Re: [PATCH v2] rtems: Generate

[Sebastian Huber]

On 08/10/2020 20:51, Peter Dufault wrote:


I have a minor issue with the ordering. *I haven't looked too much through 
earlier documents.*

I don't think this has anything to do with Sebastians work, but I think it is odd that "close" 
comes before directives like "I/O control" (or whatever it's called) that need to be invoked when 
the interface is open. If the ordering is intended to correspond to normal usage, as I think Joel said, this 
is wrong and "close" should be at the end.

If that's how the current documentation is structured we should stick with it 
and change it later.


This is the current order of the IO Manager directives:

https://docs.rtems.org/branches/master/c-user/io/directives.html

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Call for Ideas and Content: Documenting Benefits of RTEMS Features

[Joel Sherrill]

Hi

The RTEMS documentation is very good at technical details but short on the
benefit of each feature. For example, the combination of per-symbol linking
and the current system initialization results in smaller code and less code
in the linked executable to audit. The details of those features are
covered but not the whys and benefits to systems design.

We tend to talk about the whats without the whys or benefits.

As a broad topic for thinking, are we missing the boat by not including
this in the manuals? What's the benefit of each scheduler, clustered
scheduler, the recent static task and message queues, sysinit, linking by
sections, our source code layout, configuration options, waf, all the
generation, etc., etc.

At a higher level, over the past few years, we have changed our view on
releases and what users do. I now speak of "RTEMS Project Source Releases"
and Chris added the term deployment for what users do. I use the term RTEMS
Distribution for packaging up tools for distribution whether inside one or
across organizations. The technical pieces are there for all this but we
don't do a good job of making this model known, the roles each plays, and
where we think handoffs occur.

We have a lot of good stuff in RTEMS and I would like to start a trend
where we add a "this is good to use in a system when ... because..." and
"this is beneficial when..." to the documentation.

Our documentation is now what people find via Google to see what's in
RTEMS. Adding the systems view will help draw them in because they will see
that we are thinking of applications, deployments, reproducibility,
validation, analysis, stability, and long-term maintenance.

That's the challenge I put to the community. Let's add bits to the
documentation to explain why something is useful in an application, helps
with validation, schedulability analysis, etc.. Let's bring the systems
view into our documentation.

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] testsuites/samples/fileio - Increase of stack size

[Frank Kuehndel]

When I use the 'shell' from the fileio sample with the command below:

   env QEMU_AUDIO_DRV="none" \
   qemu-system-arm -no-reboot -net none -nographic -M realview-pbx-a9 -m 256M \
   -kernel build/arm/realview_pbx_a9_qemu/testsuites/samples/fileio.exe

The executable crashes with an "BLOWN STACK!!!" as soon as I try to login
as 'root' with password. (The logins without password work fine.) Increasing
the stack size of the affected thread a bit solves the issue. Hence,
I suggest this patch.
---
 testsuites/samples/fileio/init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/testsuites/samples/fileio/init.c b/testsuites/samples/fileio/init.c
index 86b34b99dd..c552d33613 100644
--- a/testsuites/samples/fileio/init.c
+++ b/testsuites/samples/fileio/init.c
@@ -630,7 +630,7 @@ static void fileio_start_shell(void)
   printf(" =\n");
   rtems_shell_init(
 "SHLL",  /* task_name */
-RTEMS_MINIMUM_STACK_SIZE * 4,/* task_stacksize */
+RTEMS_MINIMUM_STACK_SIZE * 5,/* task_stacksize */
 100, /* task_priority */
 "/dev/foobar",   /* devname */
 /* device is currently ignored by the shell if it is not a pty */
-- 
2.26.2

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] testsuites/samples/fileio - Increase of stack size

[Joel Sherrill]

This is interesting. When I teach RTEMS classes, I always run this
application and the last time, this BSP was the one used. It was a rare
case of all Zynq users with no LEON users. :)

What version of RTEMS and how did you configure it?

This sounds like it may need a ticket since it likely needs to be included
on the 5 branch.pa

I don't doubt it crashed. Just want details so we can apply the patch
properly.

--joel

On Fri, Oct 9, 2020 at 8:07 AM Frank Kuehndel <
frank.kuehn...@embedded-brains.de> wrote:

> When I use the 'shell' from the fileio sample with the command below:
>
>env QEMU_AUDIO_DRV="none" \
>qemu-system-arm -no-reboot -net none -nographic -M realview-pbx-a9 -m
> 256M \
>-kernel build/arm/realview_pbx_a9_qemu/testsuites/samples/fileio.exe
>
> The executable crashes with an "BLOWN STACK!!!" as soon as I try to login
> as 'root' with password. (The logins without password work fine.)
> Increasing
> the stack size of the affected thread a bit solves the issue. Hence,
> I suggest this patch.
> ---
>  testsuites/samples/fileio/init.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/testsuites/samples/fileio/init.c
> b/testsuites/samples/fileio/init.c
> index 86b34b99dd..c552d33613 100644
> --- a/testsuites/samples/fileio/init.c
> +++ b/testsuites/samples/fileio/init.c
> @@ -630,7 +630,7 @@ static void fileio_start_shell(void)
>printf(" =\n");
>rtems_shell_init(
>  "SHLL",  /* task_name */
> -RTEMS_MINIMUM_STACK_SIZE * 4,/* task_stacksize */
> +RTEMS_MINIMUM_STACK_SIZE * 5,/* task_stacksize */
>  100, /* task_priority */
>  "/dev/foobar",   /* devname */
>  /* device is currently ignored by the shell if it is not a pty */
> --
> 2.26.2
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] shell: Remove not functioning fdisk mount/unmount command

[Frank Kuehndel]

The shell has an 'fdisk' command which has sub-commands 'mount' and 'unmount'.
These two sub-commands have a bug which causes them to be not able
to mount anything. This proposed patch removes the buggy file
cpukit/libblock/src/bdpart-mount.c and the mount/unmount commands
from 'fdisk' as bug fix. The 'fdisk' command itself is not removed.
The reasons for removing the sub-commands (instead of fixing the issue) are:

  1) The bug has been introduced on 2010-May-31 with commit
 29e92b090c8bc35745aa5c89231ce806bcb11e57. Since ten years no one
 can use this feature, nor has anybody complained about it.

  2) Besides of the 'fdisk' 'mount' sub-command, the shell has the
 usual 'mount' and 'unmount' commands which can serve as
 substitutes.

  3) There are additional minor issues (see further down) which needed to
 be addressed when the file will be kept.

What follows below is the precise bug description.

The bug is in function rtems_bdpart_mount() which is only be used
by the 'fdisk' shell command to mount all partitions of a disk with a
single command:

> fdisk DISK_NAME mount
> mounts the file system of each partition of the disk
>
> fdisk DISK_NAME unmount
> unmounts the file system of each partition of the disk

The whole command does not work because in file
cpukit/libblock/src/bdpart-mount.c line 103 specifies the file system type
of each partition to be "msdos". Yet, "msdos" does not exist. The name
must be "dosfs".

Beside of this fundamental problem, there are more issues with the code
in bdpart-mount.c:

  1) The function returns RTEMS_SUCCESSFUL despite the mount always fails.

  2) The reason for errors is not written to the terminal.

  3) The directory '/mnt' is created but not deleted later on (failure or not).

  3) There is no documentation about this special 'fdisk' feature in the
 RTEMS Shell Guide ('fdisk' is mentioned but its documentation is a
 bit short):
 https://docs.rtems.org/branches/master/shell/
 file_and_directory.html#fdisk-format-disk

  4) Only "msdos" formatted partitions can be mounted and all partitions
 are mounted read-only. This is hard coded and cannot be changed by
 options. Moreover, there is no information about this to the user of
 the shell (i.e. using 'fdisk' mount requires insider knowledge).

How to reproduce:

  1) For testing, I use the 'testsuites/samples/fileio.exe' sample with qemu:

> cd rtems
> env QEMU_AUDIO_DRV="none" qemu-system-arm -net none -nographic \
> -M realview-pbx-a9 -m 256M -kernel \
> build/arm/realview_pbx_a9_qemu/testsuites/samples/fileio.exe

  2) Type any key to stop the timer and enter the sample tool.
 Type 's' to enter the shell, login as 'root' with the password
 shown in the terminal.

  3) Type the following shell commands (they create a RAM disk,
 partition it, register it, format it and try to mount it):

