Hi,
I had a play with the MirBSD KORN Shell
(https://www.mirbsd.org/main.htm) on RTEMS and have something running.
The source is here:
http://www.rtems.org/ftp/pub/rtems/people/chrisj/mksh/mksh-R50-rtems.tar.xz
It is a waf build so using something like:
$ waf configure \
--rtems-tools=
Invalidation of entire data cache might cause data written to the stack
to get lost.
---
testsuites/smptests/smpcache01/init.c | 47 +++
testsuites/smptests/smpcache01/smpcache01.doc | 1 -
testsuites/smptests/smpcache01/smpcache01.scn | 18 --
3 files chan
On 11/09/14 15:58, Peter Dufault wrote:
In nfs_dir_read() I see:
/* align + round down the buffer */
count &= ~ (DIRENT_HEADER_SIZE - 1);
di->len = count;
Then later:
if (count > NFS_MAXDATA)
count = NFS_MAXDATA;
di->readdirargs.count = count;
Can someone who
In nfs_dir_read() I see:
/* align + round down the buffer */
count &= ~ (DIRENT_HEADER_SIZE - 1);
di->len = count;
Then later:
if (count > NFS_MAXDATA)
count = NFS_MAXDATA;
di->readdirargs.count = count;
Can someone who understands this comment on it?
Peter
Hi
Since Sebastian investigated the msdos_conv.c and says it is a false
positive, I wanted to pass along that that makes the third set of warnings
that are upstream issues.
msdos_conv.c - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63224
This one is new. No feedback.
mathf - https://gcc.gnu.o
On 11/09/14 15:28, Joel Sherrill wrote:
+ printf ("%" PRIuPTR " ", ((intptr_t) buffer->user));
Typo, PRIuPTR vs. PRIiPTR?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : seba
crt.h defines such lovely constants as "RED" and "GREEN" which
have a nasty habit of conflicting with non-BSP code. There is
no reason to include this private .h from bsp.h and pollute the
namespace for applications.
---
c/src/lib/libbsp/i386/pc386/include/bsp.h | 6 --
1 file changed, 6 delet
---
cpukit/libfs/src/rfs/rtems-rfs-buffer.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/cpukit/libfs/src/rfs/rtems-rfs-buffer.c
b/cpukit/libfs/src/rfs/rtems-rfs-buffer.c
index 3d89f5f..4192b21 100644
--- a/cpukit/libfs/src/rfs/rtems-rfs-buffer.c
+++ b/cpukit/libfs/src
This may actually be a problem in inttypes.h.
---
cpukit/libfs/src/rfs/rtems-rfs-buffer.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/cpukit/libfs/src/rfs/rtems-rfs-buffer.c
b/cpukit/libfs/src/rfs/rtems-rfs-buffer.c
index 4192b21..3d89f5f 100644
--- a/cpukit/libfs/src
This change starts with removing the effectively empty file
timerdrv.h. The prototypes for benchmark_timer_XXX() were in
btimer.h which was not universally used. Thus every use of
timerdrv.h had to be changed to btimer.h. Then the prototypes
for benchmark_timer_read() had to be adjusted to return
b
This rippled into the handful of files that should have been using
.
---
c/src/lib/libbsp/m68k/mvme162/tod/tod.c | 2 +-
c/src/lib/libbsp/shared/tod.c | 1 +
c/src/lib/libbsp/shared/tod.h | 71 -
c/src/lib/libcpu/bfin/clock/rtc.c | 2 +-
Hi
Replying to myself. I grabbed the preprocessed source and
used shorter command lines on it. It is -Os vs -O2 on multiple
but not all targets.
[joel@rtbf64a libfs]$ arm-rtems4.11-gcc -Wall -O2 -c unused.c
[joel@rtbf64a libfs]$ arm-rtems4.11-gcc -Wall -Os -c unused.c
../../../../../../rtems/c
On Sep 11, 2014, at 07:47 , Peter Dufault wrote:
> So currently:
> - I/O is not limited to the file system block size;
> - The mounted block size is ignored and nfsStBlksize is used, which defaults
> to 4K.
I meant 8K above. Anyway, looking through the code and the associated change
log this
These flags are obsolete with the EABI based ARM tool chain.
---
c/src/lib/libbsp/arm/csb336/make/custom/csb336.cfg| 2 +-
c/src/lib/libbsp/arm/csb337/make/custom/csb337.cfg| 2 +-
c/src/lib/libbsp/arm/edb7312/make/custom/edb7312.cfg | 2 +-
c/src/lib/libbsp/arm/gba/make/custo
On 9/11/2014 5:21 AM, Sebastian Huber wrote:
> The code is awful, but
>
> c/src/../../cpukit/libfs/src/dosfs/msdos_conv.c:452:48: warning: 'c' may be
> used uninitialized in this function [-Wmaybe-uninitialized]
>
> is a false positive. On which target and GCC version do you get this warning?
>
On Sep 10, 2014, at 09:53 , Peter Dufault wrote:
> My client is having problems similar to that described here:
>
> http://www.rtems.org/rtems/maillistArchives/rtems-users/2011/march/msg00228.html
>
> I don't understand the details, or why one needs to limit the I/O size based
> on the ethern
On 10/09/14 15:12, Daniel Cederman wrote:
Invalidation of data cache lines might cause data written to the stack
to get lost.
---
testsuites/smptests/smpcache01/init.c | 45 +++
testsuites/smptests/smpcache01/smpcache01.doc | 2 --
testsuites/smptests/smpcache
Assuming this fixes a warning, commit it.
I will review the logs and answer your other question when I get to the
workshop this morning. That requires a computer.
I will also revert my change to rfs and start another build sweep so please
commit this.
On September 11, 2014 7:06:17 AM EDT, Seba
---
cpukit/libfs/src/dosfs/msdos_misc.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/cpukit/libfs/src/dosfs/msdos_misc.c
b/cpukit/libfs/src/dosfs/msdos_misc.c
index c09aa19..03ec38f 100644
--- a/cpukit/libfs/src/dosfs/msdos_misc.c
+++ b/cpuk
The code is awful, but
c/src/../../cpukit/libfs/src/dosfs/msdos_conv.c:452:48: warning: 'c' may be
used uninitialized in this function [-Wmaybe-uninitialized]
is a false positive. On which target and GCC version do you get this warning?
--
Sebastian Huber, embedded brains GmbH
Address : Dor
20 matches
Mail list logo