> mkrd
> fdisk /dev/rda fat32 16 write mbr
> fdisk /dev/rda register
> mkdos /dev/rda1
> fdisk /dev/rda mount

  4) The last line above is the command which fails - without an error
  message. There exists a '/mnt' directory but no '/mnt/rda1' directory
  as it should be:

> ls -la /mnt

  5) If you change line 103 of 'cpukit/libblock/src/bdpart-mount.c'
 from "msdos" to "dosfs", compile and build the executable and
 re-run the above test, '/mnt/rda1' exists (but the file system
 is mounted read-only).

Close #4131
---
 cpukit/Makefile.am |   1 -
 cpukit/include/rtems/bdpart.h  |  35 +-
 cpukit/libblock/src/bdpart-mount.c | 184 -
 cpukit/libmisc/shell/fdisk.c   |  36 +-
 spec/build/cpukit/librtemscpu.yml  |   1 -
 5 files changed, 7 insertions(+), 250 deletions(-)
 delete mode 100644 cpukit/libblock/src/bdpart-mount.c

diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
index 1f9124e175..bdd8ebef33 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -44,7 +44,6 @@ librtemscpu_a_SOURCES += dtc/libfdt/fdt_wip.c
 librtemscpu_a_SOURCES += libblock/src/bdbuf.c
 librtemscpu_a_SOURCES += libblock/src/bdpart-create.c
 librtemscpu_a_SOURCES += libblock/src/bdpart-dump.c
-librtemscpu_a_SOURCES += libblock/src/bdpart-mount.c
 librtemscpu_a_SOURCES += libblock/src/bdpart-read.c
 librtemscpu_a_SOURCES += libblock/src/bdpart-register.c
 librtemscpu_a_SOURCES += libblock/src/bdpart-sort.c
diff --git a/cpukit/include/rtems/bdpart.h b/cpukit/include/rtems/bdpart.h
index 8886c3614d..dde716e146 100644
--- a/cpukit/include/rtems/bdpart.h
+++ b/cpukit/include/rtems/bdpart.h
@@ -7,10 +7,10 @@
  */
 
 /*
- * Copyright (c) 2009-2012 embedded brains GmbH.  All rights reserved.
+ * Copyright (c) 2009-2012, 2020 embedded brains GmbH.  All rights reserved.
  *
  *  embedded brains GmbH
- *  Obere Lagerstr. 30
+ *  Dornierstr. 4
  *  82178 Puchheim
  *  Germany
  *  
@@ -302,37 +302,6 @@ rtems_status_code rtems_bdpart_unregister(
   size_t count
 );
 
-/**
- * @brief Mounts all supported file systems in

Re: [PATCH] testsuites/samples/fileio - Increase of stack size

[Sebastian Huber]

On 09/10/2020 15:32, Joel Sherrill wrote:

This is interesting. When I teach RTEMS classes, I always run this 
application and the last time, this BSP was the one used. It was a 
rare case of all Zynq users with no LEON users. :)


What version of RTEMS and how did you configure it?

This sounds like it may need a ticket since it likely needs to be 
included on the 5 branch.pa 


I don't doubt it crashed. Just want details so we can apply the patch 
properly.

I think this is a GCC 10 issue with -O0 and the SHA256/512 code.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] testsuites/samples/fileio - Increase of stack size

[Frank Kühndel]

Hi Joel,

Sebastian is the opinion its a "GCC 10 issue".

On 10/9/20 3:32 PM, Joel Sherrill wrote:
> This is interesting. When I teach RTEMS classes, I always run this
> application and the last time, this BSP was the one used. It was a rare
> case of all Zynq users with no LEON users. :)
> 
> What version of RTEMS and how did you configure it? 

Version is the newest, I think 6:

remote.origin.url=git://git.rtems.org/rtems.git

The branch bases on origin/master.
The preceding commit was:
commit 558a19d3adff6a3ecf678f94408b48beccbbc9fb (origin/master,
origin/HEAD, master)

The config.ini is

[arm/realview_pbx_a9_qemu]
RTEMS_DEBUG = True
RTEMS_NETWORKING = True
RTEMS_POSIX_API = True
RTEMS_SMP = True
BUILD_TESTS = True

> 
> This sounds like it may need a ticket since it likely needs to be
> included on the 5 branch.pa 

I can open a ticket for 5 and 6 if you like.

Greetings
Frank

> 
> I don't doubt it crashed. Just want details so we can apply the patch
> properly. 
> 
> --joel
> 
> On Fri, Oct 9, 2020 at 8:07 AM Frank Kuehndel
>  > wrote:
> 
> When I use the 'shell' from the fileio sample with the command below:
> 
>    env QEMU_AUDIO_DRV="none" \
>    qemu-system-arm -no-reboot -net none -nographic -M
> realview-pbx-a9 -m 256M \
>    -kernel build/arm/realview_pbx_a9_qemu/testsuites/samples/fileio.exe
> 
> The executable crashes with an "BLOWN STACK!!!" as soon as I try to
> login
> as 'root' with password. (The logins without password work fine.)
> Increasing
> the stack size of the affected thread a bit solves the issue. Hence,
> I suggest this patch.
> ---
>  testsuites/samples/fileio/init.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/testsuites/samples/fileio/init.c
> b/testsuites/samples/fileio/init.c
> index 86b34b99dd..c552d33613 100644
> --- a/testsuites/samples/fileio/init.c
> +++ b/testsuites/samples/fileio/init.c
> @@ -630,7 +630,7 @@ static void fileio_start_shell(void)
>    printf(" =\n");
>    rtems_shell_init(
>      "SHLL",                          /* task_name */
> -    RTEMS_MINIMUM_STACK_SIZE * 4,    /* task_stacksize */
> +    RTEMS_MINIMUM_STACK_SIZE * 5,    /* task_stacksize */
>      100,                             /* task_priority */
>      "/dev/foobar",                   /* devname */
>      /* device is currently ignored by the shell if it is not a pty */
> -- 
> 2.26.2
> 
> ___
> devel mailing list
> devel@rtems.org 
> http://lists.rtems.org/mailman/listinfo/devel
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH] testsuites/samples/fileio - Increase of stack size

[Kinsey Moore]

I'm not sure it's specifically a GCC10 issue, but I've encountered something 
like this before (I think it was GCC8 or GCC9).
https://github.com/ISI-apex/rtems/commit/edd6d90c3ad21393dd0de93056f371c7abc89b78

I thought I'd sent in a patch for this or at least created a ticket, but I 
can't find either at the moment.

Kinsey

-Original Message-
From: devel  On Behalf Of Frank Kühndel
Sent: Friday, October 9, 2020 09:06
To: j...@rtems.org
Cc: rtems-de...@rtems.org 
Subject: Re: [PATCH] testsuites/samples/fileio - Increase of stack size

Hi Joel,

Sebastian is the opinion its a "GCC 10 issue".

On 10/9/20 3:32 PM, Joel Sherrill wrote:
> This is interesting. When I teach RTEMS classes, I always run this 
> application and the last time, this BSP was the one used. It was a 
> rare case of all Zynq users with no LEON users. :)
> 
> What version of RTEMS and how did you configure it? 

Version is the newest, I think 6:

remote.origin.url=git://git.rtems.org/rtems.git

The branch bases on origin/master.
The preceding commit was:
commit 558a19d3adff6a3ecf678f94408b48beccbbc9fb (origin/master, origin/HEAD, 
master)

The config.ini is

[arm/realview_pbx_a9_qemu]
RTEMS_DEBUG = True
RTEMS_NETWORKING = True
RTEMS_POSIX_API = True
RTEMS_SMP = True
BUILD_TESTS = True

> 
> This sounds like it may need a ticket since it likely needs to be 
> included on the 5 branch.pa 

I can open a ticket for 5 and 6 if you like.

Greetings
Frank

> 
> I don't doubt it crashed. Just want details so we can apply the patch 
> properly.
> 
> --joel
> 
> On Fri, Oct 9, 2020 at 8:07 AM Frank Kuehndel 
>  > wrote:
> 
> When I use the 'shell' from the fileio sample with the command below:
> 
>    env QEMU_AUDIO_DRV="none" \
>    qemu-system-arm -no-reboot -net none -nographic -M
> realview-pbx-a9 -m 256M \
>    -kernel 
> build/arm/realview_pbx_a9_qemu/testsuites/samples/fileio.exe
> 
> The executable crashes with an "BLOWN STACK!!!" as soon as I try to
> login
> as 'root' with password. (The logins without password work fine.)
> Increasing
> the stack size of the affected thread a bit solves the issue. Hence,
> I suggest this patch.
> ---
>  testsuites/samples/fileio/init.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/testsuites/samples/fileio/init.c
> b/testsuites/samples/fileio/init.c
> index 86b34b99dd..c552d33613 100644
> --- a/testsuites/samples/fileio/init.c
> +++ b/testsuites/samples/fileio/init.c
> @@ -630,7 +630,7 @@ static void fileio_start_shell(void)
>    printf(" =\n");
>    rtems_shell_init(
>      "SHLL",                          /* task_name */
> -    RTEMS_MINIMUM_STACK_SIZE * 4,    /* task_stacksize */
> +    RTEMS_MINIMUM_STACK_SIZE * 5,    /* task_stacksize */
>      100,                             /* task_priority */
>      "/dev/foobar",                   /* devname */
>      /* device is currently ignored by the shell if it is not a pty */
> -- 
> 2.26.2
> 
> ___
> devel mailing list
> devel@rtems.org 
> http://lists.rtems.org/mailman/listinfo/devel
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] testsuites/samples/fileio - Increase of stack size

[Joel Sherrill]

On Fri, Oct 9, 2020 at 9:11 AM Kinsey Moore 
wrote:

> I'm not sure it's specifically a GCC10 issue, but I've encountered
> something like this before (I think it was GCC8 or GCC9).
>
> https://github.com/ISI-apex/rtems/commit/edd6d90c3ad21393dd0de93056f371c7abc89b78
>
> I thought I'd sent in a patch for this or at least created a ticket, but I
> can't find either at the moment.
>

Would switching this BSP from -O0 to -Og be prudent also?

I assume it is using -O0 to ease debugging.

--joel

>
> Kinsey
>
> -Original Message-
> From: devel  On Behalf Of Frank Kühndel
> Sent: Friday, October 9, 2020 09:06
> To: j...@rtems.org
> Cc: rtems-de...@rtems.org 
> Subject: Re: [PATCH] testsuites/samples/fileio - Increase of stack size
>
> Hi Joel,
>
> Sebastian is the opinion its a "GCC 10 issue".
>
> On 10/9/20 3:32 PM, Joel Sherrill wrote:
> > This is interesting. When I teach RTEMS classes, I always run this
> > application and the last time, this BSP was the one used. It was a
> > rare case of all Zynq users with no LEON users. :)
> >
> > What version of RTEMS and how did you configure it?
>
> Version is the newest, I think 6:
>
> remote.origin.url=git://git.rtems.org/rtems.git
>
> The branch bases on origin/master.
> The preceding commit was:
> commit 558a19d3adff6a3ecf678f94408b48beccbbc9fb (origin/master,
> origin/HEAD, master)
>
> The config.ini is
>
> [arm/realview_pbx_a9_qemu]
> RTEMS_DEBUG = True
> RTEMS_NETWORKING = True
> RTEMS_POSIX_API = True
> RTEMS_SMP = True
> BUILD_TESTS = True
>
> >
> > This sounds like it may need a ticket since it likely needs to be
> > included on the 5 branch.pa 
>
> I can open a ticket for 5 and 6 if you like.
>
> Greetings
> Frank
>
> >
> > I don't doubt it crashed. Just want details so we can apply the patch
> > properly.
> >
> > --joel
> >
> > On Fri, Oct 9, 2020 at 8:07 AM Frank Kuehndel
> >  > > wrote:
> >
> > When I use the 'shell' from the fileio sample with the command below:
> >
> >env QEMU_AUDIO_DRV="none" \
> >qemu-system-arm -no-reboot -net none -nographic -M
> > realview-pbx-a9 -m 256M \
> >-kernel
> > build/arm/realview_pbx_a9_qemu/testsuites/samples/fileio.exe
> >
> > The executable crashes with an "BLOWN STACK!!!" as soon as I try to
> > login
> > as 'root' with password. (The logins without password work fine.)
> > Increasing
> > the stack size of the affected thread a bit solves the issue. Hence,
> > I suggest this patch.
> > ---
> >  testsuites/samples/fileio/init.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/testsuites/samples/fileio/init.c
> > b/testsuites/samples/fileio/init.c
> > index 86b34b99dd..c552d33613 100644
> > --- a/testsuites/samples/fileio/init.c
> > +++ b/testsuites/samples/fileio/init.c
> > @@ -630,7 +630,7 @@ static void fileio_start_shell(void)
> >printf(" =\n");
> >rtems_shell_init(
> >  "SHLL",  /* task_name */
> > -RTEMS_MINIMUM_STACK_SIZE * 4,/* task_stacksize */
> > +RTEMS_MINIMUM_STACK_SIZE * 5,/* task_stacksize */
> >  100, /* task_priority */
> >  "/dev/foobar",   /* devname */
> >  /* device is currently ignored by the shell if it is not a pty
> */
> > --
> > 2.26.2
> >
> > ___
> > devel mailing list
> > devel@rtems.org 
> > http://lists.rtems.org/mailman/listinfo/devel
> >
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] user: Add a Languages section

[Gedare Bloom]

On Thu, Oct 8, 2020 at 11:42 PM  wrote:
>
> From: Chris Johns 
>
> ---
>  user/index.rst   |   2 +
>  user/languages/c.rst |  14 ++
>  user/languages/cpp.rst   | 312 +++
>  user/languages/index.rst |  21 +++
>  4 files changed, 349 insertions(+)
>  create mode 100644 user/languages/c.rst
>  create mode 100644 user/languages/cpp.rst
>  create mode 100644 user/languages/index.rst
>
> diff --git a/user/index.rst b/user/index.rst
> index a91aa55..32667f4 100644
> --- a/user/index.rst
> +++ b/user/index.rst
> @@ -42,6 +42,8 @@ RTEMS User Manual (|version|).
>  bld/index
>  bsps/index
>
> +languages/index
> +
>  exe/index
>  testing/index
>  tracing/index
> diff --git a/user/languages/c.rst b/user/languages/c.rst
> new file mode 100644
> index 000..c3965eb
> --- /dev/null
> +++ b/user/languages/c.rst
> @@ -0,0 +1,14 @@
> +.. SPDX-License-Identifier: CC-BY-SA-4.0
> +
> +.. Copyright (C) 2020 Chris Johns 
> +
> +.. index:: C
> +.. index:: C Programming Language
> +
> +C
> +=
> +.. index:: C
> +
> +RTEMS supports the C programming language.
> +
> +TBD.
> diff --git a/user/languages/cpp.rst b/user/languages/cpp.rst
> new file mode 100644
> index 000..8a8cb86
> --- /dev/null
> +++ b/user/languages/cpp.rst
> @@ -0,0 +1,312 @@
> +.. SPDX-License-Identifier: CC-BY-SA-4.0
> +
> +.. Copyright (C) 2020 Chris Johns 
> +
> +.. index:: C++
> +.. index:: C++ Programming Language
> +
> +C++
> +===
> +.. index:: C++
> +
> +RTEMS supports the C++ programming language and its standard library. The
> +supported language versions are C++11, C++14, and C++17.

I'm curious, will C++98/C++03 compliant code work? I admit to being
completely out of touch with the C++ standard evolution.

> +
> +The C++ standard library provides a rich set of interfaces to support
> +multi-threaded programming. The Thread support library provides
> +``std::lock_guard`` as a means to manage ``std::mutex`` or similar objects
> +within a code block while execution remains within that block. The
> +``std::promise`` and ``std::future`` supports provides a controlled means for
> +threads to end, clean-up and return a status value of some type. The Atomic
> +operations library provdes a range of methods to atomically acess data as 
> well
provides
access

> +as establish inter-thread synchronization and order non-atomic memory
> +accesses.
> +
> +The Thread support library maps to the RTEMS POSIX ``pthread`` interface and
> +the various sychronisation primatives such as mutual exclusion, condition
primitives

> +variables, and futures map to the high performance self-contained RTEMS
> +interface. These objects have a fast execution profile and their storage is
> +self-contained which means it does not have to be accounted for in the
> +configuration and work-space settings. C++ applications do not need to be
> +concerned about the number of locks being used and can implement fine grain
> +locking protocols.
> +
> +RTEMS Threads
> +-
> +
> +RTEMS provides an alternative Thread interface that lets you specify the
> +attributes of a thread when it is constructed. This is an extension to the
> +standard and is not based on any current or pending standards efforts. The
> +goal is to make the interface as close as possible to the existing standard 
> to
> +minimise the impact on code being ported to RTEMS.
> +
> +The following compiler option must be used as the implementation uses the
> +``std::invoke`` call which is only available with C++17:
> +
> +.. code-block:: c++
> +
> +   --std=c++17
> +
> +The standard Thread support library specifies the thread constructor as:
> +
> +.. code-block:: c++
> +
> +   template< class Function, class... Args >
> +   explicit thread( Function&& f, Args&&... args );
> +
> +A thread constructed using this interface will have a default set of initial
> +values. An important atribute of a thread is the stack size and this cannot 
> be
attribute

> +specified or altered with this interface. On Unix systems virtual memory can
> +be used to manage a thread's stack size and stack handling is more complex
> +when security is considered so manually controlling the stack size of a 
> thread
> +is not needed or wanted.
> +
> +Attributes
> +^^
> +
> +The ``rtems::thread::attributes`` class provides an interface to control the
> +various attributes a thread has. The header file is:
> +
> +.. code-block:: c++
> +
> +   #include 
> +
> +The default constructor initialises the attributes to the executing thread's
> +settings and the stack size is set to the configured minimum. You can then
> +alter the attributes to match the requirements of the new thread. It is easy
> +to set a name, stack size and priority:
> +
> +.. code-block:: c++
> +
> +   rtems::thread::attribute attr;
> +   attr.set_name("blue");
> +   attr.set_stack_size(16 * 1024);
> +   attr.set_priority(attr.get_priority() + 1);
> +
> +The ``update()`` method will read the attributes of

Re: Need help debugging sp16.exe

[Richi Dubey]

Okay, I'm gonna do that. Thanks for the help.

On Thu, Oct 8, 2020 at 9:47 PM Gedare Bloom  wrote:

> On Thu, Oct 8, 2020 at 9:38 AM Richi Dubey  wrote:
> >
> > Hi,
> >
> > I have been trying to debug sp16 for the last few days. I am using the
> new Strong APA scheduler we worked on during this GSoC. The scheduler fails
> only for the following tests:
> >
> >  sp02.exe
> >  sp16.exe
> >  sp30.exe
> >  sp31.exe
> >  sp37.exe
> >  sp42.exe
> >  spfatal29.exe
> >  tm24.exe
> >
> > On executing sp16.exe, I get the following output:
> >
> > *** BEGIN OF TEST SP 16 ***
> > *** TEST VERSION: 5.0.0.61ccb9c05dcd695114541960aa6bfc1315f30514-modified
> > *** TEST STATE: EXPECTED_PASS
> > *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API RTEMS_SMP
> > *** TEST TOOLS: 7.5.0 20191114 (RTEMS 5, RSB 5 (0b7e87143b76), Newlib
> fbaa096)
> > TA1 - rtems_region_ident - rnid => 32010001
> > TA1 - rtems_region_get_segment - wait on 1000 byte segment from region 2
> > TA1 - got segment from region 2 - 0x0040
> > TA1 - rtems_region_get_segment - wait on 3K segment from region 3
> > TA1 - got segment from region 3 - 0x0080
> > TA1 - rtems_region_get_segment - get 3080 byte segment from region 1 -
> NO_WAIT
> > TA1 - got segment from region 1 - 0x0040
> > TA1 - rtems_task_wake_after - yield processor
> > TA2 - rtems_region_get_segment - wait on 2K segment from region 1
> > TA1 - rtems_region_return_segment - return segment to region 1 -
> 0x0040
> > TA1 - rtems_region_get_segment - wait 10 seconds for 3K segment from
> region 1
> > TA2 - got segment from region 1 - 0x0040
> > TA2 - rtems_region_return_segment - return segment to region 1 -
> 0x0040
> > TA2 - rtems_task_set_priority - make self highest priority task
> > TA2 - rtems_region_get_segment - wait on 3750 byte segment
> > TA1 - got segment from region 1 - 0x0040
> > TA1 - rtems_region_return_segment - return segment to region 2 -
> 0x0040
> > TA2 - got segment from region 2 - 0x0040
> > TA2 - rtems_region_return_segment - return segment to region 2 -
> 0x0040
> > TA2 - rtems_task_exit
> > TA1 - rtems_task_wake_after - yield processor
> > TA3 - rtems_region_get_segment - wait on 3750 byte segment from region 2
> > TA3 - got segment from region 2 - 0x0040
> > TA3 - rtems_region_get_segment - wait on 2K segment from region 3
> > TA1 - rtems_task_delete - delete TA3
> > TA1 - rtems_task_wake_after - yield processor
> > TA4 - rtems_region_get_segment - wait on 1.5K segment from region 1
> > TA5 - rtems_region_get_segment - wait on 1.5K segment from region 1
> > TA1 - rtems_region_return_segment - return segment to region 1 -
> 0x0040
> > TA1 - rtems_task_wake_after - yield processor
> > TA4 - got and returned 0x0040
> > TA5 - got and returned 0x06c0
> > TA1 - rtems_region_get_segment - wait 10 seconds for 3K segment from
> region 1
> > TA1 - got segment from region 1 - 0x0040
> > TA1 - rtems_task_wake_after - yield processor
> > TA4 - rtems_region_get_segment - wait on 3K segment from region 1
> > TA5 - rtems_region_get_segment - wait on 3K segment from region 1
> > TA1 - rtems_task_delete - delete TA4
> > TA1 - rtems_region_return_segment - return segment to region 1 -
> 0x0040
> > TA1 - rtems_task_wake_after - yield processor
> > TA5 - got segment from region 1 - 0x0040
> > TA5 - rtems_region_return_segment - return segment to region 1 -
> 0x0040
> > TA5 - rtems_task_exit
> >
> > and it doesn't progress further from here. It gets stuck in some kind of
> loop. While debugging with gdb, I realized the loop is:
> >
> > Clock_isr (arg=0x0) at
> /home/richi/quick-start/src/rtems/bsps/arm/include/../../shared/dev/clock/clockimpl.h:155
> > 155  _Thread_Heir == _Thread_Executing &&
> _Thread_Executing->is_idle
> > (gdb)
> > 0x001042fa 155  _Thread_Heir == _Thread_Executing &&
> _Thread_Executing->is_idle
> > (gdb)
> > 0x001042fc 155  _Thread_Heir == _Thread_Executing &&
> _Thread_Executing->is_idle
> > (gdb)
> > 0x001042fe 155  _Thread_Heir == _Thread_Executing &&
> _Thread_Executing->is_idle
> > (gdb)
> >
> > 0x00104302 155  _Thread_Heir == _Thread_Executing &&
> _Thread_Executing->is_idle
> > (gdb)
> > 0x00104304 155  _Thread_Heir == _Thread_Executing &&
> _Thread_Executing->is_idle
> > (gdb)
> > 0x00104306 155  _Thread_Heir == _Thread_Executing &&
> _Thread_Executing->is_idle
> > (gdb)
> > 0x0010430a 155  _Thread_Heir == _Thread_Executing &&
> _Thread_Executing->is_idle
> > (gdb)
> > 154while (
> > (gdb)
> > 0x0010430e 154while (
> > (gdb)
> > 155  _Thread_Heir == _Thread_Executing &&
> _Thread_Executing->is_idle
> > (gdb)
> > 0x00104314 155  _Thread_Heir == _Thread_Executing &&
> _Thread_Executing->is_idle
> > (gdb)
> > 0x00104316 155  _Thread_Heir == _Thread_Executing &&
> _Thread_Executing->is_idle
> > (gdb)
> > 0x00104318 155  _Thread_Heir == _Thread_Executing &&
> _Thread_Executing->is_idle
> > (

Re: [PATCH] shell: Remove not functioning fdisk mount/unmount command

[Gedare Bloom]

Excellent analysis. I would like Chris to weigh in, but the rationale
to remove instead of try to fix makes sense because it is basically an
undocumented shell API.

On Fri, Oct 9, 2020 at 7:38 AM Frank Kuehndel
 wrote:
>
> The shell has an 'fdisk' command which has sub-commands 'mount' and 'unmount'.
> These two sub-commands have a bug which causes them to be not able
> to mount anything. This proposed patch removes the buggy file
> cpukit/libblock/src/bdpart-mount.c and the mount/unmount commands
> from 'fdisk' as bug fix. The 'fdisk' command itself is not removed.
> The reasons for removing the sub-commands (instead of fixing the issue) are:
>
>   1) The bug has been introduced on 2010-May-31 with commit
>  29e92b090c8bc35745aa5c89231ce806bcb11e57. Since ten years no one
>  can use this feature, nor has anybody complained about it.
>
>   2) Besides of the 'fdisk' 'mount' sub-command, the shell has the
>  usual 'mount' and 'unmount' commands which can serve as
>  substitutes.
>
>   3) There are additional minor issues (see further down) which needed to
>  be addressed when the file will be kept.
>
> What follows below is the precise bug description.
>
> The bug is in function rtems_bdpart_mount() which is only be used
> by the 'fdisk' shell command to mount all partitions of a disk with a
> single command:
>
> > fdisk DISK_NAME mount
> > mounts the file system of each partition of the disk
> >
> > fdisk DISK_NAME unmount
> > unmounts the file system of each partition of the disk
>
> The whole command does not work because in file
> cpukit/libblock/src/bdpart-mount.c line 103 specifies the file system type
> of each partition to be "msdos". Yet, "msdos" does not exist. The name
> must be "dosfs".
>
> Beside of this fundamental problem, there are more issues with the code
> in bdpart-mount.c:
>
>   1) The function returns RTEMS_SUCCESSFUL despite the mount always fails.
>
>   2) The reason for errors is not written to the terminal.
>
>   3) The directory '/mnt' is created but not deleted later on (failure or 
> not).
>
>   3) There is no documentation about this special 'fdisk' feature in the
>  RTEMS Shell Guide ('fdisk' is mentioned but its documentation is a
>  bit short):
>  https://docs.rtems.org/branches/master/shell/
>  file_and_directory.html#fdisk-format-disk
>
>   4) Only "msdos" formatted partitions can be mounted and all partitions
>  are mounted read-only. This is hard coded and cannot be changed by
>  options. Moreover, there is no information about this to the user of
>  the shell (i.e. using 'fdisk' mount requires insider knowledge).
>
> How to reproduce:
>
>   1) For testing, I use the 'testsuites/samples/fileio.exe' sample with qemu:
>
> > cd rtems
> > env QEMU_AUDIO_DRV="none" qemu-system-arm -net none -nographic \
> > -M realview-pbx-a9 -m 256M -kernel \
> > build/arm/realview_pbx_a9_qemu/testsuites/samples/fileio.exe
>
>   2) Type any key to stop the timer and enter the sample tool.
>  Type 's' to enter the shell, login as 'root' with the password
>  shown in the terminal.
>
>   3) Type the following shell commands (they create a RAM disk,
>  partition it, register it, format it and try to mount it):
>
> > mkrd
> > fdisk /dev/rda fat32 16 write mbr
> > fdisk /dev/rda register
> > mkdos /dev/rda1
> > fdisk /dev/rda mount
>
>   4) The last line above is the command which fails - without an error
>   message. There exists a '/mnt' directory but no '/mnt/rda1' directory
>   as it should be:
>
> > ls -la /mnt
>
>   5) If you change line 103 of 'cpukit/libblock/src/bdpart-mount.c'
>  from "msdos" to "dosfs", compile and build the executable and
>  re-run the above test, '/mnt/rda1' exists (but the file system
>  is mounted read-only).
>
> Close #4131
> ---
>  cpukit/Makefile.am |   1 -
>  cpukit/include/rtems/bdpart.h  |  35 +-
>  cpukit/libblock/src/bdpart-mount.c | 184 -
>  cpukit/libmisc/shell/fdisk.c   |  36 +-
>  spec/build/cpukit/librtemscpu.yml  |   1 -
>  5 files changed, 7 insertions(+), 250 deletions(-)
>  delete mode 100644 cpukit/libblock/src/bdpart-mount.c
>
> diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
> index 1f9124e175..bdd8ebef33 100644
> --- a/cpukit/Makefile.am
> +++ b/cpukit/Makefile.am
> @@ -44,7 +44,6 @@ librtemscpu_a_SOURCES += dtc/libfdt/fdt_wip.c
>  librtemscpu_a_SOURCES += libblock/src/bdbuf.c
>  librtemscpu_a_SOURCES += libblock/src/bdpart-create.c
>  librtemscpu_a_SOURCES += libblock/src/bdpart-dump.c
> -librtemscpu_a_SOURCES += libblock/src/bdpart-mount.c
>  librtemscpu_a_SOURCES += libblock/src/bdpart-read.c
>  librtemscpu_a_SOURCES += libblock/src/bdpart-register.c
>  librtemscpu_a_SOURCES += libblock/src/bdpart-sort.c
> diff --git a/cpukit/include/rtems/bdpart.h b/cpukit/include/rtems/bdpart.h
> index 8886c3614d..dde716e146 100644
> --- a/cpukit/include/rtems/bdpart.h
> +++ b/cpukit/include/rtems/bdpart.h

Re: [PATCH] user: Add a Languages section

[Joel Sherrill]

On Fri, Oct 9, 2020 at 10:26 AM Gedare Bloom  wrote:

> On Thu, Oct 8, 2020 at 11:42 PM  wrote:
> >
> > From: Chris Johns 
> >
> > ---
> >  user/index.rst   |   2 +
> >  user/languages/c.rst |  14 ++
> >  user/languages/cpp.rst   | 312 +++
> >  user/languages/index.rst |  21 +++
> >  4 files changed, 349 insertions(+)
> >  create mode 100644 user/languages/c.rst
> >  create mode 100644 user/languages/cpp.rst
> >  create mode 100644 user/languages/index.rst
> >
> > diff --git a/user/index.rst b/user/index.rst
> > index a91aa55..32667f4 100644
> > --- a/user/index.rst
> > +++ b/user/index.rst
> > @@ -42,6 +42,8 @@ RTEMS User Manual (|version|).
> >  bld/index
> >  bsps/index
> >
> > +languages/index
> > +
> >  exe/index
> >  testing/index
> >  tracing/index
> > diff --git a/user/languages/c.rst b/user/languages/c.rst
> > new file mode 100644
> > index 000..c3965eb
> > --- /dev/null
> > +++ b/user/languages/c.rst
> > @@ -0,0 +1,14 @@
> > +.. SPDX-License-Identifier: CC-BY-SA-4.0
> > +
> > +.. Copyright (C) 2020 Chris Johns 
> > +
>

Should there be a general introduction on the compilers we support
and that we inherently rely on them. This puts the context into what
do GCC and CLANG support and which compiler(s) are available
on your target architecture.

Also Ada should have a TBD section.

If you can build Fortran with the RSB, it also needs a TBD section.
Surprising though it may be, it does work. :)


> > +.. index:: C
> > +.. index:: C Programming Language
> > +
> > +C
> > +=
> > +.. index:: C
> > +
> > +RTEMS supports the C programming language.
> > +
> > +TBD.
>

Obviously TBD but supported via the inherent compiler support
with the C Standard Library provided by newlib. Could reference
the POSIX Compliance Guide section on the C Standard Library.

Support should be primarily for C99 and C11 including C11 threads.
Don't C11 thread also map to pthreads?

There is a C11 threads example in rtems-examples.

Disclaimer: C11 threads are a terrible API.


> diff --git a/user/languages/cpp.rst b/user/languages/cpp.rst
> > new file mode 100644
> > index 000..8a8cb86
> > --- /dev/null
> > +++ b/user/languages/cpp.rst
> > @@ -0,0 +1,312 @@
> > +.. SPDX-License-Identifier: CC-BY-SA-4.0
> > +
> > +.. Copyright (C) 2020 Chris Johns 
> > +
> > +.. index:: C++
> > +.. index:: C++ Programming Language
> > +
> > +C++
> > +===
> > +.. index:: C++
> > +
> > +RTEMS supports the C++ programming language and its standard library.
> The
> > +supported language versions are C++11, C++14, and C++17.
>
> I'm curious, will C++98/C++03 compliant code work? I admit to being
> completely out of touch with the C++ standard evolution.
>

Yes.  The FACE Conformance Test Suite has been run against our C++03
support with no issues. GCC and its C++ Library are the magic here.


>
> > +
> > +The C++ standard library provides a rich set of interfaces to support
> > +multi-threaded programming. The Thread support library provides
> > +``std::lock_guard`` as a means to manage ``std::mutex`` or similar
> objects
> > +within a code block while execution remains within that block. The
> > +``std::promise`` and ``std::future`` supports provides a controlled
> means for
> > +threads to end, clean-up and return a status value of some type. The
> Atomic
> > +operations library provdes a range of methods to atomically acess data
> as well
> provides
> access
>
> > +as establish inter-thread synchronization and order non-atomic memory
> > +accesses.
> > +
> > +The Thread support library maps to the RTEMS POSIX ``pthread``
> interface and
> > +the various sychronisation primatives such as mutual exclusion,
> condition
> primitives
>

synchronization


>
> > +variables, and futures map to the high performance self-contained RTEMS
> > +interface. These objects have a fast execution profile and their
> storage is
> > +self-contained which means it does not have to be accounted for in the
> > +configuration and work-space settings. C++ applications do not need to
> be
> > +concerned about the number of locks being used and can implement fine
> grain
> > +locking protocols.
> > +
> > +RTEMS Threads
> > +-
> > +
> > +RTEMS provides an alternative Thread interface that lets you specify the
> > +attributes of a thread when it is constructed. This is an extension to
> the
> > +standard and is not based on any current or pending standards efforts.
> The
> > +goal is to make the interface as close as possible to the existing
> standard to
> > +minimise the impact on code being ported to RTEMS.
> > +
> > +The following compiler option must be used as the implementation uses
> the
> > +``std::invoke`` call which is only available with C++17:
> > +
> > +.. code-block:: c++
> > +
> > +   --std=c++17
> > +
> > +The standard Thread support library specifies the thread constructor as:
> > +
> > +.. code-block:: c++
> > +
> > +   template< class Function, class... Args >
> > +   e

Re: [PATCH] user: Add a Languages section

[Gedare Bloom]

On Fri, Oct 9, 2020 at 9:38 AM Joel Sherrill  wrote:
>
>
>
> On Fri, Oct 9, 2020 at 10:26 AM Gedare Bloom  wrote:
>>
>> On Thu, Oct 8, 2020 at 11:42 PM  wrote:
>> >
>> > From: Chris Johns 
>> >
>> > ---
>> >  user/index.rst   |   2 +
>> >  user/languages/c.rst |  14 ++
>> >  user/languages/cpp.rst   | 312 +++
>> >  user/languages/index.rst |  21 +++
>> >  4 files changed, 349 insertions(+)
>> >  create mode 100644 user/languages/c.rst
>> >  create mode 100644 user/languages/cpp.rst
>> >  create mode 100644 user/languages/index.rst
>> >
>> > diff --git a/user/index.rst b/user/index.rst
>> > index a91aa55..32667f4 100644
>> > --- a/user/index.rst
>> > +++ b/user/index.rst
>> > @@ -42,6 +42,8 @@ RTEMS User Manual (|version|).
>> >  bld/index
>> >  bsps/index
>> >
>> > +languages/index
>> > +
>> >  exe/index
>> >  testing/index
>> >  tracing/index
>> > diff --git a/user/languages/c.rst b/user/languages/c.rst
>> > new file mode 100644
>> > index 000..c3965eb
>> > --- /dev/null
>> > +++ b/user/languages/c.rst
>> > @@ -0,0 +1,14 @@
>> > +.. SPDX-License-Identifier: CC-BY-SA-4.0
>> > +
>> > +.. Copyright (C) 2020 Chris Johns 
>> > +
>
>
> Should there be a general introduction on the compilers we support
> and that we inherently rely on them. This puts the context into what
> do GCC and CLANG support and which compiler(s) are available
> on your target architecture.
>
> Also Ada should have a TBD section.
>
> If you can build Fortran with the RSB, it also needs a TBD section.
> Surprising though it may be, it does work. :)
>
>>
>> > +.. index:: C
>> > +.. index:: C Programming Language
>> > +
>> > +C
>> > +=
>> > +.. index:: C
>> > +
>> > +RTEMS supports the C programming language.
>> > +
>> > +TBD.
>
>
> Obviously TBD but supported via the inherent compiler support
> with the C Standard Library provided by newlib. Could reference
> the POSIX Compliance Guide section on the C Standard Library.
>
> Support should be primarily for C99 and C11 including C11 threads.
> Don't C11 thread also map to pthreads?
>
> There is a C11 threads example in rtems-examples.
>
> Disclaimer: C11 threads are a terrible API.
>
>
>> > diff --git a/user/languages/cpp.rst b/user/languages/cpp.rst
>> > new file mode 100644
>> > index 000..8a8cb86
>> > --- /dev/null
>> > +++ b/user/languages/cpp.rst
>> > @@ -0,0 +1,312 @@
>> > +.. SPDX-License-Identifier: CC-BY-SA-4.0
>> > +
>> > +.. Copyright (C) 2020 Chris Johns 
>> > +
>> > +.. index:: C++
>> > +.. index:: C++ Programming Language
>> > +
>> > +C++
>> > +===
>> > +.. index:: C++
>> > +
>> > +RTEMS supports the C++ programming language and its standard library. The
>> > +supported language versions are C++11, C++14, and C++17.
>>
>> I'm curious, will C++98/C++03 compliant code work? I admit to being
>> completely out of touch with the C++ standard evolution.
>
>
> Yes.  The FACE Conformance Test Suite has been run against our C++03
> support with no issues. GCC and its C++ Library are the magic here.
>
>>
>>
>> > +
>> > +The C++ standard library provides a rich set of interfaces to support
>> > +multi-threaded programming. The Thread support library provides
>> > +``std::lock_guard`` as a means to manage ``std::mutex`` or similar objects
>> > +within a code block while execution remains within that block. The
>> > +``std::promise`` and ``std::future`` supports provides a controlled means 
>> > for
>> > +threads to end, clean-up and return a status value of some type. The 
>> > Atomic
>> > +operations library provdes a range of methods to atomically acess data as 
>> > well
>> provides
>> access
>>
>> > +as establish inter-thread synchronization and order non-atomic memory
>> > +accesses.
>> > +
>> > +The Thread support library maps to the RTEMS POSIX ``pthread`` interface 
>> > and
>> > +the various sychronisation primatives such as mutual exclusion, condition
>> primitives
>
>
> synchronization
>
or synchronisation to be self-consistent. thanks for spotting that..
the UK/AU s throws off my typo parsing :)

>>
>>
>> > +variables, and futures map to the high performance self-contained RTEMS
>> > +interface. These objects have a fast execution profile and their storage 
>> > is
>> > +self-contained which means it does not have to be accounted for in the
>> > +configuration and work-space settings. C++ applications do not need to be
>> > +concerned about the number of locks being used and can implement fine 
>> > grain
>> > +locking protocols.
>> > +
>> > +RTEMS Threads
>> > +-
>> > +
>> > +RTEMS provides an alternative Thread interface that lets you specify the
>> > +attributes of a thread when it is constructed. This is an extension to the
>> > +standard and is not based on any current or pending standards efforts. The
>> > +goal is to make the interface as close as possible to the existing 
>> > standard to
>> > +minimise the impact on code being ported to RTEMS.
>> > +
>> > +The following compiler 

Re: [PATCH] shell: Remove not functioning fdisk mount/unmount command

[Peter Dufault]

Yes, and you don't want to support two ways to do something if it hasn't been 
noticed in ten years.

> On Oct 9, 2020, at 11:37 , Gedare Bloom  wrote:
> 
> Excellent analysis. I would like Chris to weigh in, but the rationale
> to remove instead of try to fix makes sense because it is basically an
> undocumented shell API.
> 
> On Fri, Oct 9, 2020 at 7:38 AM Frank Kuehndel
>  wrote:
>> 
>> The shell has an 'fdisk' command which has sub-commands 'mount' and 
>> 'unmount'.
>> These two sub-commands have a bug which causes them to be not able
>> to mount anything. This proposed patch removes the buggy file
>> cpukit/libblock/src/bdpart-mount.c and the mount/unmount commands
>> from 'fdisk' as bug fix. The 'fdisk' command itself is not removed.
>> The reasons for removing the sub-commands (instead of fixing the issue) are:
>> 
>>  1) The bug has been introduced on 2010-May-31 with commit
>> 29e92b090c8bc35745aa5c89231ce806bcb11e57. Since ten years no one
>> can use this feature, nor has anybody complained about it.
>> 
>>  2) Besides of the 'fdisk' 'mount' sub-command, the shell has the
>> usual 'mount' and 'unmount' commands which can serve as
>> substitutes.
>> 
>>  3) There are additional minor issues (see further down) which needed to
>> be addressed when the file will be kept.
>> 
>> What follows below is the precise bug description.
>> 
>> The bug is in function rtems_bdpart_mount() which is only be used
>> by the 'fdisk' shell command to mount all partitions of a disk with a
>> single command:
>> 
>>> fdisk DISK_NAME mount
>>>mounts the file system of each partition of the disk
>>> 
>>> fdisk DISK_NAME unmount
>>>unmounts the file system of each partition of the disk
>> 
>> The whole command does not work because in file
>> cpukit/libblock/src/bdpart-mount.c line 103 specifies the file system type
>> of each partition to be "msdos". Yet, "msdos" does not exist. The name
>> must be "dosfs".
>> 
>> Beside of this fundamental problem, there are more issues with the code
>> in bdpart-mount.c:
>> 
>>  1) The function returns RTEMS_SUCCESSFUL despite the mount always fails.
>> 
>>  2) The reason for errors is not written to the terminal.
>> 
>>  3) The directory '/mnt' is created but not deleted later on (failure or 
>> not).
>> 
>>  3) There is no documentation about this special 'fdisk' feature in the
>> RTEMS Shell Guide ('fdisk' is mentioned but its documentation is a
>> bit short):
>> https://docs.rtems.org/branches/master/shell/
>> file_and_directory.html#fdisk-format-disk
>> 
>>  4) Only "msdos" formatted partitions can be mounted and all partitions
>> are mounted read-only. This is hard coded and cannot be changed by
>> options. Moreover, there is no information about this to the user of
>> the shell (i.e. using 'fdisk' mount requires insider knowledge).
>> 
>> How to reproduce:
>> 
>>  1) For testing, I use the 'testsuites/samples/fileio.exe' sample with qemu:
>> 
>>> cd rtems
>>> env QEMU_AUDIO_DRV="none" qemu-system-arm -net none -nographic \
>>> -M realview-pbx-a9 -m 256M -kernel \
>>> build/arm/realview_pbx_a9_qemu/testsuites/samples/fileio.exe
>> 
>>  2) Type any key to stop the timer and enter the sample tool.
>> Type 's' to enter the shell, login as 'root' with the password
>> shown in the terminal.
>> 
>>  3) Type the following shell commands (they create a RAM disk,
>> partition it, register it, format it and try to mount it):
>> 
>>> mkrd
>>> fdisk /dev/rda fat32 16 write mbr
>>> fdisk /dev/rda register
>>> mkdos /dev/rda1
>>> fdisk /dev/rda mount
>> 
>>  4) The last line above is the command which fails - without an error
>>  message. There exists a '/mnt' directory but no '/mnt/rda1' directory
>>  as it should be:
>> 
>>> ls -la /mnt
>> 
>>  5) If you change line 103 of 'cpukit/libblock/src/bdpart-mount.c'
>> from "msdos" to "dosfs", compile and build the executable and
>> re-run the above test, '/mnt/rda1' exists (but the file system
>> is mounted read-only).
>> 
>> Close #4131
>> ---
>> cpukit/Makefile.am |   1 -
>> cpukit/include/rtems/bdpart.h  |  35 +-
>> cpukit/libblock/src/bdpart-mount.c | 184 -
>> cpukit/libmisc/shell/fdisk.c   |  36 +-
>> spec/build/cpukit/librtemscpu.yml  |   1 -
>> 5 files changed, 7 insertions(+), 250 deletions(-)
>> delete mode 100644 cpukit/libblock/src/bdpart-mount.c
>> 
>> diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
>> index 1f9124e175..bdd8ebef33 100644
>> --- a/cpukit/Makefile.am
>> +++ b/cpukit/Makefile.am
>> @@ -44,7 +44,6 @@ librtemscpu_a_SOURCES += dtc/libfdt/fdt_wip.c
>> librtemscpu_a_SOURCES += libblock/src/bdbuf.c
>> librtemscpu_a_SOURCES += libblock/src/bdpart-create.c
>> librtemscpu_a_SOURCES += libblock/src/bdpart-dump.c
>> -librtemscpu_a_SOURCES += libblock/src/bdpart-mount.c
>> librtemscpu_a_SOURCES += libblock/src/bdpart-read.c
>> librtemscpu_a_SOURCES += libblock/src/bdpart-register.c

Re: Need help debugging sp16.exe

[Richi Dubey]

Hi,

The scheduler doesnt seem to be involved in rtems_task_exit. I believe the
scheduler is doing something wrong during the execution of rtems_yield for
TA1.  Is it related to isr_level? Please find the stacktrace below for
execution of TA5 after TA1 yields:

(gdb)
0x00103c28 in Task5 (argument=0) at
/home/richi/quick-start/src/rtems/c/src/../../testsuites/sptests/sp16/task5.c:53
53  status = rtems_region_get_segment(
(gdb)
60  puts_nocr( "TA5 - got segment from region 1 - " );
(gdb) ni
0x00103c2e 60  puts_nocr( "TA5 - got segment from region 1 - " );
(gdb)
0x00103c32 60  puts_nocr( "TA5 - got segment from region 1 - " );
(gdb)
61  Put_address_from_area_1( segment_address_2 );
(gdb)
0x00103c38 61  Put_address_from_area_1( segment_address_2 );
(gdb)
0x00103c3a 61  Put_address_from_area_1( segment_address_2 );
(gdb)
0x00103c3e 61  Put_address_from_area_1( segment_address_2 );
(gdb)
0x00103c42 61  Put_address_from_area_1( segment_address_2 );
(gdb)
0x00103c44 61  Put_address_from_area_1( segment_address_2 );
(gdb)
0x00103c46 61  Put_address_from_area_1( segment_address_2 );
(gdb)
0x00103c4a 61  Put_address_from_area_1( segment_address_2 );
(gdb)
0x00103c4e 61  Put_address_from_area_1( segment_address_2 );
(gdb)
62  new_line;
(gdb)
0x00103c56 62  new_line;
(gdb)
0x00103c5a 62  new_line;
(gdb)
64  status = rtems_region_return_segment( Region_id[ 1 ], segment_address_2
);
(gdb)
0x00103c62 64  status = rtems_region_return_segment( Region_id[ 1 ],
segment_address_2 );
(gdb) ni
0x00103c66 64  status = rtems_region_return_segment( Region_id[ 1 ],
segment_address_2 );
(gdb)
0x00103c68 64  status = rtems_region_return_segment( Region_id[ 1 ],
segment_address_2 );
(gdb)
0x00103c6a 64  status = rtems_region_return_segment( Region_id[ 1 ],
segment_address_2 );
(gdb)
0x00103c6c 64  status = rtems_region_return_segment( Region_id[ 1 ],
segment_address_2 );
(gdb)
0x00103c6e 64  status = rtems_region_return_segment( Region_id[ 1 ],
segment_address_2 );
(gdb)
0x00103c72 64  status = rtems_region_return_segment( Region_id[ 1 ],
segment_address_2 );
(gdb)
65  puts_nocr(
(gdb)
0x00103c78 65  puts_nocr(
(gdb)
0x00103c7c 65  puts_nocr(
(gdb)
68  Put_address_from_area_1( segment_address_2 );
(gdb)
0x00103c82 68  Put_address_from_area_1( segment_address_2 );
(gdb)
0x00103c84 68  Put_address_from_area_1( segment_address_2 );
(gdb)
0x00103c88 68  Put_address_from_area_1( segment_address_2 );
(gdb)
0x00103c8c 68  Put_address_from_area_1( segment_address_2 );
(gdb)
0x00103c8e 68  Put_address_from_area_1( segment_address_2 );
(gdb)
0x00103c90 68  Put_address_from_area_1( segment_address_2 );
(gdb)
0x00103c94 68  Put_address_from_area_1( segment_address_2 );
(gdb)
0x00103c98 68  Put_address_from_area_1( segment_address_2 );
(gdb)
69  new_line;
(gdb)
0x00103ca0 69  new_line;
(gdb)
0x00103ca4 69  new_line;
(gdb)
71  puts( "TA5 - rtems_task_exit" );
(gdb)
0x00103cac 71  puts( "TA5 - rtems_task_exit" );
(gdb)
0x00103cb0 71  puts( "TA5 - rtems_task_exit" );
(gdb)
72  rtems_task_exit();
(gdb) si
rtems_task_exit () at
/home/richi/quick-start/src/rtems/c/src/../../cpukit/rtems/src/taskexit.c:23
23 {
(gdb) ni
0x0010ab42 23 {
(gdb)
0x0010ab44 23 {
(gdb)
27  cpu_self = _Thread_Dispatch_disable();
(gdb)
0x0010ab4a 27  cpu_self = _Thread_Dispatch_disable();
(gdb)
28  executing = _Per_CPU_Get_executing( cpu_self );
(gdb)
0x0010ab4e 28  executing = _Per_CPU_Get_executing( cpu_self );
(gdb)
0x0010ab52 28  executing = _Per_CPU_Get_executing( cpu_self );
(gdb)
30  _Thread_Exit(
(gdb) si
0x0010ab56 30  _Thread_Exit(
(gdb)
0x0010ab58 30  _Thread_Exit(
(gdb)
0x0010ab5a 30  _Thread_Exit(
(gdb)
_Thread_Exit (executing=0x2057c0 <_Per_CPU_Information>,
set=THREAD_LIFE_PROTECTED, exit_value=0x0) at
/home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/threadrestart.c:537
537 {
(gdb) ni
0x00110da4 537 {
(gdb)
0x00110da6 537 {
(gdb)
0x00110da8 537 {
(gdb)
0x00110daa 537 {
(gdb)
0x00110dac 537 {
(gdb)
548  _Thread_State_acquire( executing, &lock_context );
(gdb)
0x00110db2 548  _Thread_State_acquire( executing, &lock_context );
(gdb)
0x00110db4 548  _Thread_State_acquire( executing, &lock_context );
(gdb)
0x00110db6 548  _Thread_State_acquire( executing, &lock_context );
(gdb)
549  _Thread_Set_exit_value( executing, exit_value );
(gdb)
0x00110dbc 549  _Thread_Set_exit_value( executing, exit_value );
(gdb)
0x00110dbe 549  _Thread_Set_exit_value( executing, exit_value );
(gdb)
550  _Thread_Change_life_locked(
(gdb) si
0x00110dc4 550  _Thread_Change_life_locked(
(gdb)
0x00110dc6 550  _Thread_Change_life_locked(
(gdb)
0x00110dc8 550  _Thread_Change_life_locked(
(gdb)
0x00110dca 550  _Thread_Change_life_locked(
(gdb)
_Thread_Change_life_locked (the_thread=0x1101e5 <_Thread_State_acquire+28>,
clear=(unknown: 2158976), set=(THREAD_LIFE_CHANGE_DEFERRED |
THREAD_LIFE_DETACHED | unknown: 2103264), ignore=(THREAD_LIFE_TERMINATING |
unknown: 2159008)) at
/home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/threadrestart.c:245
245 {
(gdb)
0x001109bc 245 {
(gd

[PATCH rtems-libbsd] wpa: Fix multiple definition of `hmac_md5`

[Christian Mauderer]

hmac_md5 is defined in dhcpcd and in wpa supplicant.
---
 freebsd/contrib/wpa/src/crypto/md5.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/freebsd/contrib/wpa/src/crypto/md5.h 
b/freebsd/contrib/wpa/src/crypto/md5.h
index 33f8426c..48afb955 100644
--- a/freebsd/contrib/wpa/src/crypto/md5.h
+++ b/freebsd/contrib/wpa/src/crypto/md5.h
@@ -11,6 +11,10 @@
 
 #define MD5_MAC_LEN 16
 
+#ifdef __rtems__
+#define hmac_md5_vectorwpa_hmac_md5_vector
+#define hmac_md5   wpa_hmac_md5
+#endif /* __rtems__ */
 int hmac_md5_vector(const u8 *key, size_t key_len, size_t num_elem,
const u8 *addr[], const size_t *len, u8 *mac);
 int hmac_md5(const u8 *key, size_t key_len, const u8 *data, size_t data_len,
-- 
2.28.0

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS 5.1 pc686 BSP malloc_info problem?

[Alan Cudmore]

After doing a lot of tracing through my application, it looks like
malloc_info works fine before we start our cFS application, but it
blocks after the cFS is initialized. This suggests some sort of memory
corruption.
I started by instrumenting our code to call malloc info during various
stages of application initialization, and finally narrowed it down to
the code where we create a RAM Disk and format it with RFS.
(skipping a bunch of other malloc based troubleshooting.. )
After I followed the issue into the RFS init, I was able to narrow
down the place where malloc_info stopped working to here:
https://git.rtems.org/rtems/tree/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c?h=5#n637
During the RFS format process.
In this section of the code, the size variable is 0, meaning it will
exit the for loop and then return from the function, but it increments
the "search_map" variable and writes to memory through the pointer one
more time before exiting the loop and function. It's at this point
where malloc_info starts blocking.

It seems to me that this if block should be skipped when size == 0. I
tried that and the malloc_info issue seems to be fixed.

Is this an RFS bug writing into other memory, or is this last write
needed before the function updates?

If this looks like a bug, should I write a ticket and provide a patch?

Thanks,
Alan

On Mon, Oct 5, 2020 at 1:06 PM Joel Sherrill  wrote:
>
>
>
> On Mon, Oct 5, 2020 at 11:07 AM Alan Cudmore  wrote:
>>
>> I built the tools shortly after the announced 5.1 release. I'm using
>> the 5.1 branches for everything.
>> But some additional info..I built the full testsuite, and ran the
>> malloctest with no problems. It calls malloc_info a couple of times.
>>
>> I also compiled my RTEMS Kernel Image (RKI) for this BSP and the
>> "malloc info" shell command works on that. This is the same way I
>> tested the sparc/leon3 BSP so at least that is consistent.
>>
>> This has to come down to a configuration issue for the application
>> (core flight system pc-rtems test platform)
>> I'm going to check over the configuration options and compiler options
>> used. It will most likely be another case of user error, which I
>> prefer!
>
>
> This wouldn't be a user error. Just a case where the bug was found
> after the release. :)
>
> --joel
>>
>>
>> Thanks,
>> Alan
>>
>> On Mon, Oct 5, 2020 at 11:58 AM Joel Sherrill  wrote:
>> >
>> >
>> >
>> > On Mon, Oct 5, 2020 at 10:34 AM Gedare Bloom  wrote:
>> >>
>> >> This is an SMP related bug?  Can you send the rtems configure command,
>> >> and the qemu run command?
>> >>
>> >> It might also help to know the number of tasks and their priorities.
>> >> The CONFIGURE* macros might also help.
>> >>
>> >> My first guess is that the lock primitive is somehow broken in the
>> >> pc686, maybe it gets caught in a buggy CAS/TAS loop? It would help if
>> >> you can narrow down the task spinning to a particular section of code
>> >> and send the disassembly (or file/line if it is in RTEMS)
>> >
>> >
>> > Hmmm.. When did you build your i386 tools? git says 9/19 for the last 
>> > change
>> > but it was very much likely a few days after that when I pushed it.
>> >
>> > --joel
>> >>
>> >>
>> >> On Sun, Oct 4, 2020 at 2:06 PM Alan Cudmore  
>> >> wrote:
>> >> >
>> >> > Hi,
>> >> > I have a problem in RTEMS 5.1 where the pc686 running on QEMU seems to
>> >> > block or spin when trying to acquire a lock for the malloc_info call.
>> >> > The CPU utilization goes up to 100 (on the QEMU host) leading me to
>> >> > think the calling task is spinning waiting on the lock. Tasks with
>> >> > lower priority than the calling task stop running as well. I also get
>> >> > this problem when running the "malloc info" shell command.
>> >> > I don't see this problem with the leon3 BSP built from the same source
>> >> > tree and executed on QEMU.
>> >> >
>> >> > Is there an SMP related initialization or perhaps QEMU option I might
>> >> > be missing? I can run the same code without problems on the RTEMS 4.11
>> >> > release (same QEMU binary and QEMU options)
>> >> >
>> >> > Thanks,
>> >> > Alan
>> >> > ___
>> >> > devel mailing list
>> >> > devel@rtems.org
>> >> > http://lists.rtems.org/mailman/listinfo/devel
>> >> ___
>> >> devel mailing list
>> >> devel@rtems.org
>> >> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

waf for RTEMS Applications

[Joel Sherrill]

Hi

I decided to try this out today. The users manual is pretty good but has
some spots which lean to 5 and haven't been updated. Also mentions updating
your PATH early and isn't really needed until rtems-run can't find qemu. :)

My big questions are from this exercise are:

+ How would one use this without using git

+ Without using git submodules?

+ What if I didn't want any external network references? I don't see waf or
rtems_waf in the release image.

+ rtems-run's output seemed cryptic when it couldn't find the simulator to
run.

It was easy enough after accounting for odd 5/6 items, misc issues that are
OK for me to encounter but not a starting user, and the example worked. I
am just putting on my user hat as best I can to comment on the process.

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel