Re: [PATCH] Updated docs to use the standalone SIS simulator, instead of GDB inbuilt SIS for the erc32 BSP.

[Niteesh]

Just a reminder, it's almost been a week since I sent the patch. I also
sent it a month ago, but it slipped from everyone's eyes.

On Thu, Jan 2, 2020 at 9:45 PM Gedare Bloom  wrote:

> looks good to me.
>
> On Fri, Dec 27, 2019 at 5:02 AM G S Niteesh  wrote:
> >
> > ---
> >  user/start/bsp-test.rst |   4 +-
> >  user/tools/tester.rst   | 144 
> >  2 files changed, 132 insertions(+), 16 deletions(-)
> >
> > diff --git a/user/start/bsp-test.rst b/user/start/bsp-test.rst
> > index 5278375..aefeeb9 100644
> > --- a/user/start/bsp-test.rst
> > +++ b/user/start/bsp-test.rst
> > @@ -21,7 +21,7 @@ Just run this command:
> >  .. code-block:: none
> >
> >  cd $HOME/quick-start/build/b-erc32
> > -rtems-test --rtems-bsp=erc32
> --rtems-tools=$HOME/quick-start/rtems/5 .
> > +rtems-test --rtems-bsp=erc32-sis
> --rtems-tools=$HOME/quick-start/rtems/5 .
> >
> >  This command should output something like this (omitted lines are
> denoted by
> >  ...).  In this output the base directory :file:`$HOME/quick-start` was
> replaced
> > @@ -30,7 +30,7 @@ by ``$BASE``.
> >  .. code-block:: none
> >
> >  RTEMS Testing - Tester, 5.0.not_released
> > - Command Line: $BASE/rtems/5/bin/rtems-test --rtems-bsp=erc32
> --rtems-tools=$BASE/rtems/5 .
> > + Command Line: $BASE/rtems/5/bin/rtems-test --rtems-bsp=erc32-sis
> --rtems-tools=$BASE/rtems/5 .
> >   Python: 2.7.15 (default, Jan 10 2019, 01:14:47) [GCC 4.2.1
> Compatible FreeBSD Clang 6.0.1 (tags/RELEASE_601/final 335540)]
> >  Host: FreeBSD-12.0-RELEASE-p2-amd64-64bit-ELF (FreeBSD
> Build_FreeBSD12 12.0-RELEASE-p2 FreeBSD 12.0-RELEASE-p2 GENERIC amd64 amd64)
> >  [  1/589] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   |
> sparc/erc32: dhrystone.exe
> > diff --git a/user/tools/tester.rst b/user/tools/tester.rst
> > index 609384b..c3c3fe2 100644
> > --- a/user/tools/tester.rst
> > +++ b/user/tools/tester.rst
> > @@ -109,39 +109,155 @@ the tests. Using the run with the ERC32 BSP the
> command is:
> >
> >  The run command is the GDB simulator without the GDB part.
> >
> > -Running the example using GDB:
> > +Running the example using SIS:
> > +
> > +.. code-block:: none
> > +
> > +$ sparc-rtems5-sis
> sparc-rtems5/c/erc32/testsuites/samples/hello/hello.exe
> > +SIS - SPARC/RISCV instruction simulator 2.20,  copyright Jiri
> Gaisler 2019
> > +Bug-reports to j...@gaisler.se
> > +ERC32 emulation enabled
> > +
> > +Loaded sparc-rtems5/c/erc32/testsuites/samples/hello.exe, entry
> 0x0200
> > +
> > +sis> run
> > +
> > +
> > +*** BEGIN OF TEST HELLO WORLD ***
> > +*** TEST VERSION: 5.0.0.c6d8589bb00a9d2a5a094c68c90290df1dc44807
> > +*** TEST STATE: EXPECTED-PASS
> > +*** TEST BUILD: RTEMS_POSIX_API
> > +*** TEST TOOLS: 7.5.0 20191114 (RTEMS 5, RSB
> 83fa79314dd87c0a8c78fd642b2cea3138be8dd6, Newlib 3e24fbf6f)
> > +Hello World
> > +
> > +*** END OF TEST HELLO WORLD ***
> > +
> > +
> > +*** FATAL ***
> > +fatal source: 0 (INTERNAL_ERROR_CORE)
> > +fatal code: 5 (INTERNAL_ERROR_THREAD_EXITTED)
> > +RTEMS version: 5.0.0.c6d8589bb00a9d2a5a094c68c90290df1dc44807
> > +RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB
> 83fa79314dd87c0a8c78fd642b2cea3138be8dd6, Newlib 3e24fbf6f)
> > +executing thread ID: 0x08a010001
> > +executing thread name: UI1
> > +cpu 0 in error mode (tt = 0x101)
> > +116401  02009ae0:  91d02000   ta  0x0
> > +
> > +sis> q
> > +
> > +The examples can also be run using GDB with SIS as the backend. SIS can
> be connected to
> > +gdb through a network socket using the gdb remote interface.
> > +
> > +Either start SIS with ``-gdb``, or issue the ``gdb`` command inside
> SIS, and connect
> > +gdb with ``target remote:1234``. The default port is ``1234``, the port
> can be changed
> > +using the ``-port`` option.
> > +
> > +Open a terminal and issue the command:
> > +
> > +.. code-block:: none
> > +
> > +$ sparc-rtems5-sis -gdb
> > +SIS - SPARC/RISCV instruction simulator 2.20,  copyright Jiri
> Gaisler 2019
> > +Bug-reports to j...@gaisler.se
> > +ERC32 emulation enabled
> > +
> > +gdb: listening on port 1234
> > +
> > +Now open another terminal and issue the command:
> >
> >  .. code-block:: none
> >
> >  $ sparc-rtems5-gdb
> sparc-rtems5/c/erc32/testsuites/samples/hello/hello.exe
> > -GNU gdb (GDB) 7.12
> > -Copyright (C) 2016 Free Software Foundation, Inc.
> > +GNU gdb (GDB) 8.3
> > +Copyright (C) 2019 Free Software Foundation, Inc.
> >  License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.html>
> >  This is free software: you are free to change and redistribute it.
> > -There is NO WARRANTY, to the extent permitted by law.  Type "show
> copying"
> > -and "show warranty" for details.
> > +There is NO WARRANTY, to the extent permitted by law.
> > +Type "show copying" and "show warranty" for details.
> >  This GDB was 

Re: What do you want to study in GSOC 2020?

[Niteesh]

I problem was in uart_probe, and console_select. I totally forgot about
console_select
changing back to pl011. The application starts without any issues
https://ibb.co/PZY5BWr
but *rtems_shell_wait_for_input *return unsuccessful, maybe it fails
because it calls
ioctl and I haven't provided a proper handler, what do you think?
Now, since I know everything works I'll add in a proper AUX driver(ns16550)
and test it again.
And also if you remember, there was this issue of printing garbage and
FATAL_SOURCE_EXCEPTION
while running examples in qemu, I have run the examples multiple times on
the board and no issues till now.

On Sat, Jan 4, 2020 at 8:47 AM Niteesh  wrote:

> On Sat, Jan 4, 2020 at 3:34 AM Christian Mauderer 
> wrote:
>
>> On 03/01/2020 20:17, Niteesh wrote:
>> > Finally, I am able to load IMAGES into Rpi3 using u-boot. But didn't
>> > check whether FDT works. I added the AUX driver from my bare-metal
>> > project for testing. I'll replace it with NS16550 soon.
>> > I loaded the fileio example and it prints the board information. Below
>> > is the link to the screenshot
>> > https://ibb.co/cJbFHqz
>>
>> That's a great start.
>>
>> > But it's stuck there, maybe an exception was raised because I didn't
>> > modify the address for another device but not sure! Can you think of
>> > something
>> > which could have caused it?
>>
>> Exceptions should print an exception frame. So I'm not sure whether that
>> is the case. Do you have some JTAG adapter that would work with OpenOCD
>> or simmilar?
>>
> I dont have a JTAG. I going to fallback to printfs. I going to stick
> printf in various places
> and see where it hangs.
> Do you have any other ideas? Can we use GDB?
>
>> >
>> >
>> > On Fri, Jan 3, 2020 at 11:07 PM Niteesh > > > wrote:
>> >
>> > On Fri, Jan 3, 2020 at 7:30 PM Christian Mauderer
>> > mailto:l...@c-mauderer.de>> wrote:
>> >
>> > On 03/01/2020 13:49, Niteesh wrote:
>> > > I have gone through previous year works and selected a few
>> > topics which
>> > > I found
>> > > interesting.
>> > > 1. Basic Support for Trace Compass #3696
>> > > .
>> >
>> > A basic support has been added last year and Sebastian extended
>> that
>> > quite a bit because we had a customer who needed it. I'm not
>> > sure what
>> > the current state is and whether there are tasks left that could
>> > be done
>> > in a GSoC project.
>> >
>> > > 2. RTEMS testing tool project #2927
>> > .
>> >
>> > No idea what the status is. Chris?
>> >
>> > > 3. Beagle BSP: Add a flattened device tree based
>> > initialization #3784
>> > > .
>> >
>> > That one is open. It would include adding some infrastructure
>> > for fdt
>> > based drivers. In theory you could do the same project for
>> > raspberry or
>> > any other board.
>> >
>> > Please note Gedares comment from the previous mail:
>> >
>> > > Infrastructure projects are nice (FDT, dynamic linking,
>> > debugger,
>> > > tracer) but need to be clearly defined ahead of time and
>> > discussed
>> > > thoroughly with the community, or you risk ending up in
>> > the "long
>> > > tedious discussions" when you should be coding.
>> >
>> >
>> > > 4. BSPs for Simulators #2903
>> > .
>> >
>> > That's always open.
>> >
>> > Some simulators are easy because the board is already supported
>> > and you
>> > only have to find out how to start it. For these a tester
>> > integration is
>> > a good target. But most likely that's only small stuff and
>> should be
>> > only one part of a project.
>> >
>> > Other simulators are not supported yet. In that case you have to
>> > write
>> > some drivers which can be a good project size.
>> >
>> > > 5. Improve the Raspberry Pi BSP #2899
>> > .
>> >
>> > You already noted: The raspberry BSP isn't in the best shape. So
>> > it's
>> > quite open for improvement.
>> >
>> > I think that there is still some work getting it to run again.
>> > We don't
>> > have something with "*bcm*" in libbsd yet so most likely USB and
>> > Ethernet are not working yet. Could be still still be a nice
>> task.
>> >
>> >
>> > Why don't we use the driver's from other sources as a reference and
>> > create our
>> > own, for USB https://github.com/Chadderz121/csud this could be
>> used as a
>> > reference, U-boot, and Linux are good sources too. But is it worth
>> > the effort for a
>> > BSP like raspberry pi? There 

Re: What do you want to study in GSOC 2020?

[Niteesh]

On Sat, Jan 4, 2020 at 3:34 AM Christian Mauderer 
wrote:

> On 03/01/2020 20:17, Niteesh wrote:
> > Finally, I am able to load IMAGES into Rpi3 using u-boot. But didn't
> > check whether FDT works. I added the AUX driver from my bare-metal
> > project for testing. I'll replace it with NS16550 soon.
> > I loaded the fileio example and it prints the board information. Below
> > is the link to the screenshot
> > https://ibb.co/cJbFHqz
>
> That's a great start.
>
> > But it's stuck there, maybe an exception was raised because I didn't
> > modify the address for another device but not sure! Can you think of
> > something
> > which could have caused it?
>
> Exceptions should print an exception frame. So I'm not sure whether that
> is the case. Do you have some JTAG adapter that would work with OpenOCD
> or simmilar?
>
I dont have a JTAG. I going to fallback to printfs. I going to stick printf
in various places
and see where it hangs.
Do you have any other ideas? Can we use GDB?

> >
> >
> > On Fri, Jan 3, 2020 at 11:07 PM Niteesh  > > wrote:
> >
> > On Fri, Jan 3, 2020 at 7:30 PM Christian Mauderer
> > mailto:l...@c-mauderer.de>> wrote:
> >
> > On 03/01/2020 13:49, Niteesh wrote:
> > > I have gone through previous year works and selected a few
> > topics which
> > > I found
> > > interesting.
> > > 1. Basic Support for Trace Compass #3696
> > > .
> >
> > A basic support has been added last year and Sebastian extended
> that
> > quite a bit because we had a customer who needed it. I'm not
> > sure what
> > the current state is and whether there are tasks left that could
> > be done
> > in a GSoC project.
> >
> > > 2. RTEMS testing tool project #2927
> > .
> >
> > No idea what the status is. Chris?
> >
> > > 3. Beagle BSP: Add a flattened device tree based
> > initialization #3784
> > > .
> >
> > That one is open. It would include adding some infrastructure
> > for fdt
> > based drivers. In theory you could do the same project for
> > raspberry or
> > any other board.
> >
> > Please note Gedares comment from the previous mail:
> >
> > > Infrastructure projects are nice (FDT, dynamic linking,
> > debugger,
> > > tracer) but need to be clearly defined ahead of time and
> > discussed
> > > thoroughly with the community, or you risk ending up in
> > the "long
> > > tedious discussions" when you should be coding.
> >
> >
> > > 4. BSPs for Simulators #2903
> > .
> >
> > That's always open.
> >
> > Some simulators are easy because the board is already supported
> > and you
> > only have to find out how to start it. For these a tester
> > integration is
> > a good target. But most likely that's only small stuff and
> should be
> > only one part of a project.
> >
> > Other simulators are not supported yet. In that case you have to
> > write
> > some drivers which can be a good project size.
> >
> > > 5. Improve the Raspberry Pi BSP #2899
> > .
> >
> > You already noted: The raspberry BSP isn't in the best shape. So
> > it's
> > quite open for improvement.
> >
> > I think that there is still some work getting it to run again.
> > We don't
> > have something with "*bcm*" in libbsd yet so most likely USB and
> > Ethernet are not working yet. Could be still still be a nice
> task.
> >
> >
> > Why don't we use the driver's from other sources as a reference and
> > create our
> > own, for USB https://github.com/Chadderz121/csud this could be used
> as a
> > reference, U-boot, and Linux are good sources too. But is it worth
> > the effort for a
> > BSP like raspberry pi? There is also a c++ bare metal environment
> > called circle
> > https://github.com/rsta2/circle which supports
> > USB(https://github.com/rsta2/uspi)
> > and ethernet.
> >
> > Christian, can you check out
> > this https://github.com/0xabu/qemu/wiki it partially supports
> > USB, can you give it a try?
> >
> >
> > With the difficulties getting it to run on RPi3 or RPi4 that
> > might could
> > be also a project. It seems that they are aarch64. Also I was
> quite
> > surprised about it I didn't find a aarch64 BSP. So that would be
> > a new port.
> >
> >
> > Rpi3 looks for kernel7.img if it finds one, it boots into 32bit
> > mode, so if the, offset is the only difference
> > between rpi2 and rpi3 it should boot 

Re: What do you want to study in GSOC 2020?

[Niteesh]

On Sat, Jan 4, 2020 at 1:29 AM Christian Mauderer 
wrote:

> On 03/01/2020 18:37, Niteesh wrote:
> > On Fri, Jan 3, 2020 at 7:30 PM Christian Mauderer  > > wrote:
> >
> > On 03/01/2020 13:49, Niteesh wrote:
> > > I have gone through previous year works and selected a few topics
> > which
> > > I found
> > > interesting.
> > > 1. Basic Support for Trace Compass #3696
> > > .
> >
> > A basic support has been added last year and Sebastian extended that
> > quite a bit because we had a customer who needed it. I'm not sure
> what
> > the current state is and whether there are tasks left that could be
> done
> > in a GSoC project.
> >
> > > 2. RTEMS testing tool project #2927
> > .
> >
> > No idea what the status is. Chris?
> >
> > > 3. Beagle BSP: Add a flattened device tree based
> initialization #3784
> > > .
> >
> > That one is open. It would include adding some infrastructure for fdt
> > based drivers. In theory you could do the same project for raspberry
> or
> > any other board.
> >
> > Please note Gedares comment from the previous mail:
> >
> > > Infrastructure projects are nice (FDT, dynamic linking,
> debugger,
> > > tracer) but need to be clearly defined ahead of time and
> discussed
> > > thoroughly with the community, or you risk ending up in the
> "long
> > > tedious discussions" when you should be coding.
> >
> >
> > > 4. BSPs for Simulators #2903  >.
> >
> > That's always open.
> >
> > Some simulators are easy because the board is already supported and
> you
> > only have to find out how to start it. For these a tester
> integration is
> > a good target. But most likely that's only small stuff and should be
> > only one part of a project.
> >
> > Other simulators are not supported yet. In that case you have to
> write
> > some drivers which can be a good project size.
> >
> > > 5. Improve the Raspberry Pi BSP #2899
> > .
> >
> > You already noted: The raspberry BSP isn't in the best shape. So it's
> > quite open for improvement.
> >
> > I think that there is still some work getting it to run again. We
> don't
> > have something with "*bcm*" in libbsd yet so most likely USB and
> > Ethernet are not working yet. Could be still still be a nice task.
> >
> >
> > Why don't we use the driver's from other sources as a reference and
> > create our
> > own, for USB https://github.com/Chadderz121/csud this could be used as a
> > reference, U-boot, and Linux are good sources too. But is it worth the
> > effort for a
> > BSP like raspberry pi? There is also a c++ bare metal environment called
> > circle
> > https://github.com/rsta2/circle which supports
> > USB(https://github.com/rsta2/uspi)
> > and ethernet.
>
> The reason for using libbsd is that its already there and therefore its
> easy to add for all chips that are supported (and raspberry is supported
> in FreeBSD).
>
> U-Boot and Linux can't be used most of the time due to license issues.
> Both have a GPL license which isn't usable in a lot of RTEMS
> applications (industrial, automotive, ...). There shouldn't be any GPL
> code in the core repository and we tend to avoid libraries if there are
> alternatives.
>
> >
> > Christian, can you check out this https://github.com/0xabu/qemu/wiki it
> > partially supports
> > USB, can you give it a try?
>
> RTEMS with libbsd doesn't yet have a USB support committed for the
> raspberry. Do you mean try it with Linux or Windows? Did you already
> test something? What do you want to find out?
>
Can you build this version of qemu and see if USB works properly? you don't
have to use RTEMS, you can use a lightweight linux distro and see if you can
talk to a usb device in qemu.

> >
> >
> > With the difficulties getting it to run on RPi3 or RPi4 that might
> could
> > be also a project. It seems that they are aarch64. Also I was quite
> > surprised about it I didn't find a aarch64 BSP. So that would be a
> > new port.
> >
> >
> > Rpi3 looks for kernel7.img if it finds one, it boots into 32bit mode, so
> > if the, offset is the only difference
> > between rpi2 and rpi3 it should boot without any issues I'll try adding
> > the AUX uart driver
> > and see if it boots on Rpi3.
>
> Don't forget to add a "kernel_address=0x0020" line if you use the
> linker file like it is currently there in RTEMS.
>
For some reason, I couldn't get it to boot using the default bootloader. I
will
be using u-boot since it also makes it easier for me to upload the kernel
images.

> >
> > I would also like to discuss about the FDT infrastructure for RTEMS, I
> > would like to know what are
> > the requirements, what could be expected in a short 

Re: What do you want to study in GSOC 2020?

[Christian Mauderer]

On 03/01/2020 20:17, Niteesh wrote:
> Finally, I am able to load IMAGES into Rpi3 using u-boot. But didn't
> check whether FDT works. I added the AUX driver from my bare-metal
> project for testing. I'll replace it with NS16550 soon.
> I loaded the fileio example and it prints the board information. Below
> is the link to the screenshot
> https://ibb.co/cJbFHqz

That's a great start.

> But it's stuck there, maybe an exception was raised because I didn't
> modify the address for another device but not sure! Can you think of
> something
> which could have caused it?

Exceptions should print an exception frame. So I'm not sure whether that
is the case. Do you have some JTAG adapter that would work with OpenOCD
or simmilar?

> 
> 
> On Fri, Jan 3, 2020 at 11:07 PM Niteesh  > wrote:
> 
> On Fri, Jan 3, 2020 at 7:30 PM Christian Mauderer
> mailto:l...@c-mauderer.de>> wrote:
> 
> On 03/01/2020 13:49, Niteesh wrote:
> > I have gone through previous year works and selected a few
> topics which
> > I found
> > interesting.
> > 1. Basic Support for Trace Compass #3696
> > .
> 
> A basic support has been added last year and Sebastian extended that
> quite a bit because we had a customer who needed it. I'm not
> sure what
> the current state is and whether there are tasks left that could
> be done
> in a GSoC project.
> 
> > 2. RTEMS testing tool project #2927
> .
> 
> No idea what the status is. Chris?
> 
> > 3. Beagle BSP: Add a flattened device tree based
> initialization #3784
> > .
> 
> That one is open. It would include adding some infrastructure
> for fdt
> based drivers. In theory you could do the same project for
> raspberry or
> any other board.
> 
> Please note Gedares comment from the previous mail:
> 
> >     Infrastructure projects are nice (FDT, dynamic linking,
> debugger,
> >     tracer) but need to be clearly defined ahead of time and
> discussed
> >     thoroughly with the community, or you risk ending up in
> the "long
> >     tedious discussions" when you should be coding.
> 
> 
> > 4. BSPs for Simulators #2903
> .
> 
> That's always open.
> 
> Some simulators are easy because the board is already supported
> and you
> only have to find out how to start it. For these a tester
> integration is
> a good target. But most likely that's only small stuff and should be
> only one part of a project.
> 
> Other simulators are not supported yet. In that case you have to
> write
> some drivers which can be a good project size.
> 
> > 5. Improve the Raspberry Pi BSP #2899
> .
> 
> You already noted: The raspberry BSP isn't in the best shape. So
> it's
> quite open for improvement.
> 
> I think that there is still some work getting it to run again.
> We don't
> have something with "*bcm*" in libbsd yet so most likely USB and
> Ethernet are not working yet. Could be still still be a nice task.
> 
> 
> Why don't we use the driver's from other sources as a reference and
> create our
> own, for USB https://github.com/Chadderz121/csud this could be used as a
> reference, U-boot, and Linux are good sources too. But is it worth
> the effort for a
> BSP like raspberry pi? There is also a c++ bare metal environment
> called circle
> https://github.com/rsta2/circle which supports
> USB(https://github.com/rsta2/uspi)
> and ethernet.
> 
> Christian, can you check out
> this https://github.com/0xabu/qemu/wiki it partially supports
> USB, can you give it a try?
> 
> 
> With the difficulties getting it to run on RPi3 or RPi4 that
> might could
> be also a project. It seems that they are aarch64. Also I was quite
> surprised about it I didn't find a aarch64 BSP. So that would be
> a new port.
> 
>  
> Rpi3 looks for kernel7.img if it finds one, it boots into 32bit
> mode, so if the, offset is the only difference
> between rpi2 and rpi3 it should boot without any issues I'll try
> adding the AUX uart driver
> and see if it boots on Rpi3.
> 
> I would also like to discuss about the FDT infrastructure for RTEMS,
> I would like to know what are
> the requirements, what could be expected in a short span of 3months,
> what could be used as a reference
> and so on.
> 
> Note that an aarch64 port would most likely be observed with
> argus eyes
> 

Re: What do you want to study in GSOC 2020?

[Christian Mauderer]

On 03/01/2020 18:37, Niteesh wrote:
> On Fri, Jan 3, 2020 at 7:30 PM Christian Mauderer  > wrote:
> 
> On 03/01/2020 13:49, Niteesh wrote:
> > I have gone through previous year works and selected a few topics
> which
> > I found
> > interesting.
> > 1. Basic Support for Trace Compass #3696
> > .
> 
> A basic support has been added last year and Sebastian extended that
> quite a bit because we had a customer who needed it. I'm not sure what
> the current state is and whether there are tasks left that could be done
> in a GSoC project.
> 
> > 2. RTEMS testing tool project #2927
> .
> 
> No idea what the status is. Chris?
> 
> > 3. Beagle BSP: Add a flattened device tree based initialization #3784
> > .
> 
> That one is open. It would include adding some infrastructure for fdt
> based drivers. In theory you could do the same project for raspberry or
> any other board.
> 
> Please note Gedares comment from the previous mail:
> 
> >     Infrastructure projects are nice (FDT, dynamic linking, debugger,
> >     tracer) but need to be clearly defined ahead of time and discussed
> >     thoroughly with the community, or you risk ending up in the "long
> >     tedious discussions" when you should be coding.
> 
> 
> > 4. BSPs for Simulators #2903 .
> 
> That's always open.
> 
> Some simulators are easy because the board is already supported and you
> only have to find out how to start it. For these a tester integration is
> a good target. But most likely that's only small stuff and should be
> only one part of a project.
> 
> Other simulators are not supported yet. In that case you have to write
> some drivers which can be a good project size.
> 
> > 5. Improve the Raspberry Pi BSP #2899
> .
> 
> You already noted: The raspberry BSP isn't in the best shape. So it's
> quite open for improvement.
> 
> I think that there is still some work getting it to run again. We don't
> have something with "*bcm*" in libbsd yet so most likely USB and
> Ethernet are not working yet. Could be still still be a nice task.
> 
> 
> Why don't we use the driver's from other sources as a reference and
> create our
> own, for USB https://github.com/Chadderz121/csud this could be used as a
> reference, U-boot, and Linux are good sources too. But is it worth the
> effort for a
> BSP like raspberry pi? There is also a c++ bare metal environment called
> circle
> https://github.com/rsta2/circle which supports
> USB(https://github.com/rsta2/uspi)
> and ethernet.

The reason for using libbsd is that its already there and therefore its
easy to add for all chips that are supported (and raspberry is supported
in FreeBSD).

U-Boot and Linux can't be used most of the time due to license issues.
Both have a GPL license which isn't usable in a lot of RTEMS
applications (industrial, automotive, ...). There shouldn't be any GPL
code in the core repository and we tend to avoid libraries if there are
alternatives.

> 
> Christian, can you check out this https://github.com/0xabu/qemu/wiki it
> partially supports
> USB, can you give it a try?

RTEMS with libbsd doesn't yet have a USB support committed for the
raspberry. Do you mean try it with Linux or Windows? Did you already
test something? What do you want to find out?

> 
> 
> With the difficulties getting it to run on RPi3 or RPi4 that might could
> be also a project. It seems that they are aarch64. Also I was quite
> surprised about it I didn't find a aarch64 BSP. So that would be a
> new port.
> 
>  
> Rpi3 looks for kernel7.img if it finds one, it boots into 32bit mode, so
> if the, offset is the only difference
> between rpi2 and rpi3 it should boot without any issues I'll try adding
> the AUX uart driver
> and see if it boots on Rpi3.

Don't forget to add a "kernel_address=0x0020" line if you use the
linker file like it is currently there in RTEMS.

> 
> I would also like to discuss about the FDT infrastructure for RTEMS, I
> would like to know what are
> the requirements, what could be expected in a short span of 3months,
> what could be used as a reference
> and so on.

We use a lot of FreeBSD stuff (because it has a matching license and is
quite well designed most of the time). So I would suggest to take a look
how the FDT stuff works in FreeBSD and whether we can adopt or port the
interface - maybe slightly adapted to RTEMS needs like having an early
initialization for the console driver. Porting or implementing that and
adapting a few drivers as proof of concept should be possible in the
given time if you discuss the basic direction before the coding starts.

Please note (for any project you pick): If there is 

Re: What do you want to study in GSOC 2020?

[Niteesh]

Finally, I am able to load IMAGES into Rpi3 using u-boot. But didn't
check whether FDT works. I added the AUX driver from my bare-metal
project for testing. I'll replace it with NS16550 soon.
I loaded the fileio example and it prints the board information. Below
is the link to the screenshot
https://ibb.co/cJbFHqz
But it's stuck there, maybe an exception was raised because I didn't
modify the address for another device but not sure! Can you think of
something
which could have caused it?


On Fri, Jan 3, 2020 at 11:07 PM Niteesh  wrote:

> On Fri, Jan 3, 2020 at 7:30 PM Christian Mauderer 
> wrote:
>
>> On 03/01/2020 13:49, Niteesh wrote:
>> > I have gone through previous year works and selected a few topics which
>> > I found
>> > interesting.
>> > 1. Basic Support for Trace Compass #3696
>> > .
>>
>> A basic support has been added last year and Sebastian extended that
>> quite a bit because we had a customer who needed it. I'm not sure what
>> the current state is and whether there are tasks left that could be done
>> in a GSoC project.
>>
>> > 2. RTEMS testing tool project #2927 <
>> https://devel.rtems.org/ticket/2927>.
>>
>> No idea what the status is. Chris?
>>
>> > 3. Beagle BSP: Add a flattened device tree based initialization #3784
>> > .
>>
>> That one is open. It would include adding some infrastructure for fdt
>> based drivers. In theory you could do the same project for raspberry or
>> any other board.
>>
>> Please note Gedares comment from the previous mail:
>>
>> > Infrastructure projects are nice (FDT, dynamic linking, debugger,
>> > tracer) but need to be clearly defined ahead of time and discussed
>> > thoroughly with the community, or you risk ending up in the "long
>> > tedious discussions" when you should be coding.
>>
>>
>> > 4. BSPs for Simulators #2903 .
>>
>> That's always open.
>>
>> Some simulators are easy because the board is already supported and you
>> only have to find out how to start it. For these a tester integration is
>> a good target. But most likely that's only small stuff and should be
>> only one part of a project.
>>
>> Other simulators are not supported yet. In that case you have to write
>> some drivers which can be a good project size.
>>
>> > 5. Improve the Raspberry Pi BSP #2899 <
>> https://devel.rtems.org/ticket/2899>.
>>
>> You already noted: The raspberry BSP isn't in the best shape. So it's
>> quite open for improvement.
>>
>> I think that there is still some work getting it to run again. We don't
>> have something with "*bcm*" in libbsd yet so most likely USB and
>> Ethernet are not working yet. Could be still still be a nice task.
>>
>
> Why don't we use the driver's from other sources as a reference and create
> our
> own, for USB https://github.com/Chadderz121/csud this could be used as a
> reference, U-boot, and Linux are good sources too. But is it worth the
> effort for a
> BSP like raspberry pi? There is also a c++ bare metal environment called
> circle
> https://github.com/rsta2/circle which supports USB(
> https://github.com/rsta2/uspi)
> and ethernet.
>
> Christian, can you check out this https://github.com/0xabu/qemu/wiki it
> partially supports
> USB, can you give it a try?
>
>>
>> With the difficulties getting it to run on RPi3 or RPi4 that might could
>> be also a project. It seems that they are aarch64. Also I was quite
>> surprised about it I didn't find a aarch64 BSP. So that would be a new
>> port.
>>
>
> Rpi3 looks for kernel7.img if it finds one, it boots into 32bit mode, so
> if the, offset is the only difference
> between rpi2 and rpi3 it should boot without any issues I'll try adding
> the AUX uart driver
> and see if it boots on Rpi3.
>
> I would also like to discuss about the FDT infrastructure for RTEMS, I
> would like to know what are
> the requirements, what could be expected in a short span of 3months, what
> could be used as a reference
> and so on.
>
> Note that an aarch64 port would most likely be observed with argus eyes
>> because it has the potential to be a very important port. But don't let
>> that keep you bag suggesting it.
>>
>> >
>> > I would like to know what are the future plans for these topics.
>> > What is the current status of USB and ethernet in raspberrypi?
>> > Does the beagle BSP require hardware or is it possible to emulate it?
>>
>> I never used an emulator for Beagle. It seems that qemu supported it
>> some when:
>>
>> https://www.cnx-software.com/2011/09/26/beagleboard-emulator-in-ubuntu-with-qemu/
>>
>> But I didn't find it in current qemu. So most likely it would need
>> hardware.
>>
>> > Last year Vijay Kumar Banerjee worked on analysis and generation of gcov
>> > reports.
>> >
>> > On Thu, Jan 2, 2020 at 10:07 PM Gedare Bloom > > > wrote:
>> >
>> > On Mon, Dec 30, 2019 at 2:47 PM Christian Mauderer
>> > mailto:l...@c-mauderer.de>> wrote:

Re: [PATCH] cpukit/libfs: remove more dead code from pipe/fifo.c

[Joel Sherrill]

Looks good to me.

FWIW the one in untar may have to be annotated as ok in the code. They
legitimately see a potential race condition but we should document that
untar should be allowed to run with no interference.

On Fri, Jan 3, 2020, 12:56 PM Gedare Bloom  wrote:

> Dead code identified by Coverity (CID 1456674). The value of ret
> at line 358 is always 0.
> ---
>  cpukit/libfs/src/pipe/fifo.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/cpukit/libfs/src/pipe/fifo.c b/cpukit/libfs/src/pipe/fifo.c
> index 579f118bfd..0a3cbf3d65 100644
> --- a/cpukit/libfs/src/pipe/fifo.c
> +++ b/cpukit/libfs/src/pipe/fifo.c
> @@ -355,8 +355,6 @@ ssize_t pipe_write(
>pipe->waitingWriters ++;
>PIPE_WRITEWAIT(pipe);
>pipe->waitingWriters --;
> -  if (ret != 0)
> -goto out_locked;
>
>if (pipe->Readers == 0) {
>  ret = -EPIPE;
> --
> 2.17.1
>
> ___
> 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] cpukit/libfs: remove more dead code from pipe/fifo.c

[Gedare Bloom]

Dead code identified by Coverity (CID 1456674). The value of ret
at line 358 is always 0.
---
 cpukit/libfs/src/pipe/fifo.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/cpukit/libfs/src/pipe/fifo.c b/cpukit/libfs/src/pipe/fifo.c
index 579f118bfd..0a3cbf3d65 100644
--- a/cpukit/libfs/src/pipe/fifo.c
+++ b/cpukit/libfs/src/pipe/fifo.c
@@ -355,8 +355,6 @@ ssize_t pipe_write(
   pipe->waitingWriters ++;
   PIPE_WRITEWAIT(pipe);
   pipe->waitingWriters --;
-  if (ret != 0)
-goto out_locked;
 
   if (pipe->Readers == 0) {
 ret = -EPIPE;
-- 
2.17.1

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

Re: [PATCH] cpukit/libfs: remove dead code from pipe/fifo.c

[Joel Sherrill]

This looks ok to me.

On Fri, Jan 3, 2020, 12:51 PM Gedare Bloom  wrote:

> Dead code identified by Coverity (CID 1456678). The value of ret
> at line 293 is always 0.
> ---
>  cpukit/libfs/src/pipe/fifo.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/cpukit/libfs/src/pipe/fifo.c b/cpukit/libfs/src/pipe/fifo.c
> index b64c0d95b6..579f118bfd 100644
> --- a/cpukit/libfs/src/pipe/fifo.c
> +++ b/cpukit/libfs/src/pipe/fifo.c
> @@ -290,8 +290,6 @@ ssize_t pipe_read(
>  pipe->waitingReaders ++;
>  PIPE_READWAIT(pipe);
>  pipe->waitingReaders --;
> -if (ret != 0)
> -  goto out_locked;
>}
>
>/* Read chunk bytes */
> --
> 2.17.1
>
> ___
> 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: sptests/sp19/Makefile in git?

[Gedare Bloom]

OK must be something that got leftover on my filesystem during
bootstrapping and switching branches between 4.10 and master. Sorry
about the noise.

On Fri, Jan 3, 2020 at 11:32 AM Joel Sherrill  wrote:
>
>
>
> On Fri, Jan 3, 2020 at 12:22 PM Gedare Bloom  wrote:
>>
>> With master, bootstrap -c deletes testsuites/ada/sptests/sp19/Makefile
>> and shows up in my git status. Is the sp19/Makefile supposed to be
>> under version control or is that a mistake?
>
>
> That has to be a mistake. But I don't see it in git even on 4.10
>
> https://git.rtems.org/rtems/tree/testsuites/sptests/sp19
>
> I wonder where it came from for you.
>
> --joel
>
>
>>
>> ___
>> 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] cpukit/libfs: remove dead code from pipe/fifo.c

[Gedare Bloom]

Dead code identified by Coverity (CID 1456678). The value of ret
at line 293 is always 0.
---
 cpukit/libfs/src/pipe/fifo.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/cpukit/libfs/src/pipe/fifo.c b/cpukit/libfs/src/pipe/fifo.c
index b64c0d95b6..579f118bfd 100644
--- a/cpukit/libfs/src/pipe/fifo.c
+++ b/cpukit/libfs/src/pipe/fifo.c
@@ -290,8 +290,6 @@ ssize_t pipe_read(
 pipe->waitingReaders ++;
 PIPE_READWAIT(pipe);
 pipe->waitingReaders --;
-if (ret != 0)
-  goto out_locked;
   }
 
   /* Read chunk bytes */
-- 
2.17.1

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

[PATCH] bsps/irq: fix resource leak in irq-server.c

[Gedare Bloom]

Resource leak identified by Coverity (CID 1456675). The value
of instances is leaked in case some but not all irq servers are
created. It should be stored in bsp_interrupt_server_instances.
---
 bsps/shared/irq/irq-server.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bsps/shared/irq/irq-server.c b/bsps/shared/irq/irq-server.c
index 0e62d76acb..93e2d144d8 100644
--- a/bsps/shared/irq/irq-server.c
+++ b/bsps/shared/irq/irq-server.c
@@ -539,6 +539,7 @@ rtems_status_code rtems_interrupt_server_initialize(
 
 #if defined(RTEMS_SMP)
   if (cpu_index > 0) {
+bsp_interrupt_server_instances = instances;
 return RTEMS_SUCCESSFUL;
   }
 
-- 
2.17.1

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

Re: sptests/sp19/Makefile in git?

[Joel Sherrill]

On Fri, Jan 3, 2020 at 12:22 PM Gedare Bloom  wrote:

> With master, bootstrap -c deletes testsuites/ada/sptests/sp19/Makefile
> and shows up in my git status. Is the sp19/Makefile supposed to be
> under version control or is that a mistake?
>

That has to be a mistake. But I don't see it in git even on 4.10

https://git.rtems.org/rtems/tree/testsuites/sptests/sp19

I wonder where it came from for you.

--joel



> ___
> 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

sptests/sp19/Makefile in git?

[Gedare Bloom]

With master, bootstrap -c deletes testsuites/ada/sptests/sp19/Makefile
and shows up in my git status. Is the sp19/Makefile supposed to be
under version control or is that a mistake?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 3/3] eng: Rework stakeholder chapter

[Joel Sherrill]

On Fri, Jan 3, 2020, 11:37 AM Gedare Bloom  wrote:

> On Fri, Jan 3, 2020 at 10:07 AM Joel Sherrill  wrote:
> >
> >
> >
> > On Fri, Jan 3, 2020, 6:31 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> >>
> >> ---
> >>  eng/index.rst|  2 +-
> >>  eng/prequalification.rst | 11 +++
> >>  eng/stakeholders.rst | 24 +++-
> >>  3 files changed, 19 insertions(+), 18 deletions(-)
> >>
> >> diff --git a/eng/index.rst b/eng/index.rst
> >> index 094b1e5..3340e34 100644
> >> --- a/eng/index.rst
> >> +++ b/eng/index.rst
> >> @@ -25,8 +25,8 @@ RTEMS Software Engineering (|version|)
> >>
> >>  preface
> >>  mission
> >> -prequalification
> >>  stakeholders
> >> +prequalification
> >>  req-eng
> >>  management
> >>  test-plan
> >> diff --git a/eng/prequalification.rst b/eng/prequalification.rst
> >> index 2004a7c..b591d3f 100644
> >> --- a/eng/prequalification.rst
> >> +++ b/eng/prequalification.rst
> >> @@ -76,3 +76,14 @@ qualification standards. It will maintain
> "scorecards" which
> >>  identify how the RTEMS Project is currently doing when reviewed per
> each
> >>  standard. These will be maintained in the open as community resources
> >>  which will guide the community in improving its infrastructure.
> >> +
> >> +Stakeholder Involvement
> >> +===
> >> +
> >> +Qualification of RTEMS is a specialized activity and only specific
> users
> >> +of RTEMS will complete a formal qualification activity. The RTEMS
> Project
> >> +cannot self-fund this entire activity and requires stakeholder to
> invest
> >> +in an ongoing basis to ensure the any investment they make is
> maintained
> >> +and viable in an ongoing basis. The RTEMS core developers view steady
> >> +support of the qualification effort as necessary to continue to lower
> >> +the overall costs of qualification RTEMS.
> >> diff --git a/eng/stakeholders.rst b/eng/stakeholders.rst
> >> index 222c340..756c462 100644
> >> --- a/eng/stakeholders.rst
> >> +++ b/eng/stakeholders.rst
> >> @@ -1,23 +1,13 @@
> >>  .. SPDX-License-Identifier: CC-BY-SA-4.0
> >>
> >> -.. Copyright (C) 2018.
> >> -.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
> >> +.. Copyright (C) 2020 embedded brains GmbH
> >> +.. Copyright (C) 2018 RTEMS Foundation, The RTEMS Documentation Project
> >>
> >>  RTEMS Stakeholders
> >>  **
> >>
> >> -RTEMS is a community based open source project. All users are treated
> >> -as stakeholders. It is hoped that as stakeholders, users will
> contribute
> >> -to the project, sponsor core developers, and help fund the
> infrastructure
> >> -required to host and manage the project.
> >
> >
> > This paragraph shouldn't disappear. It is true. Qualification is just a
> special case which is way beyond anything else
> >
> It doesn't disappear. He moved some content to above, and some to below.


Thanks. Hard to tell.

Probably a point to emphasize also somewhere more prominent than here.

>
> >> -
> >> -Qualification - Stakeholder Involvement
> >> -===
> >> -
> >> -Qualification of RTEMS is a specialized activity and only specific
> users
> >> -of RTEMS will complete a formal qualification activity. The RTEMS
> Project
> >> -cannot self-fund this entire activity and requires stakeholder to
> invest
> >> -in an ongoing basis to ensure the any investment they make is
> maintained
> >> -and viable in an ongoing basis. The RTEMS core developers view steady
> >> -support of the qualification effort as necessary to continue to lower
> >> -the overall costs of qualification RTEMS.
> >> +You are a potential RTEMS stakeholder.  RTEMS is a community based
> free and open
> >> +source project.  All users are treated as stakeholders.  It is hoped
> that as
> >> +stakeholders, users will contribute to the project, sponsor core
> developers, and
> >> +help fund the infrastructure required to host and manage the project.
> Please
> >> +have a look at the *Support and Contributing* chapter of the
> :r:url:`user`.
> >> --
> >> 2.16.4
> >>
> >> ___
> >> 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: Requirement Document generator tool

[Joel Sherrill]

On Fri, Jan 3, 2020, 4:49 AM Jose Valdez  wrote:

> Hello Gedare and Joel,
>
> Please see my answers below for both of you (see JV02012019).
>
> Please tell me, if you need further clarification.
>
> Best regards
>
> José
>
> -Original Message-
> From: Gedare Bloom [mailto:ged...@rtems.org]
> Sent: quinta-feira, 2 de janeiro de 2020 17:21
> To: Joel Sherrill
> Cc: Jose Valdez; devel@rtems.org
> Subject: Re: Requirement Document generator tool
>
> Hello José et al.,
>
> I have only a few points I would like clarified, below:
>
> On Mon, Dec 16, 2019 at 3:35 PM Joel Sherrill  wrote:
> >
> >
> >
> > On Mon, Dec 16, 2019 at 7:29 AM Jose Valdez 
> wrote:
> >>
> >> Hello Chris,
> >>
> >> Thank you for your reply.
> >>
> >> Please find below my answers.
> >>
> >> José
> >>
> >> -Original Message-
> >> From: Chris Johns [mailto:chr...@rtems.org]
> >> Sent: sexta-feira, 13 de dezembro de 2019 19:09
> >> To: Jose Valdez; devel@rtems.org
> >> Subject: Re: Requirement Document generator tool
> >>
> >> On 14/12/19 3:09 am, Jose Valdez wrote:
> >> > In the scope of ESA's RTEMS SMP project, we are developing a tool
> which will
> >> > allow to generate RTEMS software documentation
> >>
> >> I assume this is the pre-qual effort.
> >>
> >> JV: That's correct.
> >>
> >> > (Requirements, Design, Test Specification and other software
> documents).
> >>
> >> How do these documents relate to the project's current documentation?
> It may
> >> help to explain the purpose of each of these documents and the target
> user.
> >
> >
> >
> >>
> >> JV: The idea of the project is to allow an user to pre-qualify RTEMS
> for space applications. In that sense, the goal of the tool is to save the
> pre-qualification effort, by creating automatically the parts of the
> necessary documentation, which may be automatized. Generically parts which
> may be automatized are:
> >> -> Traceabilities (ex: Requirements against Architecture)
> >> -> Requirement coverage (Tests against requirements)
> >> -> Test results verification
> >> -> Creation of document templates
> >> -> source code metrics collection
> >> -> etc.
> >>
> >> The current scope is to create the documentation in accordance with ESA
> standard (ECSS), which defines the following necessary documents (and also
> the template) for a software product (note: the description text of each
> document was taken from ECSS, for helping you to understand the goal of
> each document):
> >
> >
> > This list of documents has some of which I would expect to
> > be hand-written, one-time documents. Others related to requirements,
> traceability,
> > and tests, I would expect to be generated. Can you clarify which
> documents
> > fall into which category?
> >
> > And how these documents related to RTEMS Pre-Qualification. For example,
> I don't see the
> > need for a Software Reuse File for RTEMS. That would seem to be
> something a project adopting
> > RTEMS might need.
> >
> > These documents also show an intentional bias to ECSS which is OK for
> you guys but
> > doesn't help in the RTEMS.org broader goal of having technical data for
> qualification which
> > fulfills the needs for multiple standards (NASA Quality, DO-178,
> automotive, etc.) Please
> > keep in mind that RTEMS is a world-wide project, independent of ESA and
> we would
> > like this effort to be able to address the multiple stakeholders.
> >
> > Some of these have the same names as other quality standard, others
> don't.
>
>
> JV02012019: Regarding your first question, a document itself may have both
> parts hand-written and generated. I understand that probably we missed to
> give you the full technical scope of the project (which is difficult by
> only exchanging e-mails). Please wait for our first input (Requirement
> Manager), which will include instructions on how to use and then you may
> perform your assessments and clarify your technical doubts.
>

One of the things that has unfortunately been lost over the years in
computer documentation is a Theory of Operations. This is independent of
the implementation.

In this case, you guys are trying to automate parts of an information flow
and traceability of that flow. What would help is an implementation
independent description of that information flow so we can say for
information X, traceability link Y,  etc, this is what we will do.

This is a software engineering process and there are lots of ways to
achieve it from Excel spreadsheets and pain to hugely expensive proprietary
tools. All achieve the same information and trace links.


>
> JV02012019: The documents which are not applicable to RTEMS project (like
> Software Reuse File) will be created, but will not have any content (the
> sections will have text like "Not Applicable").
>

What about code in RTEMS from third parties?

Doesn't this document have a perspective of a code base?


> JV02012019: I understand your concern about having the tool producing
> output for other standards/applications. 

Re: [PATCH] cpukit/score: avoid NULL and races in priority mutex

[Gedare Bloom]

On Fri, Jan 3, 2020 at 10:19 AM Joel Sherrill  wrote:
>
>
>
> On Fri, Jan 3, 2020, 12:08 AM Sebastian Huber 
>  wrote:
>>
>> On 03/01/2020 00:24, Gedare Bloom wrote:
>> > while ( !_Chain_Is_empty( 
>> > _thread->Priority_node.Inherited_priorities ) ) {
>> > +_ISR_Disable( level );
>> >   _Thread_Dequeue_priority_node(
>> > ((Thread_Priority_node*)_Chain_First(
>> >   _thread->Priority_node.Inherited_priorities
>> > ))
>> >   );
>> > +_ISR_Enable( level );
>> > }
>>
>> I don't know how the stuff works in detail, but this looks like a TOCTOU
>> problem. Should this be changed into:
>>
>> _ISR_Disable( level );
>> while ( !_Chain_Is_empty(
>> _thread->Priority_node.Inherited_priorities ) ) {
>>_Thread_Dequeue_priority_node(
>>  (Thread_Priority_node *) _Chain_First(
>>_thread->Priority_node.Inherited_priorities
>>  )
>>);
>>_ISR_Flash( level );
>> }
>> _ISR_Enable( level );
>
>
> I think Sebastian is right. There is a small window.

I'll push with this change. I'm not even sure this is live code. It
requires a thread reset while the thread is holding a lock. I don't
know if this is possible. Definitely it is a bad idea.

>>
>>
>> --
>> 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  : sebastian.hu...@embedded-brains.de
>> PGP : Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>> ___
>> 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: What do you want to study in GSOC 2020?

[Niteesh]

On Fri, Jan 3, 2020 at 7:30 PM Christian Mauderer 
wrote:

> On 03/01/2020 13:49, Niteesh wrote:
> > I have gone through previous year works and selected a few topics which
> > I found
> > interesting.
> > 1. Basic Support for Trace Compass #3696
> > .
>
> A basic support has been added last year and Sebastian extended that
> quite a bit because we had a customer who needed it. I'm not sure what
> the current state is and whether there are tasks left that could be done
> in a GSoC project.
>
> > 2. RTEMS testing tool project #2927  >.
>
> No idea what the status is. Chris?
>
> > 3. Beagle BSP: Add a flattened device tree based initialization #3784
> > .
>
> That one is open. It would include adding some infrastructure for fdt
> based drivers. In theory you could do the same project for raspberry or
> any other board.
>
> Please note Gedares comment from the previous mail:
>
> > Infrastructure projects are nice (FDT, dynamic linking, debugger,
> > tracer) but need to be clearly defined ahead of time and discussed
> > thoroughly with the community, or you risk ending up in the "long
> > tedious discussions" when you should be coding.
>
>
> > 4. BSPs for Simulators #2903 .
>
> That's always open.
>
> Some simulators are easy because the board is already supported and you
> only have to find out how to start it. For these a tester integration is
> a good target. But most likely that's only small stuff and should be
> only one part of a project.
>
> Other simulators are not supported yet. In that case you have to write
> some drivers which can be a good project size.
>
> > 5. Improve the Raspberry Pi BSP #2899 <
> https://devel.rtems.org/ticket/2899>.
>
> You already noted: The raspberry BSP isn't in the best shape. So it's
> quite open for improvement.
>
> I think that there is still some work getting it to run again. We don't
> have something with "*bcm*" in libbsd yet so most likely USB and
> Ethernet are not working yet. Could be still still be a nice task.
>

Why don't we use the driver's from other sources as a reference and create
our
own, for USB https://github.com/Chadderz121/csud this could be used as a
reference, U-boot, and Linux are good sources too. But is it worth the
effort for a
BSP like raspberry pi? There is also a c++ bare metal environment called
circle
https://github.com/rsta2/circle which supports USB(
https://github.com/rsta2/uspi)
and ethernet.

Christian, can you check out this https://github.com/0xabu/qemu/wiki it
partially supports
USB, can you give it a try?

>
> With the difficulties getting it to run on RPi3 or RPi4 that might could
> be also a project. It seems that they are aarch64. Also I was quite
> surprised about it I didn't find a aarch64 BSP. So that would be a new
> port.
>

Rpi3 looks for kernel7.img if it finds one, it boots into 32bit mode, so if
the, offset is the only difference
between rpi2 and rpi3 it should boot without any issues I'll try adding the
AUX uart driver
and see if it boots on Rpi3.

I would also like to discuss about the FDT infrastructure for RTEMS, I
would like to know what are
the requirements, what could be expected in a short span of 3months, what
could be used as a reference
and so on.

Note that an aarch64 port would most likely be observed with argus eyes
> because it has the potential to be a very important port. But don't let
> that keep you bag suggesting it.
>
> >
> > I would like to know what are the future plans for these topics.
> > What is the current status of USB and ethernet in raspberrypi?
> > Does the beagle BSP require hardware or is it possible to emulate it?
>
> I never used an emulator for Beagle. It seems that qemu supported it
> some when:
>
> https://www.cnx-software.com/2011/09/26/beagleboard-emulator-in-ubuntu-with-qemu/
>
> But I didn't find it in current qemu. So most likely it would need
> hardware.
>
> > Last year Vijay Kumar Banerjee worked on analysis and generation of gcov
> > reports.
> >
> > On Thu, Jan 2, 2020 at 10:07 PM Gedare Bloom  > > wrote:
> >
> > On Mon, Dec 30, 2019 at 2:47 PM Christian Mauderer
> > mailto:l...@c-mauderer.de>> wrote:
> > >
> > > On 30/12/2019 15:45, Niteesh wrote:
> > > > On Mon, Dec 30, 2019 at 7:14 PM Christian Mauderer
> > mailto:l...@c-mauderer.de>
> > > > >> wrote:
> > > >
> > > > On 30/12/2019 07:25, Niteesh wrote:
> > > > >
> > > > >
> > > > > On Mon, Dec 30, 2019 at 4:44 AM Peter Dufault
> > mailto:dufa...@hda.com>
> > > > >
> > > > > 
> >  > > > >
> > > > >
> > > > > 

Re: [PATCH 3/3] eng: Rework stakeholder chapter

[Gedare Bloom]

On Fri, Jan 3, 2020 at 10:07 AM Joel Sherrill  wrote:
>
>
>
> On Fri, Jan 3, 2020, 6:31 AM Sebastian Huber 
>  wrote:
>>
>> ---
>>  eng/index.rst|  2 +-
>>  eng/prequalification.rst | 11 +++
>>  eng/stakeholders.rst | 24 +++-
>>  3 files changed, 19 insertions(+), 18 deletions(-)
>>
>> diff --git a/eng/index.rst b/eng/index.rst
>> index 094b1e5..3340e34 100644
>> --- a/eng/index.rst
>> +++ b/eng/index.rst
>> @@ -25,8 +25,8 @@ RTEMS Software Engineering (|version|)
>>
>>  preface
>>  mission
>> -prequalification
>>  stakeholders
>> +prequalification
>>  req-eng
>>  management
>>  test-plan
>> diff --git a/eng/prequalification.rst b/eng/prequalification.rst
>> index 2004a7c..b591d3f 100644
>> --- a/eng/prequalification.rst
>> +++ b/eng/prequalification.rst
>> @@ -76,3 +76,14 @@ qualification standards. It will maintain "scorecards" 
>> which
>>  identify how the RTEMS Project is currently doing when reviewed per each
>>  standard. These will be maintained in the open as community resources
>>  which will guide the community in improving its infrastructure.
>> +
>> +Stakeholder Involvement
>> +===
>> +
>> +Qualification of RTEMS is a specialized activity and only specific users
>> +of RTEMS will complete a formal qualification activity. The RTEMS Project
>> +cannot self-fund this entire activity and requires stakeholder to invest
>> +in an ongoing basis to ensure the any investment they make is maintained
>> +and viable in an ongoing basis. The RTEMS core developers view steady
>> +support of the qualification effort as necessary to continue to lower
>> +the overall costs of qualification RTEMS.
>> diff --git a/eng/stakeholders.rst b/eng/stakeholders.rst
>> index 222c340..756c462 100644
>> --- a/eng/stakeholders.rst
>> +++ b/eng/stakeholders.rst
>> @@ -1,23 +1,13 @@
>>  .. SPDX-License-Identifier: CC-BY-SA-4.0
>>
>> -.. Copyright (C) 2018.
>> -.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
>> +.. Copyright (C) 2020 embedded brains GmbH
>> +.. Copyright (C) 2018 RTEMS Foundation, The RTEMS Documentation Project
>>
>>  RTEMS Stakeholders
>>  **
>>
>> -RTEMS is a community based open source project. All users are treated
>> -as stakeholders. It is hoped that as stakeholders, users will contribute
>> -to the project, sponsor core developers, and help fund the infrastructure
>> -required to host and manage the project.
>
>
> This paragraph shouldn't disappear. It is true. Qualification is just a 
> special case which is way beyond anything else
>
It doesn't disappear. He moved some content to above, and some to below.

>> -
>> -Qualification - Stakeholder Involvement
>> -===
>> -
>> -Qualification of RTEMS is a specialized activity and only specific users
>> -of RTEMS will complete a formal qualification activity. The RTEMS Project
>> -cannot self-fund this entire activity and requires stakeholder to invest
>> -in an ongoing basis to ensure the any investment they make is maintained
>> -and viable in an ongoing basis. The RTEMS core developers view steady
>> -support of the qualification effort as necessary to continue to lower
>> -the overall costs of qualification RTEMS.
>> +You are a potential RTEMS stakeholder.  RTEMS is a community based free and 
>> open
>> +source project.  All users are treated as stakeholders.  It is hoped that as
>> +stakeholders, users will contribute to the project, sponsor core 
>> developers, and
>> +help fund the infrastructure required to host and manage the project.  
>> Please
>> +have a look at the *Support and Contributing* chapter of the :r:url:`user`.
>> --
>> 2.16.4
>>
>> ___
>> 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] cpukit/score: avoid NULL and races in priority mutex

[Joel Sherrill]

On Fri, Jan 3, 2020, 12:08 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 03/01/2020 00:24, Gedare Bloom wrote:
> > while ( !_Chain_Is_empty(
> _thread->Priority_node.Inherited_priorities ) ) {
> > +_ISR_Disable( level );
> >   _Thread_Dequeue_priority_node(
> > ((Thread_Priority_node*)_Chain_First(
> >   _thread->Priority_node.Inherited_priorities
> > ))
> >   );
> > +_ISR_Enable( level );
> > }
>
> I don't know how the stuff works in detail, but this looks like a TOCTOU
> problem. Should this be changed into:
>
> _ISR_Disable( level );
> while ( !_Chain_Is_empty(
> _thread->Priority_node.Inherited_priorities ) ) {
>_Thread_Dequeue_priority_node(
>  (Thread_Priority_node *) _Chain_First(
>_thread->Priority_node.Inherited_priorities
>  )
>);
>_ISR_Flash( level );
> }
> _ISR_Enable( level );
>

I think Sebastian is right. There is a small window.

>
> --
> 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  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> ___
> 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: Glossary of Terms

[Joel Sherrill]

On Fri, Jan 3, 2020, 10:22 AM Gedare Bloom  wrote:

> On Fri, Jan 3, 2020 at 3:25 AM Sebastian Huber
>  wrote:
> >
> > On 03/01/2020 10:42, andrew.butterfi...@cs.tcd.ie wrote:
> > > Hello all, and Happy New Year!
> > >
> > >> On 3 Jan 2020, at 08:10, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> > >>
> > >>
> > >> 1. Should we use one shared glossary which is included in all
> documents?
> > >>
> > >> 2. Do we want to use document-specific glossaries and maintain
> copy-and-paste entries by hand?
> > >>
> > >> With option 1. the glossary may contain a lot of things which are
> unrelated to a specific document. However, if the Sphinx glossary support
> gets improved, this problem may vanish. With 2. we have a maintenance
> problem, e.g. keeping the copy and paste definitions in synchronization.
> > >>
> > >> What do you think?
> > >>
> > >
> > > Can we fuse 1+2 - keep a single (master) glossary file with added tags
> "glos1", "glos2" (or whatever)
> > > We then have a script that generates the different glossaries from
> that one master?
> > >
> > > I guess the issue is how easy it is to run that script from within the
> various document build workflows.
> >
> > Yes, we can also add our own scripts to automate this. The question is
> > if we want to develop special case solutions or try to fix it in the
> > upstream Sphinx project. Using our own scripts would be much probably
> > much easier, unless someone is familiar with the Sphinx internals.
> >
> > We could for example get the terms used in a document and based on this
> > generate a document-specific glossary from a master template, e.g.
> >
> > grep -r --include='*.rst' ':term:`[^`]*`' -o
> > eng/req-eng.rst::term:`GNAT`
> > eng/req-eng.rst::term:`EARS`
> > eng/req-eng.rst::term:`API`
> > eng/req-eng.rst::term:`ABI`
> > eng/req-eng.rst::term:`source code`
> > eng/req-eng.rst::term:`CCB`
> > eng/req-eng.rst::term:`ISVV`
> > eng/req-eng.rst::term:`ReqIF`
> > eng/req-eng.rst::term:`Doorstop`
> > eng/req-eng.rst::term:`Doorstop`
> > eng/req-eng.rst::term:`YAML`
> > c-user/key_concepts.rst::term:`thread`
> > c-user/symmetric_multiprocessing_services.rst::term:`TLS`
> > c-user/symmetric_multiprocessing_services.rst::term:`C11`
> > c-user/symmetric_multiprocessing_services.rst::term:`MCS`
> > c-user/symmetric_multiprocessing_services.rst::term:`FIFO`
> > c-user/symmetric_multiprocessing_services.rst::term:`NUMA`
> > c-user/symmetric_multiprocessing_services.rst::term:`TCB`
> > c-user/symmetric_multiprocessing_services.rst::term:`TTAS`
> > c-user/glossary.rst::term:`C11`
> > c-user/glossary.rst::term:`C11`
> > c-user/glossary.rst::term:`C++11`
> > user/start/prefixes.rst::term:`prefix`
> > user/installation/project-sandboxing.rst::term:`prefix`
> > user/overview/index.rst::term:`RTEMS`
> > user/overview/index.rst::term:`SMP`
> > user/overview/index.rst::term:`APIs `
> > user/overview/index.rst::term:`POSIX`
> > user/overview/index.rst::term:`C11`
> > user/overview/index.rst::term:`C++11`
> > user/overview/index.rst::term:`GCC`
> > user/overview/index.rst::term:`EMB²`
> > user/overview/index.rst::term:`OpenMP`
> > user/overview/index.rst::term:`Futex`
> > user/overview/index.rst::term:`OpenMP`
> > user/overview/index.rst::term:`OMIP`
> > user/overview/index.rst::term:`MrsP`
> > user/overview/index.rst::term:`TLS`
> > user/overview/index.rst::term:`EDF`
> > user/overview/index.rst::term:`EDF`
> > user/overview/index.rst::term:`APA`
> > user/overview/index.rst::term:`IMFS`
> > user/overview/index.rst::term:`FAT`
> > user/overview/index.rst::term:`RFS`
> > user/overview/index.rst::term:`NFSv2`
> > user/overview/index.rst::term:`JFFS2`
> > user/overview/index.rst::term:`YAFFS2`
> > user/hardware/architectures.rst::term:`ABI`
> > eclipse/overview.rst::term:`RTEMS`
> >
> > An include if used policy is not followed by the Classic API Guide since
> > this feature was not available in the old texinfo framework as well.
> >
>
> I prefer we use a centralized glossary/document to generate individual
> glossaries (via scripting or improving Sphinx). This will be a lot
> easier to maintain.
>

The DoD Architecture Framework (DoDAF) calls this an AV-2 which is a
singular artifacr across the project for consistencyt

http://acqnotes.com/acqnote/tasks/av-2-integrated-dictionary

That said, you need glossaries in documents and automating pulling
definitions and acronyms out automatically producing a glossary and acronym
list from the master AV-2 is desirable. No one wants to reference a
standalone glossary.

There can be issues if definitions change over time because the single AV-2
can't deal with old and new. It gets confusing. I have seen a project where
the AV-2 included history like the Oxford English Dictionary. It was
dreadful.

That's a lot of background to say this isn't a RTEMS unique problem. A
central database of acronyms and definitions would be a good thing. If grep
is sufficient to find word use to trigger inclusion in a document specific

Re: [PATCH 3/3] eng: Rework stakeholder chapter

[Joel Sherrill]

On Fri, Jan 3, 2020, 6:31 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> ---
>  eng/index.rst|  2 +-
>  eng/prequalification.rst | 11 +++
>  eng/stakeholders.rst | 24 +++-
>  3 files changed, 19 insertions(+), 18 deletions(-)
>
> diff --git a/eng/index.rst b/eng/index.rst
> index 094b1e5..3340e34 100644
> --- a/eng/index.rst
> +++ b/eng/index.rst
> @@ -25,8 +25,8 @@ RTEMS Software Engineering (|version|)
>
>  preface
>  mission
> -prequalification
>  stakeholders
> +prequalification
>  req-eng
>  management
>  test-plan
> diff --git a/eng/prequalification.rst b/eng/prequalification.rst
> index 2004a7c..b591d3f 100644
> --- a/eng/prequalification.rst
> +++ b/eng/prequalification.rst
> @@ -76,3 +76,14 @@ qualification standards. It will maintain "scorecards"
> which
>  identify how the RTEMS Project is currently doing when reviewed per each
>  standard. These will be maintained in the open as community resources
>  which will guide the community in improving its infrastructure.
> +
> +Stakeholder Involvement
> +===
> +
> +Qualification of RTEMS is a specialized activity and only specific users
> +of RTEMS will complete a formal qualification activity. The RTEMS Project
> +cannot self-fund this entire activity and requires stakeholder to invest
> +in an ongoing basis to ensure the any investment they make is maintained
> +and viable in an ongoing basis. The RTEMS core developers view steady
> +support of the qualification effort as necessary to continue to lower
> +the overall costs of qualification RTEMS.
> diff --git a/eng/stakeholders.rst b/eng/stakeholders.rst
> index 222c340..756c462 100644
> --- a/eng/stakeholders.rst
> +++ b/eng/stakeholders.rst
> @@ -1,23 +1,13 @@
>  .. SPDX-License-Identifier: CC-BY-SA-4.0
>
> -.. Copyright (C) 2018.
> -.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
> +.. Copyright (C) 2020 embedded brains GmbH
> +.. Copyright (C) 2018 RTEMS Foundation, The RTEMS Documentation Project
>
>  RTEMS Stakeholders
>  **
>
> -RTEMS is a community based open source project. All users are treated
> -as stakeholders. It is hoped that as stakeholders, users will contribute
> -to the project, sponsor core developers, and help fund the infrastructure
> -required to host and manage the project.
>

This paragraph shouldn't disappear. It is true. Qualification is just a
special case which is way beyond anything else

-
> -Qualification - Stakeholder Involvement
> -===
> -
> -Qualification of RTEMS is a specialized activity and only specific users
> -of RTEMS will complete a formal qualification activity. The RTEMS Project
> -cannot self-fund this entire activity and requires stakeholder to invest
> -in an ongoing basis to ensure the any investment they make is maintained
> -and viable in an ongoing basis. The RTEMS core developers view steady
> -support of the qualification effort as necessary to continue to lower
> -the overall costs of qualification RTEMS.
> +You are a potential RTEMS stakeholder.  RTEMS is a community based free
> and open
> +source project.  All users are treated as stakeholders.  It is hoped that
> as
> +stakeholders, users will contribute to the project, sponsor core
> developers, and
> +help fund the infrastructure required to host and manage the project.
> Please
> +have a look at the *Support and Contributing* chapter of the
> :r:url:`user`.
> --
> 2.16.4
>
> ___
> 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: Coding Convention: Sorting Order of Includes?

[Joel Sherrill]

On Fri, Jan 3, 2020, 10:53 AM Gedare Bloom  wrote:

> Hello all,
>
> Vijay noted in another thread that:
> "For RTEMS, I don't see any preference mentioned in the docs for the
> order or includes:
> https://docs.rtems.org/branches/master/eng/coding-conventions.html
>
> In libbsd, however, the FreeBSD style guide is followed which has a
> preference for the order of header includes:
> https://www.freebsd.org/cgi/man.cgi?query=style=0=9;
>
> Should we consider any rules? I would suspect that at least ordering
> by API layering could be helpful. Lexical sorting is nice but probably
> there will be some exceptions based on dependencies.
>

Those look pretty good as rules. I try to alphabetize headers but you
are right, sometimes it isn't possible. I'd be ok if this was added to our
style.

The linked page mentions how they do the beginning of a license block with
/*- so a program they have recovnizes it as a license but indent doesn't
like that so use /** when you need indent. They don't mention that /**
turns it into a Doxygen comment which creates another problem. We may want
to discuss doing something on these blocks. Personally I'd like to see
licenses start to change and spdx tags added even if the license can't
change.


> Gedare
> ___
> 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

Coding Convention: Sorting Order of Includes?

[Gedare Bloom]

Hello all,

Vijay noted in another thread that:
"For RTEMS, I don't see any preference mentioned in the docs for the
order or includes:
https://docs.rtems.org/branches/master/eng/coding-conventions.html

In libbsd, however, the FreeBSD style guide is followed which has a
preference for the order of header includes:
https://www.freebsd.org/cgi/man.cgi?query=style=0=9;

Should we consider any rules? I would suspect that at least ordering
by API layering could be helpful. Lexical sorting is nice but probably
there will be some exceptions based on dependencies.

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

Re: [PATCH 3/3] eng: Rework stakeholder chapter

[Gedare Bloom]

Good. I spotted 2 typos that existed from before:

On Fri, Jan 3, 2020 at 5:31 AM Sebastian Huber
 wrote:
>
> ---
>  eng/index.rst|  2 +-
>  eng/prequalification.rst | 11 +++
>  eng/stakeholders.rst | 24 +++-
>  3 files changed, 19 insertions(+), 18 deletions(-)
>
> diff --git a/eng/index.rst b/eng/index.rst
> index 094b1e5..3340e34 100644
> --- a/eng/index.rst
> +++ b/eng/index.rst
> @@ -25,8 +25,8 @@ RTEMS Software Engineering (|version|)
>
>  preface
>  mission
> -prequalification
>  stakeholders
> +prequalification
>  req-eng
>  management
>  test-plan
> diff --git a/eng/prequalification.rst b/eng/prequalification.rst
> index 2004a7c..b591d3f 100644
> --- a/eng/prequalification.rst
> +++ b/eng/prequalification.rst
> @@ -76,3 +76,14 @@ qualification standards. It will maintain "scorecards" 
> which
>  identify how the RTEMS Project is currently doing when reviewed per each
>  standard. These will be maintained in the open as community resources
>  which will guide the community in improving its infrastructure.
> +
> +Stakeholder Involvement
> +===
> +
> +Qualification of RTEMS is a specialized activity and only specific users
> +of RTEMS will complete a formal qualification activity. The RTEMS Project
> +cannot self-fund this entire activity and requires stakeholder to invest
> +in an ongoing basis to ensure the any investment they make is maintained
the -> that

> +and viable in an ongoing basis. The RTEMS core developers view steady
> +support of the qualification effort as necessary to continue to lower
> +the overall costs of qualification RTEMS.
qualification -> qualifying  OR  qualification of

> diff --git a/eng/stakeholders.rst b/eng/stakeholders.rst
> index 222c340..756c462 100644
> --- a/eng/stakeholders.rst
> +++ b/eng/stakeholders.rst
> @@ -1,23 +1,13 @@
>  .. SPDX-License-Identifier: CC-BY-SA-4.0
>
> -.. Copyright (C) 2018.
> -.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
> +.. Copyright (C) 2020 embedded brains GmbH
> +.. Copyright (C) 2018 RTEMS Foundation, The RTEMS Documentation Project
>
>  RTEMS Stakeholders
>  **
>
> -RTEMS is a community based open source project. All users are treated
> -as stakeholders. It is hoped that as stakeholders, users will contribute
> -to the project, sponsor core developers, and help fund the infrastructure
> -required to host and manage the project.
> -
> -Qualification - Stakeholder Involvement
> -===
> -
> -Qualification of RTEMS is a specialized activity and only specific users
> -of RTEMS will complete a formal qualification activity. The RTEMS Project
> -cannot self-fund this entire activity and requires stakeholder to invest
> -in an ongoing basis to ensure the any investment they make is maintained
> -and viable in an ongoing basis. The RTEMS core developers view steady
> -support of the qualification effort as necessary to continue to lower
> -the overall costs of qualification RTEMS.
> +You are a potential RTEMS stakeholder.  RTEMS is a community based free and 
> open
> +source project.  All users are treated as stakeholders.  It is hoped that as
> +stakeholders, users will contribute to the project, sponsor core developers, 
> and
> +help fund the infrastructure required to host and manage the project.  Please
> +have a look at the *Support and Contributing* chapter of the :r:url:`user`.
> --
> 2.16.4
>
> ___
> 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: Glossary of Terms

[Gedare Bloom]

On Fri, Jan 3, 2020 at 3:25 AM Sebastian Huber
 wrote:
>
> On 03/01/2020 10:42, andrew.butterfi...@cs.tcd.ie wrote:
> > Hello all, and Happy New Year!
> >
> >> On 3 Jan 2020, at 08:10, Sebastian Huber 
> >>  wrote:
> >>
> >>
> >> 1. Should we use one shared glossary which is included in all documents?
> >>
> >> 2. Do we want to use document-specific glossaries and maintain 
> >> copy-and-paste entries by hand?
> >>
> >> With option 1. the glossary may contain a lot of things which are 
> >> unrelated to a specific document. However, if the Sphinx glossary support 
> >> gets improved, this problem may vanish. With 2. we have a maintenance 
> >> problem, e.g. keeping the copy and paste definitions in synchronization.
> >>
> >> What do you think?
> >>
> >
> > Can we fuse 1+2 - keep a single (master) glossary file with added tags 
> > "glos1", "glos2" (or whatever)
> > We then have a script that generates the different glossaries from that one 
> > master?
> >
> > I guess the issue is how easy it is to run that script from within the 
> > various document build workflows.
>
> Yes, we can also add our own scripts to automate this. The question is
> if we want to develop special case solutions or try to fix it in the
> upstream Sphinx project. Using our own scripts would be much probably
> much easier, unless someone is familiar with the Sphinx internals.
>
> We could for example get the terms used in a document and based on this
> generate a document-specific glossary from a master template, e.g.
>
> grep -r --include='*.rst' ':term:`[^`]*`' -o
> eng/req-eng.rst::term:`GNAT`
> eng/req-eng.rst::term:`EARS`
> eng/req-eng.rst::term:`API`
> eng/req-eng.rst::term:`ABI`
> eng/req-eng.rst::term:`source code`
> eng/req-eng.rst::term:`CCB`
> eng/req-eng.rst::term:`ISVV`
> eng/req-eng.rst::term:`ReqIF`
> eng/req-eng.rst::term:`Doorstop`
> eng/req-eng.rst::term:`Doorstop`
> eng/req-eng.rst::term:`YAML`
> c-user/key_concepts.rst::term:`thread`
> c-user/symmetric_multiprocessing_services.rst::term:`TLS`
> c-user/symmetric_multiprocessing_services.rst::term:`C11`
> c-user/symmetric_multiprocessing_services.rst::term:`MCS`
> c-user/symmetric_multiprocessing_services.rst::term:`FIFO`
> c-user/symmetric_multiprocessing_services.rst::term:`NUMA`
> c-user/symmetric_multiprocessing_services.rst::term:`TCB`
> c-user/symmetric_multiprocessing_services.rst::term:`TTAS`
> c-user/glossary.rst::term:`C11`
> c-user/glossary.rst::term:`C11`
> c-user/glossary.rst::term:`C++11`
> user/start/prefixes.rst::term:`prefix`
> user/installation/project-sandboxing.rst::term:`prefix`
> user/overview/index.rst::term:`RTEMS`
> user/overview/index.rst::term:`SMP`
> user/overview/index.rst::term:`APIs `
> user/overview/index.rst::term:`POSIX`
> user/overview/index.rst::term:`C11`
> user/overview/index.rst::term:`C++11`
> user/overview/index.rst::term:`GCC`
> user/overview/index.rst::term:`EMB²`
> user/overview/index.rst::term:`OpenMP`
> user/overview/index.rst::term:`Futex`
> user/overview/index.rst::term:`OpenMP`
> user/overview/index.rst::term:`OMIP`
> user/overview/index.rst::term:`MrsP`
> user/overview/index.rst::term:`TLS`
> user/overview/index.rst::term:`EDF`
> user/overview/index.rst::term:`EDF`
> user/overview/index.rst::term:`APA`
> user/overview/index.rst::term:`IMFS`
> user/overview/index.rst::term:`FAT`
> user/overview/index.rst::term:`RFS`
> user/overview/index.rst::term:`NFSv2`
> user/overview/index.rst::term:`JFFS2`
> user/overview/index.rst::term:`YAFFS2`
> user/hardware/architectures.rst::term:`ABI`
> eclipse/overview.rst::term:`RTEMS`
>
> An include if used policy is not followed by the Classic API Guide since
> this feature was not available in the old texinfo framework as well.
>

I prefer we use a centralized glossary/document to generate individual
glossaries (via scripting or improving Sphinx). This will be a lot
easier to maintain.

> --
> 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  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> ___
> 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 v2 2/2] score: Simplify _Thread_Initialize()

[Gedare Bloom]

Looks good.

On Thu, Jan 2, 2020 at 11:31 PM Sebastian Huber
 wrote:
>
> Allocate new thread queue heads during objects information extend.  This
> removes an error case and the last dependency on the workspace in
> _Thread_Initialize().
>
> Update #3835.
> ---
>  cpukit/Makefile.am |  1 +
>  cpukit/include/rtems/score/thread.h| 10 -
>  cpukit/score/src/threadallocateunlimited.c | 72 
> ++
>  cpukit/score/src/threadinitialize.c| 11 +
>  testsuites/samples/unlimited/test1.c   |  2 +
>  5 files changed, 86 insertions(+), 10 deletions(-)
>  create mode 100644 cpukit/score/src/threadallocateunlimited.c
>
> diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
> index 52365cab8c..6e754bfe86 100644
> --- a/cpukit/Makefile.am
> +++ b/cpukit/Makefile.am
> @@ -943,6 +943,7 @@ librtemscpu_a_SOURCES += score/src/rbtreeiterate.c
>  librtemscpu_a_SOURCES += score/src/rbtreenext.c
>  librtemscpu_a_SOURCES += score/src/rbtreepostorder.c
>  librtemscpu_a_SOURCES += score/src/rbtreereplace.c
> +librtemscpu_a_SOURCES += score/src/threadallocateunlimited.c
>  librtemscpu_a_SOURCES += score/src/thread.c
>  librtemscpu_a_SOURCES += score/src/threadchangepriority.c
>  librtemscpu_a_SOURCES += score/src/threadclearstate.c
> diff --git a/cpukit/include/rtems/score/thread.h 
> b/cpukit/include/rtems/score/thread.h
> index ab640c3595..fbd5327b30 100644
> --- a/cpukit/include/rtems/score/thread.h
> +++ b/cpukit/include/rtems/score/thread.h
> @@ -1039,6 +1039,14 @@ Thread_Information name##_Information = { \
>} \
>  }
>
> +/**
> + * @brief Return an inactive thread object or NULL.
> + *
> + * @retval NULL No inactive object is available.
> + * @retval object An inactive object.
> + */
> +Objects_Control *_Thread_Allocate_unlimited( Objects_Information 
> *information );
> +
>  #define THREAD_INFORMATION_DEFINE( name, api, cls, max ) \
>  static Objects_Control * \
>  name##_Local_table[ _Objects_Maximum_per_allocation( max ) ]; \
> @@ -1051,7 +1059,7 @@ Thread_Information name##_Information = { \
>  _Objects_Build_id( api, cls, 1, _Objects_Maximum_per_allocation( max ) 
> ), \
>  name##_Local_table, \
>  _Objects_Is_unlimited( max ) ? \
> -  _Objects_Allocate_unlimited : _Objects_Allocate_static, \
> +  _Thread_Allocate_unlimited : _Objects_Allocate_static, \
>  _Objects_Is_unlimited( max ) ? \
>_Objects_Free_unlimited : _Objects_Free_static, \
>  0, \
> diff --git a/cpukit/score/src/threadallocateunlimited.c 
> b/cpukit/score/src/threadallocateunlimited.c
> new file mode 100644
> index 00..c4b176f887
> --- /dev/null
> +++ b/cpukit/score/src/threadallocateunlimited.c
> @@ -0,0 +1,72 @@
> +/**
> + * @file
> + *
> + * @ingroup RTEMSScoreThread
> + */
> +
> +/*
> + * SPDX-License-Identifier: BSD-2-Clause
> + *
> + * Copyright (C) 2019, 2020 embedded brains GmbH
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
> IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#if HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +
> +#include 
> +#include 
> +#include 
> +
> +static void _Thread_Extend_information( Objects_Information *base )
> +{
> +  Thread_Information *information;
> +  Objects_Maximum block;
> +
> +  information = (Thread_Information *) base;
> +  block = _Objects_Extend_information( >Objects );
> +
> +  if ( block > 0 ) {
> +void *new_heads;
> +
> +new_heads = _Freechain_Extend(
> +  >Thread_queue_heads.Free,
> +  _Workspace_Allocate,
> +  _Objects_Extend_size( >Objects ),
> +  _Thread_queue_Heads_size
> +);
> +
> +if ( new_heads == NULL ) {
> +  _Objects_Free_objects_block( >Objects, block );
> +}
> +  }

Re: [PATCH] cpukit/score: avoid NULL and races in priority mutex

[Gedare Bloom]

On Thu, Jan 2, 2020 at 11:08 PM Sebastian Huber
 wrote:
>
> On 03/01/2020 00:24, Gedare Bloom wrote:
> > while ( !_Chain_Is_empty( 
> > _thread->Priority_node.Inherited_priorities ) ) {
> > +_ISR_Disable( level );
> >   _Thread_Dequeue_priority_node(
> > ((Thread_Priority_node*)_Chain_First(
> >   _thread->Priority_node.Inherited_priorities
> > ))
> >   );
> > +_ISR_Enable( level );
> > }
>
> I don't know how the stuff works in detail, but this looks like a TOCTOU
> problem. Should this be changed into:
>
> _ISR_Disable( level );
> while ( !_Chain_Is_empty(
> _thread->Priority_node.Inherited_priorities ) ) {
>_Thread_Dequeue_priority_node(
>  (Thread_Priority_node *) _Chain_First(
>_thread->Priority_node.Inherited_priorities
>  )
>);
>_ISR_Flash( level );
> }
> _ISR_Enable( level );
>
That would work fine. I'll adjust it, thanks.

> --
> 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  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsp/raspberrypi: Updated the console API.

[Vijay Kumar Banerjee]

On Fri, Jan 3, 2020, 8:53 PM Niteesh  wrote:

> On Fri, Jan 3, 2020 at 7:32 PM Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> Hi Niteesh,
>> A few formatting suggestions:
>>
>>>
>>> diff --git a/bsps/arm/raspberrypi/console/console-config.c
>>> b/bsps/arm/raspberrypi/console/console-config.c
>>> index d2186c918b..4000fd1c50 100644
>>> --- a/bsps/arm/raspberrypi/console/console-config.c
>>> +++ b/bsps/arm/raspberrypi/console/console-config.c
>>> @@ -19,50 +19,132 @@
>>>   */
>>>
>>>  #include 
>>> -
>>> -#include 
>>>
>> You removed it here and added it below
>>
>>> +#include 
>>> +#include 
>>>
>>>  #include 
>>> -#include 
>>> -#include 
>>>
>> same here
>>
>>> +#include 
>>>  #include 
>>> +#include 
>>>
>> added here ^
>>
>>> +#include 
>>>  #include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#include 
>>> +#include 
>>
>> here
>>
> Is there any particular reason for doing it, or is it just a preference?
>
For RTEMS, I don't see any preference mentioned in the docs for the order
or includes:
https://docs.rtems.org/branches/master/eng/coding-conventions.html

In libbsd, however, the FreeBSD style guide is followed which has a
preference for the order of header includes:
https://www.freebsd.org/cgi/man.cgi?query=style=0=9

Apart from that, this is a redundant change. Is there a reason to change
the order?

> This is just a small change and I would suggest you wait for at least a day
>> before sending a v2 of the patch so that you can add changes suggested
>> by other people (if any). Congrats on getting it working ;-)
>>
> Thank you.
>
>> Best,
>> Vijay
>>
>>> +
>>> +#define UART0 "/dev/ttyS0"
>>> +#define FBCONS"/dev/fbcons"
>>> +
>>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsp/raspberrypi: Updated the console API.

[Niteesh]

On Fri, Jan 3, 2020 at 7:32 PM Vijay Kumar Banerjee <
vijaykumar9...@gmail.com> wrote:

> Hi Niteesh,
> A few formatting suggestions:
>
>>
>> diff --git a/bsps/arm/raspberrypi/console/console-config.c
>> b/bsps/arm/raspberrypi/console/console-config.c
>> index d2186c918b..4000fd1c50 100644
>> --- a/bsps/arm/raspberrypi/console/console-config.c
>> +++ b/bsps/arm/raspberrypi/console/console-config.c
>> @@ -19,50 +19,132 @@
>>   */
>>
>>  #include 
>> -
>> -#include 
>>
> You removed it here and added it below
>
>> +#include 
>> +#include 
>>
>>  #include 
>> -#include 
>> -#include 
>>
> same here
>
>> +#include 
>>  #include 
>> +#include 
>>
> added here ^
>
>> +#include 
>>  #include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>
> here
>
Is there any particular reason for doing it, or is it just a preference?

> This is just a small change and I would suggest you wait for at least a day
> before sending a v2 of the patch so that you can add changes suggested
> by other people (if any). Congrats on getting it working ;-)
>
Thank you.

> Best,
> Vijay
>
>> +
>> +#define UART0 "/dev/ttyS0"
>> +#define FBCONS"/dev/fbcons"
>> +
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: What do you want to study in GSOC 2020?

[Vijay Kumar Banerjee]

On Fri, Jan 3, 2020 at 7:30 PM Christian Mauderer 
wrote:

> On 03/01/2020 13:49, Niteesh wrote:
> > I have gone through previous year works and selected a few topics which
> > I found
> > interesting.
> > 1. Basic Support for Trace Compass #3696
> > .
>
> A basic support has been added last year and Sebastian extended that
> quite a bit because we had a customer who needed it. I'm not sure what
> the current state is and whether there are tasks left that could be done
> in a GSoC project.
>
> > 2. RTEMS testing tool project #2927  >.
>
> No idea what the status is. Chris?
>
> > 3. Beagle BSP: Add a flattened device tree based initialization #3784
> > .
>
> That one is open. It would include adding some infrastructure for fdt
> based drivers. In theory you could do the same project for raspberry or
> any other board.
>
> Please note Gedares comment from the previous mail:
>
> > Infrastructure projects are nice (FDT, dynamic linking, debugger,
> > tracer) but need to be clearly defined ahead of time and discussed
> > thoroughly with the community, or you risk ending up in the "long
> > tedious discussions" when you should be coding.
>
>
> > 4. BSPs for Simulators #2903 .
>
> That's always open.
>
> Some simulators are easy because the board is already supported and you
> only have to find out how to start it. For these a tester integration is
> a good target. But most likely that's only small stuff and should be
> only one part of a project.
>
> Other simulators are not supported yet. In that case you have to write
> some drivers which can be a good project size.
>
> > 5. Improve the Raspberry Pi BSP #2899 <
> https://devel.rtems.org/ticket/2899>.
>
> You already noted: The raspberry BSP isn't in the best shape. So it's
> quite open for improvement.
>
> I think that there is still some work getting it to run again. We don't
> have something with "*bcm*" in libbsd yet so most likely USB and
> Ethernet are not working yet. Could be still still be a nice task.
>
> With the difficulties getting it to run on RPi3 or RPi4 that might could
> be also a project. It seems that they are aarch64. Also I was quite
> surprised about it I didn't find a aarch64 BSP. So that would be a new
> port.
>
> Note that an aarch64 port would most likely be observed with argus eyes
> because it has the potential to be a very important port. But don't let
> that keep you bag suggesting it.
>
> >
> > I would like to know what are the future plans for these topics.
> > What is the current status of USB and ethernet in raspberrypi?
> > Does the beagle BSP require hardware or is it possible to emulate it?
>
> I never used an emulator for Beagle. It seems that qemu supported it
> some when:
>
> https://www.cnx-software.com/2011/09/26/beagleboard-emulator-in-ubuntu-with-qemu/
>
> But I didn't find it in current qemu. So most likely it would need
> hardware.
>
> > Last year Vijay Kumar Banerjee worked on analysis and generation of gcov
> > reports.
>
Gcov integration needs a lot of work and some very detailed study of the
Gcov
framework. While it'll be a really valuable project, currently we lack
expertise
about gcov. I will not suggest you on taking gcov integration as the
project as
most of the time will be spent in discussions and reading (as Gedare
mentioned).


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

Re: [PATCH] bsp/raspberrypi: Updated the console API.

[Vijay Kumar Banerjee]

Hi Niteesh,
A few formatting suggestions:

>
> diff --git a/bsps/arm/raspberrypi/console/console-config.c
> b/bsps/arm/raspberrypi/console/console-config.c
> index d2186c918b..4000fd1c50 100644
> --- a/bsps/arm/raspberrypi/console/console-config.c
> +++ b/bsps/arm/raspberrypi/console/console-config.c
> @@ -19,50 +19,132 @@
>   */
>
>  #include 
> -
> -#include 
>
You removed it here and added it below

> +#include 
> +#include 
>
>  #include 
> -#include 
> -#include 
>
same here

> +#include 
>  #include 
> +#include 
>
added here ^

> +#include 
>  #include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 

here

This is just a small change and I would suggest you wait for at least a day
before sending a v2 of the patch so that you can add changes suggested
by other people (if any). Congrats on getting it working ;-)

Best,
Vijay

> +
> +#define UART0 "/dev/ttyS0"
> +#define FBCONS"/dev/fbcons"
> +
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: What do you want to study in GSOC 2020?

[Christian Mauderer]

On 03/01/2020 13:49, Niteesh wrote:
> I have gone through previous year works and selected a few topics which
> I found
> interesting.
> 1. Basic Support for Trace Compass #3696
> .

A basic support has been added last year and Sebastian extended that
quite a bit because we had a customer who needed it. I'm not sure what
the current state is and whether there are tasks left that could be done
in a GSoC project.

> 2. RTEMS testing tool project #2927 .

No idea what the status is. Chris?

> 3. Beagle BSP: Add a flattened device tree based initialization #3784
> .

That one is open. It would include adding some infrastructure for fdt
based drivers. In theory you could do the same project for raspberry or
any other board.

Please note Gedares comment from the previous mail:

> Infrastructure projects are nice (FDT, dynamic linking, debugger,
> tracer) but need to be clearly defined ahead of time and discussed
> thoroughly with the community, or you risk ending up in the "long
> tedious discussions" when you should be coding.


> 4. BSPs for Simulators #2903 .

That's always open.

Some simulators are easy because the board is already supported and you
only have to find out how to start it. For these a tester integration is
a good target. But most likely that's only small stuff and should be
only one part of a project.

Other simulators are not supported yet. In that case you have to write
some drivers which can be a good project size.

> 5. Improve the Raspberry Pi BSP #2899 .

You already noted: The raspberry BSP isn't in the best shape. So it's
quite open for improvement.

I think that there is still some work getting it to run again. We don't
have something with "*bcm*" in libbsd yet so most likely USB and
Ethernet are not working yet. Could be still still be a nice task.

With the difficulties getting it to run on RPi3 or RPi4 that might could
be also a project. It seems that they are aarch64. Also I was quite
surprised about it I didn't find a aarch64 BSP. So that would be a new port.

Note that an aarch64 port would most likely be observed with argus eyes
because it has the potential to be a very important port. But don't let
that keep you bag suggesting it.

> 
> I would like to know what are the future plans for these topics.
> What is the current status of USB and ethernet in raspberrypi?
> Does the beagle BSP require hardware or is it possible to emulate it?

I never used an emulator for Beagle. It seems that qemu supported it
some when:
https://www.cnx-software.com/2011/09/26/beagleboard-emulator-in-ubuntu-with-qemu/

But I didn't find it in current qemu. So most likely it would need hardware.

> Last year Vijay Kumar Banerjee worked on analysis and generation of gcov
> reports.
> 
> On Thu, Jan 2, 2020 at 10:07 PM Gedare Bloom  > wrote:
> 
> On Mon, Dec 30, 2019 at 2:47 PM Christian Mauderer
> mailto:l...@c-mauderer.de>> wrote:
> >
> > On 30/12/2019 15:45, Niteesh wrote:
> > > On Mon, Dec 30, 2019 at 7:14 PM Christian Mauderer
> mailto:l...@c-mauderer.de>
> > > >> wrote:
> > >
> > >     On 30/12/2019 07:25, Niteesh wrote:
> > >     >
> > >     >
> > >     > On Mon, Dec 30, 2019 at 4:44 AM Peter Dufault
> mailto:dufa...@hda.com>
> > >     >
> > >     > 
>  > >     >
> > >     >
> > >     >     Niteesh, what do you want to study?  Go over what most
> > >     interests you
> > >     >     most about working in a real-time environment like
> RTEMS, and not
> > >     >     about working on the RPI, and look at the earlier GSOC
> projects.
> > >     >     Propose an ideal project for yourself and get some
> feedback.
> > >
> > >     Peter: Thanks for starting that discussion. I started to
> focus too much
> > >     on the running topics about small stuff that can be done as a
> > >     preparation.
> > >
> > >     >
> > >     >  I love learning about how the software and hardware
> interact, I have
> > >     > been programming from 9th grade and have a wide variety of
> > >     > interests(networking, app development). But recently I
> took a course
> > >     > called nandtotetris were we build an 8bit computer from
> scratch, we
> > >     > start with NAND gates and finally finish with a Tetris game.
> > >
> > >     That sounds like a really nice course. Most likely is ended
> in a bigger
> > >     pile of circuit boards to have a running processor ;-)
> > >
> > > It is a free course on
>  

Re: Builtin memcpy() requirements

[Sebastian Huber]

Hello Jonathan,

On 20/12/2019 20:03, Jonathan Brandmeyer wrote:

Small improvements inline:

On Fri, Dec 20, 2019 at 1:25 AM Sebastian Huber 
> wrote:


Hello,

while working on a test case for

https://devel.rtems.org/ticket/3767

I tried to find the right test suite for it. At first I thought that
this is a unit test
(testsuites/unit/compiler/tc-misaligned-builtin-memcpy.c). However, I
now think that we should have a requirement for this function. The test
case is more or less clear:

T_TEST_CASE(MisalignedBuiltinMemcpy)
{
         double a;
         double b;
         char buf[2 * sizeof(double)];


buf has the alignment of char.  Although it is likely to be aligned to 
sizeof(int), it very well could be less than that.  In C11 and newer, 
you can use alignas() to force buf to have the alignment of double.


         void *p;

         p = [0]; 


         p = (void *)((uintptr_t)p | 1);


IMO, this reads a bit clearer if p is just a char*.  Then you would 
initialize it to the address of buf[1] to force the misalignment.


This depends on the compiler and the system to provide a char buffer 
with the specified alignment. The (uintptr_t)p | 1 does not depend on this.




         RTEMS_OBFUSCATE_VARIABLE(p);
         a = 123e4;
         RTEMS_OBFUSCATE_VARIABLE(a);
         a *= a;
         memcpy(p, , sizeof(a));
         RTEMS_OBFUSCATE_VARIABLE(p);
         memcpy(, p, sizeof(b));
         T_eq(a, b, "%f == %f", a, b);
}

It is obvious that such a memcpy() operation should work. In
general, we
assume in RTEMS that the compiler does the right job. However, on some
architectures we have to select the right compiler options and this is
clearly under full control of the RTEMS BSP. I think we should add
something like this to the RTEMS requirements:

A call of memcpy() in C from a pointer to a double value to a
misaligned
destination buffer shall store the double value in the destination
buffer.

The formulation is quite specific, but I was not able to formulate it
more generic and keep it testable.


I've worked on at least one system where double's were silently 
equivalent to float.  Maybe a sized integer type such as int64_t would 
be a better candidate for the test case?


No, I specifically want to test situations in which the compiler 
generates floating point load/store operations to a misaligned location. The


  a = 123e4;
  RTEMS_OBFUSCATE_VARIABLE(a);
  a *= a;

is there to make the compiler load "a" into a floating point register 
and push the compiler to consider to replace the memcpy(p, , 
sizeof(a)) with a floating point store operation.


I guess we need the same requirement with double replaced by int64_t.



We have to keep in mind here that we
are not interested in the memcpy() C library function, but rather the
compiler optimized code for the memcpy() builtin function.


This is going to be difficult to verify without examining the generated 
assembly code.


Yes, if you have to look at the assembly code to be sure. Maybe we need 
some sort of a signal in the test plans, e.g. this test case needs a 
validation by inspection.




-mstrict-align would be overkill for some systems.  At least on ARMv7 
and ARMv8, many instructions do support unaligned accesses, while some 
other instructions don't.


Yes, I also think the -mstrict-align is unnecessary on most systems.

--
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  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsp/raspberrypi: Updated the console API.

[Christian Mauderer]

On 03/01/2020 13:31, Niteesh wrote:
> On Fri, Jan 3, 2020 at 3:48 PM Christian Mauderer  > wrote:
> 
> On 03/01/2020 11:11, Niteesh wrote:
> > Great, please do have a look at the FDT patch I sent today.
> 
> The FDT patch looks OK too. I thought it's clear when I said that I'll
> push it together with this one in a few days.
> 
>  
> Sorry, I was reading that on mobile and somehow missed it. 

No problem.

> 
> > I would like to work on something else now, do you have something
> > interesting
> > for me to do?
> 
> That depends on what you want to do. I think your original intention was
> to get the serial console running on the RPi3? So maybe add that?
> 
>  
> I did try that, but qemu-system-aarch64 doesn't accept exe file formats,
> I tried
> converting it to .img file, but then it doesn't run. Is there some way
> to convert to
> get elf files as output instead of exe? Is it possible to convert exe to
> elf, maybe we have
> to do some symbol table and header manipulation?

exe is a commonly used ending for an elf file. They are the same. Just
use the "file" utility on some of the generated exe files and it will
tell you that you have a

ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically
linked, with debug_info, not stripped

It seems the qemu only emulates an aarch64? I was sure that the rpi3 has
an 32bit fallback? Otherwise rpi3 would be another architecture.

> 
> It would be also great if you could write down some lines on how to
> start the BSP on qemu or on a real hardware for the manual. It doesn't
> have to be an extensive chapter. Some hints like "use objcopy like
> that..., start qemu like this, ..." can be already very helpful.
> 
>  
> I will send in a documentation patch on how to run executables in qemu in a
> couple of days. 

Thanks.

> 
> Joel suggested a tester integration for the raspberry BSP on qemu in
> another mail thread.
> 
>  
> By tester integration, you mean writing a tester.cfg which will automate
> testing using
> rtems-test right?

Right.

> 
> You might want to start to discuss your toppic for GSoC in some more
> details. Gedare gave some hints in the other mail thread too.
> 
> 
> Won't there be any idea's list? because I am literally confused about
> what to choose.
> Everything seems interesting to me, I just fear if I would pick
> something big, that I am
> not capable of finishing.

Usually that list is the open projects list which is not yet up to date.
But we allways encourage students to pick projects that interests them.

Don't worry about having a project that is too big. Just ask about
anything that interests you and we will help you defining work packets
in the right size. In the worst case you will get the answer that it's
too big for one GSoC but that you can reach some part of it.

Let's discuss the details in the other thread.

> I have gone through previous GSOC projects and have selected a few which
> I found
> quite interesting to me. I listed them in the other thread* What do you
> want to study in GSOC 2020?*
> have a look at it.
> It is still not clear of what has been accomplished? Based on the
> feedback and suggestions from
> the community, I will choose, a particular project and start working on it.
> 
> But don't hesitate to pick any other topic that picks your eye. I'm not
> giving orders here. Take them just as some hints what could be possible
> from my point of view.
> 
> >
> > On Fri, Jan 3, 2020 at 3:39 PM Christian Mauderer
> mailto:l...@c-mauderer.de>
> > >> wrote:
> >
> >     Hello Niteesh,
> >
> >     looks good to me. The UART works for a Pi1 and a Pi2. The
> Framebuffer
> >     console doesn't but it doesn't work either before this patch
> and as far
> >     as I can tell you took over the logic correctly. So I don't
> think this
> >     patch will break anything that isn't already broken.
> >
> >     I'll give the patch some more days for others to review and if
> no one
> >     objects, I'll push it together with the "Enable FDT support"
> and my two
> >     patches that fix the SDRAM stuff.
> >
> >     Best regards
> >
> >     Christian
> >
> >     On 03/01/2020 09:26, G S Niteesh wrote:
> >     > Replaces the legacy termios API with new termios API (#3034)
> >     > Replaces the custom PL011 serial driver with RTEMS arm-pl011.
> >     > Update #3034
> >     > ---
> >     >  bsps/arm/raspberrypi/console/console-config.c | 148
> 
> >     >  bsps/arm/raspberrypi/console/console_select.c | 114
> 
> >     >  bsps/arm/raspberrypi/console/fbcons.c         |  78 
> >     >  bsps/arm/raspberrypi/console/usart.c          | 167
> >     --
> >     >  

Re: Requirement Document generator tool

[Sebastian Huber]

Hello Jose,

On 03/01/2020 11:52, Jose Valdez wrote:

Should be in rtems-tools? If so, in which place?

I think this is the best place given the information I have. I would
need to have more detail before I could provide any specific direction here.


All host tools are in rtems-tools so at this point, there isn't another place.

But I agree with Chris. We need more information.


We need to know:
* Language(s) used for the tool
* Host requirements to run the tool
* Licensing of the tool

Putting the pre-qual tools into rtems-tools seems reasonable, but a discussion 
should happen within the RTEMS Project community/maintainers to do that.

JV02012019, Joel and Gedare:

We need to know:
* Language(s) used for the tool - python (>= 3.7)
* Host requirements to run the tool - Debian 10
* Licensing of the tool - BSD-2-Clause

Please read the section 4 of the document SDD-301.pdf, I am sending in attach 
(removed to go to rtems devel mailing list!!). This provides an overview of the 
tool (I think we missed to give you this overview).
For more information you may also take a look in the SRS-300.pdf and TI-003 
(just the conclusions on each section).
Note that the information presented in these documents is subjected to be 
changed, but as I said, the idea is for you to have a better understanding 
about the big picture of the project. The details will be discussed (and 
iterated) alongside the project execution.


the aim is to write all tools in the ESA pre-qualification activity in 
Python. Derivatives of existing stuff will use the respective license. 
New stuff will use the BSD-2-Clause license for code and CC-BY-SA-4.0 
for documentation.


From an RTEMS Project point of view, project-specific documentation is 
irrelevant in general. It can be used as a complementary material to 
explain things intended for integration, however, all content relevant 
to things integrated in the RTEMS Project must move to the right places 
in the RTEMS Project.


We have to settle on a specific Python version. Since Doorstop 2.0.post2 
is already selected as the tool for requirements management and it 
requires at least Python 3.6 I think it makes sense to use this version 
as well for new tools. In contrast to the build system I think a Python 
2 compatibility is unnecessary.


Tools which belong also to the work flow of an RTEMS user, e.g. the 
RTEMS Tester, should still work with Python 2.


The decisions, justification, and requirements with respect to the tool 
language selection should be recorded in the RTEMS Software Engineering 
manual.


Once a tool language is selected. We need a coding style and standard. 
We should choose an existing one, e.g.


https://www.python.org/dev/peps/pep-0008/

There should be tools to check the coding style automatically. I don't 
want the situation we have with the RTEMS sources. For Python there are 
plenty of tools, guides, and documentation available. We just have to 
pick some for the RTEMS Project and document this in the RTEMS Software 
Engineering manual.


The compatible Python versions (e.g. 3.6+), coding style (e.g. black -l 
80), documentation style (e.g. pydocstyle), test approach (standard 
Python unittest and unittest.mock), static analysis (e.g. mypy and 
pylint), code coverage, use of third-party packages, etc. need to be 
discussed with the RTEMS Project and the conclusions should be added to 
the RTEMS Software Engineering manual.


Running the checkers, test suites, code coverage, etc. should be done 
though the build system (in rtems-tools this is waf). The Doorstop 
project is a good example how this can be set up.


If you look at the current RTEMS Software Engineering manual you will 
find next to nothing with respect to Python code. You can set now the 
standards (after discussion on devel@rtems.org). You should do this 
before you send the first line of Python code for review.


Once the frame for Python development is settled. We need a high level 
description of the purpose of the tools, the inputs and the outputs. 
This high level description should be integrated in the RTEMS Project 
documentation. If you want to get things integrated in the RTEMS Project 
then you have make sure that it is good and general enough so that 
others can continue to work on it. In the worst case everything should 
be maintainable by the RTEMS Project without you in the future.


--
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  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: What do you want to study in GSOC 2020?

[Niteesh]

I have gone through previous year works and selected a few topics which I
found
interesting.
1. Basic Support for Trace Compass #3696
.
2. RTEMS testing tool project #2927 .
3. Beagle BSP: Add a flattened device tree based initialization #3784
.
4. BSPs for Simulators #2903 .
5. Improve the Raspberry Pi BSP #2899 .

I would like to know what are the future plans for these topics.
What is the current status of USB and ethernet in raspberrypi?
Does the beagle BSP require hardware or is it possible to emulate it?
Last year Vijay Kumar Banerjee worked on analysis and generation of gcov
reports.

On Thu, Jan 2, 2020 at 10:07 PM Gedare Bloom  wrote:

> On Mon, Dec 30, 2019 at 2:47 PM Christian Mauderer 
> wrote:
> >
> > On 30/12/2019 15:45, Niteesh wrote:
> > > On Mon, Dec 30, 2019 at 7:14 PM Christian Mauderer  > > > wrote:
> > >
> > > On 30/12/2019 07:25, Niteesh wrote:
> > > >
> > > >
> > > > On Mon, Dec 30, 2019 at 4:44 AM Peter Dufault  > > 
> > > > >> wrote:
> > > >
> > > >
> > > > Niteesh, what do you want to study?  Go over what most
> > > interests you
> > > > most about working in a real-time environment like RTEMS,
> and not
> > > > about working on the RPI, and look at the earlier GSOC
> projects.
> > > > Propose an ideal project for yourself and get some feedback.
> > >
> > > Peter: Thanks for starting that discussion. I started to focus too
> much
> > > on the running topics about small stuff that can be done as a
> > > preparation.
> > >
> > > >
> > > >  I love learning about how the software and hardware interact, I
> have
> > > > been programming from 9th grade and have a wide variety of
> > > > interests(networking, app development). But recently I took a
> course
> > > > called nandtotetris were we build an 8bit computer from scratch,
> we
> > > > start with NAND gates and finally finish with a Tetris game.
> > >
> > > That sounds like a really nice course. Most likely is ended in a
> bigger
> > > pile of circuit boards to have a running processor ;-)
> > >
> > > It is a free course on
> > > coursera https://www.coursera.org/learn/build-a-computer/home/welcome
> > > do check it out. It's completely simulated in software. But planning to
> > > build it on PCB.
> > >
> > >
> > > > Low-level
> > > > software, systems programming, and operating systems are always
> quite
> > > > fascinating for me. While learning about operating systems, I
> came
> > > > across the concepts of real-time systems. Back then arduino was
> > > the only
> > > > hardware I was having while searching for an RTOS to play with,
> I came
> > > > across RTEMS. RTOS was harder for me to grasp but were always
> > > > interesting, being a critical part of a system, I always wanted
> to
> > > learn
> > > > how they worked from inside. That's what bought me to
> contributing
> > > to RTOS.
> > > > I wanted to contribute to core of RTEMS, but it was a bit complex
> > > for me
> > > > to understand, so I started with driver development for RTEMS.
> > >
> > > That's where I started too. But don't hesitate to pick a more
> complex
> > > topic if you are interested in it. From what I've seen you can
> read and
> > > understand existing code quite fast compared to some other GSoC
> students
> > > we had. So I would say that you have a good chance to manage
> complex
> > > topics too.
> > >
> > > Thank you, it's quite good to hear.
> > >
> > > > After going through some of the previous GSOC projects, BSP
> > > development
> > > > and real-time tracing are what I find interesting. While also
> > > converting
> > > > the console driver of rpi to FDT based one, *Christian Mauderer
> > > > *explained how
> > > > FDT worked in FreeBSD and Linux, and RTEMS lacked that
> > > infrastructure, I
> > > > have no idea of how hard it would it, and if I am even capable of
> > > > developing it. But one proposal would be to build the FDT
> > > infrastructure
> > > > similar to FreeBSD or Linux and have the driver's probe and
> attach to
> > > > the hardware.
> > >
> > > We start to have more and more FDT based BSPs. So it would be
> great if
> > > our infrastructure would improve. But like I said: Don't hesitate
> to
> > > pick any other topic. Device drivers (and similar) are low hanging
> fruit
> > > where it is easy to get success and it isn't very likely to start
> long
> > > tedious discussions because you only touch one BSP. Therefore I
> tend to
> > > suggest them for GSoC. But GSoC isn't limited to that.

Re: [PATCH] bsp/raspberrypi: Updated the console API.

[Niteesh]

qemu-system-aarch64 doesn't support elf formats too. I tried running them
but
the qemu is stuck at 0x200. Should I change the cpu type to armv7, but by
default
Rpi3 should run 32bit applications, but not sure about qemu.

On Fri, Jan 3, 2020 at 6:01 PM Niteesh  wrote:

> On Fri, Jan 3, 2020 at 3:48 PM Christian Mauderer 
> wrote:
>
>> On 03/01/2020 11:11, Niteesh wrote:
>> > Great, please do have a look at the FDT patch I sent today.
>>
>> The FDT patch looks OK too. I thought it's clear when I said that I'll
>> push it together with this one in a few days.
>>
>
> Sorry, I was reading that on mobile and somehow missed it.
>
> > I would like to work on something else now, do you have something
>> > interesting
>> > for me to do?
>>
>> That depends on what you want to do. I think your original intention was
>> to get the serial console running on the RPi3? So maybe add that?
>>
>
> I did try that, but qemu-system-aarch64 doesn't accept exe file formats, I
> tried
> converting it to .img file, but then it doesn't run. Is there some way to
> convert to
> get elf files as output instead of exe? Is it possible to convert exe to
> elf, maybe we have
> to do some symbol table and header manipulation?
>
> It would be also great if you could write down some lines on how to
>> start the BSP on qemu or on a real hardware for the manual. It doesn't
>> have to be an extensive chapter. Some hints like "use objcopy like
>> that..., start qemu like this, ..." can be already very helpful.
>>
>
> I will send in a documentation patch on how to run executables in qemu in a
> couple of days.
>
> Joel suggested a tester integration for the raspberry BSP on qemu in
>> another mail thread.
>>
>
> By tester integration, you mean writing a tester.cfg which will automate
> testing using
> rtems-test right?
>
> You might want to start to discuss your toppic for GSoC in some more
>> details. Gedare gave some hints in the other mail thread too.
>>
>
> Won't there be any idea's list? because I am literally confused about what
> to choose.
> Everything seems interesting to me, I just fear if I would pick something
> big, that I am
> not capable of finishing.
> I have gone through previous GSOC projects and have selected a few which I
> found
> quite interesting to me. I listed them in the other thread* What do you
> want to study in GSOC 2020?*
> have a look at it.
> It is still not clear of what has been accomplished? Based on the feedback
> and suggestions from
> the community, I will choose, a particular project and start working on it.
>
> But don't hesitate to pick any other topic that picks your eye. I'm not
>> giving orders here. Take them just as some hints what could be possible
>> from my point of view.
>>
>> >
>> > On Fri, Jan 3, 2020 at 3:39 PM Christian Mauderer > > > wrote:
>> >
>> > Hello Niteesh,
>> >
>> > looks good to me. The UART works for a Pi1 and a Pi2. The
>> Framebuffer
>> > console doesn't but it doesn't work either before this patch and as
>> far
>> > as I can tell you took over the logic correctly. So I don't think
>> this
>> > patch will break anything that isn't already broken.
>> >
>> > I'll give the patch some more days for others to review and if no
>> one
>> > objects, I'll push it together with the "Enable FDT support" and my
>> two
>> > patches that fix the SDRAM stuff.
>> >
>> > Best regards
>> >
>> > Christian
>> >
>> > On 03/01/2020 09:26, G S Niteesh wrote:
>> > > Replaces the legacy termios API with new termios API (#3034)
>> > > Replaces the custom PL011 serial driver with RTEMS arm-pl011.
>> > > Update #3034
>> > > ---
>> > >  bsps/arm/raspberrypi/console/console-config.c | 148
>> 
>> > >  bsps/arm/raspberrypi/console/console_select.c | 114 
>> > >  bsps/arm/raspberrypi/console/fbcons.c |  78 
>> > >  bsps/arm/raspberrypi/console/usart.c  | 167
>> > --
>> > >  bsps/arm/raspberrypi/include/bsp.h|   2 +
>> > >  bsps/arm/raspberrypi/include/bsp/fbcons.h |  17 +-
>> > >  .../arm/raspberrypi/include/bsp/raspberrypi.h |  54 ++
>> > >  bsps/arm/raspberrypi/include/bsp/usart.h  |   5 +-
>> > >  bsps/arm/raspberrypi/start/bspstart.c |  15 ++
>> > >  c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   6 +-
>> > >  10 files changed, 199 insertions(+), 407 deletions(-)
>> > >  delete mode 100644 bsps/arm/raspberrypi/console/console_select.c
>> > >  delete mode 100644 bsps/arm/raspberrypi/console/usart.c
>> > >
>> > > diff --git a/bsps/arm/raspberrypi/console/console-config.c
>> > b/bsps/arm/raspberrypi/console/console-config.c
>> > > index d2186c918b..4000fd1c50 100644
>> > > --- a/bsps/arm/raspberrypi/console/console-config.c
>> > > +++ b/bsps/arm/raspberrypi/console/console-config.c
>> > > @@ -19,50 +19,132 @@
>> > >   */
>> > >
>> >  

Re: [PATCH] bsp/raspberrypi: Updated the console API.

[Niteesh]

On Fri, Jan 3, 2020 at 3:48 PM Christian Mauderer 
wrote:

> On 03/01/2020 11:11, Niteesh wrote:
> > Great, please do have a look at the FDT patch I sent today.
>
> The FDT patch looks OK too. I thought it's clear when I said that I'll
> push it together with this one in a few days.
>

Sorry, I was reading that on mobile and somehow missed it.

> I would like to work on something else now, do you have something
> > interesting
> > for me to do?
>
> That depends on what you want to do. I think your original intention was
> to get the serial console running on the RPi3? So maybe add that?
>

I did try that, but qemu-system-aarch64 doesn't accept exe file formats, I
tried
converting it to .img file, but then it doesn't run. Is there some way to
convert to
get elf files as output instead of exe? Is it possible to convert exe to
elf, maybe we have
to do some symbol table and header manipulation?

It would be also great if you could write down some lines on how to
> start the BSP on qemu or on a real hardware for the manual. It doesn't
> have to be an extensive chapter. Some hints like "use objcopy like
> that..., start qemu like this, ..." can be already very helpful.
>

I will send in a documentation patch on how to run executables in qemu in a
couple of days.

Joel suggested a tester integration for the raspberry BSP on qemu in
> another mail thread.
>

By tester integration, you mean writing a tester.cfg which will automate
testing using
rtems-test right?

You might want to start to discuss your toppic for GSoC in some more
> details. Gedare gave some hints in the other mail thread too.
>

Won't there be any idea's list? because I am literally confused about what
to choose.
Everything seems interesting to me, I just fear if I would pick something
big, that I am
not capable of finishing.
I have gone through previous GSOC projects and have selected a few which I
found
quite interesting to me. I listed them in the other thread* What do you
want to study in GSOC 2020?*
have a look at it.
It is still not clear of what has been accomplished? Based on the feedback
and suggestions from
the community, I will choose, a particular project and start working on it.

But don't hesitate to pick any other topic that picks your eye. I'm not
> giving orders here. Take them just as some hints what could be possible
> from my point of view.
>
> >
> > On Fri, Jan 3, 2020 at 3:39 PM Christian Mauderer  > > wrote:
> >
> > Hello Niteesh,
> >
> > looks good to me. The UART works for a Pi1 and a Pi2. The Framebuffer
> > console doesn't but it doesn't work either before this patch and as
> far
> > as I can tell you took over the logic correctly. So I don't think
> this
> > patch will break anything that isn't already broken.
> >
> > I'll give the patch some more days for others to review and if no one
> > objects, I'll push it together with the "Enable FDT support" and my
> two
> > patches that fix the SDRAM stuff.
> >
> > Best regards
> >
> > Christian
> >
> > On 03/01/2020 09:26, G S Niteesh wrote:
> > > Replaces the legacy termios API with new termios API (#3034)
> > > Replaces the custom PL011 serial driver with RTEMS arm-pl011.
> > > Update #3034
> > > ---
> > >  bsps/arm/raspberrypi/console/console-config.c | 148
> 
> > >  bsps/arm/raspberrypi/console/console_select.c | 114 
> > >  bsps/arm/raspberrypi/console/fbcons.c |  78 
> > >  bsps/arm/raspberrypi/console/usart.c  | 167
> > --
> > >  bsps/arm/raspberrypi/include/bsp.h|   2 +
> > >  bsps/arm/raspberrypi/include/bsp/fbcons.h |  17 +-
> > >  .../arm/raspberrypi/include/bsp/raspberrypi.h |  54 ++
> > >  bsps/arm/raspberrypi/include/bsp/usart.h  |   5 +-
> > >  bsps/arm/raspberrypi/start/bspstart.c |  15 ++
> > >  c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   6 +-
> > >  10 files changed, 199 insertions(+), 407 deletions(-)
> > >  delete mode 100644 bsps/arm/raspberrypi/console/console_select.c
> > >  delete mode 100644 bsps/arm/raspberrypi/console/usart.c
> > >
> > > diff --git a/bsps/arm/raspberrypi/console/console-config.c
> > b/bsps/arm/raspberrypi/console/console-config.c
> > > index d2186c918b..4000fd1c50 100644
> > > --- a/bsps/arm/raspberrypi/console/console-config.c
> > > +++ b/bsps/arm/raspberrypi/console/console-config.c
> > > @@ -19,50 +19,132 @@
> > >   */
> > >
> > >  #include 
> > > -
> > > -#include 
> > > +#include 
> > > +#include 
> > >
> > >  #include 
> > > -#include 
> > > -#include 
> > > +#include 
> > >  #include 
> > > +#include 
> > > +#include 
> > >  #include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +#include 
> > > +#include 
> > > +
> > > +#define UART0 

[PATCH 3/3] eng: Rework stakeholder chapter

[Sebastian Huber]

---
 eng/index.rst|  2 +-
 eng/prequalification.rst | 11 +++
 eng/stakeholders.rst | 24 +++-
 3 files changed, 19 insertions(+), 18 deletions(-)

diff --git a/eng/index.rst b/eng/index.rst
index 094b1e5..3340e34 100644
--- a/eng/index.rst
+++ b/eng/index.rst
@@ -25,8 +25,8 @@ RTEMS Software Engineering (|version|)
 
 preface
 mission
-prequalification
 stakeholders
+prequalification
 req-eng
 management
 test-plan
diff --git a/eng/prequalification.rst b/eng/prequalification.rst
index 2004a7c..b591d3f 100644
--- a/eng/prequalification.rst
+++ b/eng/prequalification.rst
@@ -76,3 +76,14 @@ qualification standards. It will maintain "scorecards" which
 identify how the RTEMS Project is currently doing when reviewed per each
 standard. These will be maintained in the open as community resources
 which will guide the community in improving its infrastructure.
+
+Stakeholder Involvement
+===
+
+Qualification of RTEMS is a specialized activity and only specific users
+of RTEMS will complete a formal qualification activity. The RTEMS Project
+cannot self-fund this entire activity and requires stakeholder to invest
+in an ongoing basis to ensure the any investment they make is maintained
+and viable in an ongoing basis. The RTEMS core developers view steady
+support of the qualification effort as necessary to continue to lower
+the overall costs of qualification RTEMS.
diff --git a/eng/stakeholders.rst b/eng/stakeholders.rst
index 222c340..756c462 100644
--- a/eng/stakeholders.rst
+++ b/eng/stakeholders.rst
@@ -1,23 +1,13 @@
 .. SPDX-License-Identifier: CC-BY-SA-4.0
 
-.. Copyright (C) 2018.
-.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
+.. Copyright (C) 2020 embedded brains GmbH
+.. Copyright (C) 2018 RTEMS Foundation, The RTEMS Documentation Project
 
 RTEMS Stakeholders
 **
 
-RTEMS is a community based open source project. All users are treated
-as stakeholders. It is hoped that as stakeholders, users will contribute
-to the project, sponsor core developers, and help fund the infrastructure
-required to host and manage the project.
-
-Qualification - Stakeholder Involvement
-===
-
-Qualification of RTEMS is a specialized activity and only specific users
-of RTEMS will complete a formal qualification activity. The RTEMS Project
-cannot self-fund this entire activity and requires stakeholder to invest
-in an ongoing basis to ensure the any investment they make is maintained
-and viable in an ongoing basis. The RTEMS core developers view steady
-support of the qualification effort as necessary to continue to lower
-the overall costs of qualification RTEMS.
+You are a potential RTEMS stakeholder.  RTEMS is a community based free and 
open
+source project.  All users are treated as stakeholders.  It is hoped that as
+stakeholders, users will contribute to the project, sponsor core developers, 
and
+help fund the infrastructure required to host and manage the project.  Please
+have a look at the *Support and Contributing* chapter of the :r:url:`user`.
-- 
2.16.4

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

[PATCH 1/3] common: Add URLs to manuals

[Sebastian Huber]

---
 common/rtemsdomain.py | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/common/rtemsdomain.py b/common/rtemsdomain.py
index 49d0728..018e7ed 100644
--- a/common/rtemsdomain.py
+++ b/common/rtemsdomain.py
@@ -43,7 +43,19 @@ role_url = {
"review":   ("Gerrit Code Review",  
"https://review.rtems.org/;),
"bugs": ("Bugs Database",   
"https://devel.rtems.org/wiki/Bugs/;),
"gsoc": ("Google Summer of Code", 
"https://devel.rtems.org/wiki/GSoC/;),
-   "socis":("ESA SOCIS",   
"https://devel.rtems.org/wiki/SOCIS/;)
+   "socis":("ESA SOCIS",   
"https://devel.rtems.org/wiki/SOCIS/;),
+   "bsp-howto":("RTEMS BSP and Driver Guide",  
"https://docs.rtems.org/branches/master/bsp-howto/index.html;),
+   "cpu-supplement":   ("RTEMS CPU Architecture Supplement",   
"https://docs.rtems.org/branches/master/cpu-supplement/index.html;),
+   "c-user":   ("RTEMS Classic API Guide", 
"https://docs.rtems.org/branches/master/c-user/index.html;),
+   "develenv": ("RTEMS Development Environment Guide", 
"https://docs.rtems.org/branches/master/develenv/index.html;),
+   "eclipse":  ("RTEMS Eclipse Manual",
"https://docs.rtems.org/branches/master/eclipse/index.html;),
+   "eng":  ("RTEMS Software Engineering",  
"https://docs.rtems.org/branches/master/eng/index.html;),
+   "filesystem":   ("RTEMS Filesystem Design Guide",   
"https://docs.rtems.org/branches/master/filesystem/index.html;),
+   "networking":   ("RTEMS Networking User Manual",
"https://docs.rtems.org/branches/master/networking/index.html;),
+   "posix-compliance": ("RTEMS POSIX 1003.1 Compliance Guide", 
"https://docs.rtems.org/branches/master/posix-compliance/index.html;),
+   "posix-users":  ("RTEMS POSIX API Guide",   
"https://docs.rtems.org/branches/master/posix-users/index.html;),
+   "shell":("RTEMS Shell Guide",   
"https://docs.rtems.org/branches/master/shell/index.html;),
+   "user": ("RTEMS User Manual",   
"https://docs.rtems.org/branches/master/user/index.html;),
 }
 
 
-- 
2.16.4

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

RE: Requirement Document generator tool

[Jose Valdez]

Same message with no attachs.

-Original Message-
From: Jose Valdez
Sent: sexta-feira, 3 de janeiro de 2020 10:49
To: 'Gedare Bloom'; Joel Sherrill
Cc: devel@rtems.org
Subject: RE: Requirement Document generator tool

Hello Gedare and Joel,

Please see my answers below for both of you (see JV02012019).

Please tell me, if you need further clarification.

Best regards

José

-Original Message-
From: Gedare Bloom [mailto:ged...@rtems.org]
Sent: quinta-feira, 2 de janeiro de 2020 17:21
To: Joel Sherrill
Cc: Jose Valdez; devel@rtems.org
Subject: Re: Requirement Document generator tool

Hello José et al.,

I have only a few points I would like clarified, below:

On Mon, Dec 16, 2019 at 3:35 PM Joel Sherrill  wrote:
>
>
>
> On Mon, Dec 16, 2019 at 7:29 AM Jose Valdez  wrote:
>>
>> Hello Chris,
>>
>> Thank you for your reply.
>>
>> Please find below my answers.
>>
>> José
>>
>> -Original Message-
>> From: Chris Johns [mailto:chr...@rtems.org]
>> Sent: sexta-feira, 13 de dezembro de 2019 19:09
>> To: Jose Valdez; devel@rtems.org
>> Subject: Re: Requirement Document generator tool
>>
>> On 14/12/19 3:09 am, Jose Valdez wrote:
>> > In the scope of ESA's RTEMS SMP project, we are developing a tool
>> > which will allow to generate RTEMS software documentation
>>
>> I assume this is the pre-qual effort.
>>
>> JV: That's correct.
>>
>> > (Requirements, Design, Test Specification and other software documents).
>>
>> How do these documents relate to the project's current documentation?
>> It may help to explain the purpose of each of these documents and the target 
>> user.
>
>
>
>>
>> JV: The idea of the project is to allow an user to pre-qualify RTEMS for 
>> space applications. In that sense, the goal of the tool is to save the 
>> pre-qualification effort, by creating automatically the parts of the 
>> necessary documentation, which may be automatized. Generically parts which 
>> may be automatized are:
>> -> Traceabilities (ex: Requirements against Architecture) Requirement
>> -> coverage (Tests against requirements) Test results verification
>> -> Creation of document templates source code metrics collection etc.
>>
>> The current scope is to create the documentation in accordance with ESA 
>> standard (ECSS), which defines the following necessary documents (and also 
>> the template) for a software product (note: the description text of each 
>> document was taken from ECSS, for helping you to understand the goal of each 
>> document):
>
>
> This list of documents has some of which I would expect to be
> hand-written, one-time documents. Others related to requirements,
> traceability, and tests, I would expect to be generated. Can you
> clarify which documents fall into which category?
>
> And how these documents related to RTEMS Pre-Qualification. For
> example, I don't see the need for a Software Reuse File for RTEMS.
> That would seem to be something a project adopting RTEMS might need.
>
> These documents also show an intentional bias to ECSS which is OK for
> you guys but doesn't help in the RTEMS.org broader goal of having
> technical data for qualification which fulfills the needs for multiple
> standards (NASA Quality, DO-178, automotive, etc.) Please keep in mind
> that RTEMS is a world-wide project, independent of ESA and we would like this 
> effort to be able to address the multiple stakeholders.
>
> Some of these have the same names as other quality standard, others don't.


JV02012019: Regarding your first question, a document itself may have both 
parts hand-written and generated. I understand that probably we missed to give 
you the full technical scope of the project (which is difficult by only 
exchanging e-mails). Please wait for our first input (Requirement Manager), 
which will include instructions on how to use and then you may perform your 
assessments and clarify your technical doubts.

JV02012019: The documents which are not applicable to RTEMS project (like 
Software Reuse File) will be created, but will not have any content (the 
sections will have text like "Not Applicable").

JV02012019: I understand your concern about having the tool producing output 
for other standards/applications. Unfortunately this is not possible in this 
project (due to budget). However, the philosophy for this project should be to 
open the possibility to extend the tool, and hence other users may add the 
functionality to produce the documentation according with their standards.

>
>>
>>
>> -
>> --- Software Development Plan (SDP) - Its
>> purpose is to describe the established management and development approach 
>> for the software items to be defined by a software supplier to set up a 
>> software project in accordance with the customer requirements.
>>
>> Software Product Assurance Plan (SPAP) - The purpose of the software
>> product assurance plan is to provide information on the
>> 

Re: Glossary of Terms

[Sebastian Huber]

On 03/01/2020 10:42, andrew.butterfi...@cs.tcd.ie wrote:

Hello all, and Happy New Year!


On 3 Jan 2020, at 08:10, Sebastian Huber  
wrote:


1. Should we use one shared glossary which is included in all documents?

2. Do we want to use document-specific glossaries and maintain copy-and-paste 
entries by hand?

With option 1. the glossary may contain a lot of things which are unrelated to 
a specific document. However, if the Sphinx glossary support gets improved, 
this problem may vanish. With 2. we have a maintenance problem, e.g. keeping 
the copy and paste definitions in synchronization.

What do you think?



Can we fuse 1+2 - keep a single (master) glossary file with added tags "glos1", 
"glos2" (or whatever)
We then have a script that generates the different glossaries from that one 
master?

I guess the issue is how easy it is to run that script from within the various 
document build workflows.


Yes, we can also add our own scripts to automate this. The question is 
if we want to develop special case solutions or try to fix it in the 
upstream Sphinx project. Using our own scripts would be much probably 
much easier, unless someone is familiar with the Sphinx internals.


We could for example get the terms used in a document and based on this 
generate a document-specific glossary from a master template, e.g.


grep -r --include='*.rst' ':term:`[^`]*`' -o
eng/req-eng.rst::term:`GNAT`
eng/req-eng.rst::term:`EARS`
eng/req-eng.rst::term:`API`
eng/req-eng.rst::term:`ABI`
eng/req-eng.rst::term:`source code`
eng/req-eng.rst::term:`CCB`
eng/req-eng.rst::term:`ISVV`
eng/req-eng.rst::term:`ReqIF`
eng/req-eng.rst::term:`Doorstop`
eng/req-eng.rst::term:`Doorstop`
eng/req-eng.rst::term:`YAML`
c-user/key_concepts.rst::term:`thread`
c-user/symmetric_multiprocessing_services.rst::term:`TLS`
c-user/symmetric_multiprocessing_services.rst::term:`C11`
c-user/symmetric_multiprocessing_services.rst::term:`MCS`
c-user/symmetric_multiprocessing_services.rst::term:`FIFO`
c-user/symmetric_multiprocessing_services.rst::term:`NUMA`
c-user/symmetric_multiprocessing_services.rst::term:`TCB`
c-user/symmetric_multiprocessing_services.rst::term:`TTAS`
c-user/glossary.rst::term:`C11`
c-user/glossary.rst::term:`C11`
c-user/glossary.rst::term:`C++11`
user/start/prefixes.rst::term:`prefix`
user/installation/project-sandboxing.rst::term:`prefix`
user/overview/index.rst::term:`RTEMS`
user/overview/index.rst::term:`SMP`
user/overview/index.rst::term:`APIs `
user/overview/index.rst::term:`POSIX`
user/overview/index.rst::term:`C11`
user/overview/index.rst::term:`C++11`
user/overview/index.rst::term:`GCC`
user/overview/index.rst::term:`EMB²`
user/overview/index.rst::term:`OpenMP`
user/overview/index.rst::term:`Futex`
user/overview/index.rst::term:`OpenMP`
user/overview/index.rst::term:`OMIP`
user/overview/index.rst::term:`MrsP`
user/overview/index.rst::term:`TLS`
user/overview/index.rst::term:`EDF`
user/overview/index.rst::term:`EDF`
user/overview/index.rst::term:`APA`
user/overview/index.rst::term:`IMFS`
user/overview/index.rst::term:`FAT`
user/overview/index.rst::term:`RFS`
user/overview/index.rst::term:`NFSv2`
user/overview/index.rst::term:`JFFS2`
user/overview/index.rst::term:`YAFFS2`
user/hardware/architectures.rst::term:`ABI`
eclipse/overview.rst::term:`RTEMS`

An include if used policy is not followed by the Classic API Guide since 
this feature was not available in the old texinfo framework as well.


--
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  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsp/raspberrypi: Updated the console API.

[Christian Mauderer]

On 03/01/2020 11:11, Niteesh wrote:
> Great, please do have a look at the FDT patch I sent today.

The FDT patch looks OK too. I thought it's clear when I said that I'll
push it together with this one in a few days.

> I would like to work on something else now, do you have something
> interesting
> for me to do?

That depends on what you want to do. I think your original intention was
to get the serial console running on the RPi3? So maybe add that?

It would be also great if you could write down some lines on how to
start the BSP on qemu or on a real hardware for the manual. It doesn't
have to be an extensive chapter. Some hints like "use objcopy like
that..., start qemu like this, ..." can be already very helpful.

Joel suggested a tester integration for the raspberry BSP on qemu in
another mail thread.

You might want to start to discuss your toppic for GSoC in some more
details. Gedare gave some hints in the other mail thread too.

But don't hesitate to pick any other topic that picks your eye. I'm not
giving orders here. Take them just as some hints what could be possible
from my point of view.

> 
> On Fri, Jan 3, 2020 at 3:39 PM Christian Mauderer  > wrote:
> 
> Hello Niteesh,
> 
> looks good to me. The UART works for a Pi1 and a Pi2. The Framebuffer
> console doesn't but it doesn't work either before this patch and as far
> as I can tell you took over the logic correctly. So I don't think this
> patch will break anything that isn't already broken.
> 
> I'll give the patch some more days for others to review and if no one
> objects, I'll push it together with the "Enable FDT support" and my two
> patches that fix the SDRAM stuff.
> 
> Best regards
> 
> Christian
> 
> On 03/01/2020 09:26, G S Niteesh wrote:
> > Replaces the legacy termios API with new termios API (#3034)
> > Replaces the custom PL011 serial driver with RTEMS arm-pl011.
> > Update #3034
> > ---
> >  bsps/arm/raspberrypi/console/console-config.c | 148 
> >  bsps/arm/raspberrypi/console/console_select.c | 114 
> >  bsps/arm/raspberrypi/console/fbcons.c         |  78 
> >  bsps/arm/raspberrypi/console/usart.c          | 167
> --
> >  bsps/arm/raspberrypi/include/bsp.h            |   2 +
> >  bsps/arm/raspberrypi/include/bsp/fbcons.h     |  17 +-
> >  .../arm/raspberrypi/include/bsp/raspberrypi.h |  54 ++
> >  bsps/arm/raspberrypi/include/bsp/usart.h      |   5 +-
> >  bsps/arm/raspberrypi/start/bspstart.c         |  15 ++
> >  c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   6 +-
> >  10 files changed, 199 insertions(+), 407 deletions(-)
> >  delete mode 100644 bsps/arm/raspberrypi/console/console_select.c
> >  delete mode 100644 bsps/arm/raspberrypi/console/usart.c
> >
> > diff --git a/bsps/arm/raspberrypi/console/console-config.c
> b/bsps/arm/raspberrypi/console/console-config.c
> > index d2186c918b..4000fd1c50 100644
> > --- a/bsps/arm/raspberrypi/console/console-config.c
> > +++ b/bsps/arm/raspberrypi/console/console-config.c
> > @@ -19,50 +19,132 @@
> >   */
> > 
> >  #include 
> > -
> > -#include 
> > +#include 
> > +#include 
> > 
> >  #include 
> > -#include 
> > -#include 
> > +#include 
> >  #include 
> > +#include 
> > +#include 
> >  #include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +
> > +#define UART0     "/dev/ttyS0"
> > +#define FBCONS    "/dev/fbcons"
> > +
> > +arm_pl011_context pl011_context;
> > +
> > +rpi_fb_context fb_context;
> > +
> > +static void output_char_serial(char c)
> > +{
> > +  arm_pl011_write_polled(_context.base, c);
> > +}
> > +
> > +void output_char_fb(char c)
> > +{
> > +  fbcons_write_polled(_context.base, c);
> > +}
> > 
> > -console_tbl Console_Configuration_Ports [] = {
> > -    {
> > -      .sDeviceName = "/dev/ttyS0",
> > -      .deviceType = SERIAL_CUSTOM,
> > -      .pDeviceFns = _usart_fns,
> > -      .deviceProbe = NULL,
> > -      .pDeviceFlow = NULL,
> > -      .ulCtrlPort1 = BCM2835_UART0_BASE,
> > -      .ulCtrlPort2 = 0,
> > -      .ulClock = USART0_DEFAULT_BAUD,
> > -      .ulIntVector = BCM2835_IRQ_ID_UART
> > -    },
> > -    {
> > -      .sDeviceName ="/dev/fbcons",
> > -      .deviceType = SERIAL_CUSTOM,
> > -      .pDeviceFns = _fns,
> > -      .deviceProbe = fbcons_probe,
> > -      .pDeviceFlow = NULL,
> > -    },
> > -};
> > -
> > -#define PORT_COUNT \
> > -  (sizeof(Console_Configuration_Ports) \
> > -    / sizeof(Console_Configuration_Ports [0]))
> > -
> > -unsigned long Console_Configuration_Count = PORT_COUNT;
> > +static void 

Re: [PATCH] bsp/raspberrypi: Updated the console API.

[Niteesh]

Great, please do have a look at the FDT patch I sent today.
I would like to work on something else now, do you have something
interesting
for me to do?

On Fri, Jan 3, 2020 at 3:39 PM Christian Mauderer 
wrote:

> Hello Niteesh,
>
> looks good to me. The UART works for a Pi1 and a Pi2. The Framebuffer
> console doesn't but it doesn't work either before this patch and as far
> as I can tell you took over the logic correctly. So I don't think this
> patch will break anything that isn't already broken.
>
> I'll give the patch some more days for others to review and if no one
> objects, I'll push it together with the "Enable FDT support" and my two
> patches that fix the SDRAM stuff.
>
> Best regards
>
> Christian
>
> On 03/01/2020 09:26, G S Niteesh wrote:
> > Replaces the legacy termios API with new termios API (#3034)
> > Replaces the custom PL011 serial driver with RTEMS arm-pl011.
> > Update #3034
> > ---
> >  bsps/arm/raspberrypi/console/console-config.c | 148 
> >  bsps/arm/raspberrypi/console/console_select.c | 114 
> >  bsps/arm/raspberrypi/console/fbcons.c |  78 
> >  bsps/arm/raspberrypi/console/usart.c  | 167 --
> >  bsps/arm/raspberrypi/include/bsp.h|   2 +
> >  bsps/arm/raspberrypi/include/bsp/fbcons.h |  17 +-
> >  .../arm/raspberrypi/include/bsp/raspberrypi.h |  54 ++
> >  bsps/arm/raspberrypi/include/bsp/usart.h  |   5 +-
> >  bsps/arm/raspberrypi/start/bspstart.c |  15 ++
> >  c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   6 +-
> >  10 files changed, 199 insertions(+), 407 deletions(-)
> >  delete mode 100644 bsps/arm/raspberrypi/console/console_select.c
> >  delete mode 100644 bsps/arm/raspberrypi/console/usart.c
> >
> > diff --git a/bsps/arm/raspberrypi/console/console-config.c
> b/bsps/arm/raspberrypi/console/console-config.c
> > index d2186c918b..4000fd1c50 100644
> > --- a/bsps/arm/raspberrypi/console/console-config.c
> > +++ b/bsps/arm/raspberrypi/console/console-config.c
> > @@ -19,50 +19,132 @@
> >   */
> >
> >  #include 
> > -
> > -#include 
> > +#include 
> > +#include 
> >
> >  #include 
> > -#include 
> > -#include 
> > +#include 
> >  #include 
> > +#include 
> > +#include 
> >  #include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +
> > +#define UART0 "/dev/ttyS0"
> > +#define FBCONS"/dev/fbcons"
> > +
> > +arm_pl011_context pl011_context;
> > +
> > +rpi_fb_context fb_context;
> > +
> > +static void output_char_serial(char c)
> > +{
> > +  arm_pl011_write_polled(_context.base, c);
> > +}
> > +
> > +void output_char_fb(char c)
> > +{
> > +  fbcons_write_polled(_context.base, c);
> > +}
> >
> > -console_tbl Console_Configuration_Ports [] = {
> > -{
> > -  .sDeviceName = "/dev/ttyS0",
> > -  .deviceType = SERIAL_CUSTOM,
> > -  .pDeviceFns = _usart_fns,
> > -  .deviceProbe = NULL,
> > -  .pDeviceFlow = NULL,
> > -  .ulCtrlPort1 = BCM2835_UART0_BASE,
> > -  .ulCtrlPort2 = 0,
> > -  .ulClock = USART0_DEFAULT_BAUD,
> > -  .ulIntVector = BCM2835_IRQ_ID_UART
> > -},
> > -{
> > -  .sDeviceName ="/dev/fbcons",
> > -  .deviceType = SERIAL_CUSTOM,
> > -  .pDeviceFns = _fns,
> > -  .deviceProbe = fbcons_probe,
> > -  .pDeviceFlow = NULL,
> > -},
> > -};
> > -
> > -#define PORT_COUNT \
> > -  (sizeof(Console_Configuration_Ports) \
> > -/ sizeof(Console_Configuration_Ports [0]))
> > -
> > -unsigned long Console_Configuration_Count = PORT_COUNT;
> > +static void init_ctx_arm_pl011(
> > +  const void *fdt,
> > +  int node
> > +)
> > +{
> > +  arm_pl011_context *ctx = _context;
> > +  rtems_termios_device_context_initialize(>base, "UART");
> > +  ctx->regs = raspberrypi_get_reg_of_node(fdt, node);
> > +}
> > +
> > +static void register_fb( void )
> > +{
> > +  if (fbcons_probe(_context.base) == true) {
> > +rtems_termios_device_install(
> > +  FBCONS,
> > +  _fns,
> > +  NULL,
> > +  _context.base);
> > +  }
> > +}
> > +
> > +static void console_select( void )
> > +{
> > +  const char *opt;
> > +
> > +  opt = rpi_cmdline_get_arg("--console=");
> > +
> > +  if ( opt ) {
> > +if ( strncmp( opt, "fbcons", sizeof( "fbcons" ) - 1 ) == 0 ) {
> > +  if ( rpi_video_is_initialized() > 0 ) {
> > +BSP_output_char = output_char_fb;
> > +link(FBCONS, CONSOLE_DEVICE_NAME);
> > +return ;
> > +  }
> > +}
> > +  }
> > +  BSP_output_char = output_char_serial;
> > +  link(UART0, CONSOLE_DEVICE_NAME);
> > +}
> > +
> > +static void uart_probe(void)
> > +{
> > +  static bool initialized = false;
> > +  const void *fdt;
> > +  int node;
> > +
> > +  if ( initialized ) {
> > +return ;
> > +  }
> > +
> > +  fdt = bsp_fdt_get();
> > +  node = fdt_node_offset_by_compatible(fdt, -1, "brcm,bcm2835-pl011");
> > +
> > +  init_ctx_arm_pl011(fdt, node);
> > +
> > +  initialized = true;
> > +}
> >
> >  static void output_char(char c)
> >  {
> 

Re: [PATCH] bsp/raspberrypi: Updated the console API.

[Christian Mauderer]

Hello Niteesh,

looks good to me. The UART works for a Pi1 and a Pi2. The Framebuffer
console doesn't but it doesn't work either before this patch and as far
as I can tell you took over the logic correctly. So I don't think this
patch will break anything that isn't already broken.

I'll give the patch some more days for others to review and if no one
objects, I'll push it together with the "Enable FDT support" and my two
patches that fix the SDRAM stuff.

Best regards

Christian

On 03/01/2020 09:26, G S Niteesh wrote:
> Replaces the legacy termios API with new termios API (#3034)
> Replaces the custom PL011 serial driver with RTEMS arm-pl011.
> Update #3034
> ---
>  bsps/arm/raspberrypi/console/console-config.c | 148 
>  bsps/arm/raspberrypi/console/console_select.c | 114 
>  bsps/arm/raspberrypi/console/fbcons.c |  78 
>  bsps/arm/raspberrypi/console/usart.c  | 167 --
>  bsps/arm/raspberrypi/include/bsp.h|   2 +
>  bsps/arm/raspberrypi/include/bsp/fbcons.h |  17 +-
>  .../arm/raspberrypi/include/bsp/raspberrypi.h |  54 ++
>  bsps/arm/raspberrypi/include/bsp/usart.h  |   5 +-
>  bsps/arm/raspberrypi/start/bspstart.c |  15 ++
>  c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   6 +-
>  10 files changed, 199 insertions(+), 407 deletions(-)
>  delete mode 100644 bsps/arm/raspberrypi/console/console_select.c
>  delete mode 100644 bsps/arm/raspberrypi/console/usart.c
> 
> diff --git a/bsps/arm/raspberrypi/console/console-config.c 
> b/bsps/arm/raspberrypi/console/console-config.c
> index d2186c918b..4000fd1c50 100644
> --- a/bsps/arm/raspberrypi/console/console-config.c
> +++ b/bsps/arm/raspberrypi/console/console-config.c
> @@ -19,50 +19,132 @@
>   */
>  
>  #include 
> -
> -#include 
> +#include 
> +#include 
>  
>  #include 
> -#include 
> -#include 
> +#include 
>  #include 
> +#include 
> +#include 
>  #include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#define UART0 "/dev/ttyS0"
> +#define FBCONS"/dev/fbcons"
> +
> +arm_pl011_context pl011_context;
> +
> +rpi_fb_context fb_context;
> +
> +static void output_char_serial(char c)
> +{
> +  arm_pl011_write_polled(_context.base, c);
> +}
> +
> +void output_char_fb(char c)
> +{
> +  fbcons_write_polled(_context.base, c);
> +}
>  
> -console_tbl Console_Configuration_Ports [] = {
> -{
> -  .sDeviceName = "/dev/ttyS0",
> -  .deviceType = SERIAL_CUSTOM,
> -  .pDeviceFns = _usart_fns,
> -  .deviceProbe = NULL,
> -  .pDeviceFlow = NULL,
> -  .ulCtrlPort1 = BCM2835_UART0_BASE,
> -  .ulCtrlPort2 = 0,
> -  .ulClock = USART0_DEFAULT_BAUD,
> -  .ulIntVector = BCM2835_IRQ_ID_UART
> -},
> -{
> -  .sDeviceName ="/dev/fbcons",
> -  .deviceType = SERIAL_CUSTOM,
> -  .pDeviceFns = _fns,
> -  .deviceProbe = fbcons_probe,
> -  .pDeviceFlow = NULL,
> -},
> -};
> -
> -#define PORT_COUNT \
> -  (sizeof(Console_Configuration_Ports) \
> -/ sizeof(Console_Configuration_Ports [0]))
> -
> -unsigned long Console_Configuration_Count = PORT_COUNT;
> +static void init_ctx_arm_pl011(
> +  const void *fdt,
> +  int node
> +)
> +{
> +  arm_pl011_context *ctx = _context;
> +  rtems_termios_device_context_initialize(>base, "UART");
> +  ctx->regs = raspberrypi_get_reg_of_node(fdt, node);
> +}
> +
> +static void register_fb( void )
> +{
> +  if (fbcons_probe(_context.base) == true) {
> +rtems_termios_device_install(
> +  FBCONS,
> +  _fns,
> +  NULL,
> +  _context.base);
> +  }
> +}
> +
> +static void console_select( void )
> +{
> +  const char *opt;
> +
> +  opt = rpi_cmdline_get_arg("--console=");
> +
> +  if ( opt ) {
> +if ( strncmp( opt, "fbcons", sizeof( "fbcons" ) - 1 ) == 0 ) {
> +  if ( rpi_video_is_initialized() > 0 ) {
> +BSP_output_char = output_char_fb;
> +link(FBCONS, CONSOLE_DEVICE_NAME);
> +return ;
> +  }
> +}
> +  }
> +  BSP_output_char = output_char_serial;
> +  link(UART0, CONSOLE_DEVICE_NAME);
> +}
> +
> +static void uart_probe(void)
> +{
> +  static bool initialized = false;
> +  const void *fdt;
> +  int node;
> +
> +  if ( initialized ) {
> +return ;
> +  }
> +
> +  fdt = bsp_fdt_get();
> +  node = fdt_node_offset_by_compatible(fdt, -1, "brcm,bcm2835-pl011");
> +
> +  init_ctx_arm_pl011(fdt, node);
> +
> +  initialized = true;
> +}
>  
>  static void output_char(char c)
>  {
> -  const console_fns *con =
> -Console_Configuration_Ports [Console_Port_Minor].pDeviceFns;
> +  uart_probe();
> +  output_char_serial(c);
> +}
> +
> +rtems_status_code console_initialize(
> +  rtems_device_major_number major,
> +  rtems_device_minor_number minor,
> +  void *arg
> +)
> +{
> +  rtems_termios_initialize();
>  
> -  con->deviceWritePolled((int) Console_Port_Minor, c);
> +  uart_probe();
> +  rtems_termios_device_install(
> +UART0,
> +_pl011_fns,
> +NULL,
> +_context.base
> +  );
> +
> +  

RE: [PATCH] user: Add a link for the setup of frdme310arty BSP

[Pragnesh Patel]

>-Original Message-
>From: Gedare Bloom 
>Sent: 02 January 2020 21:28
>To: Sebastian Huber 
>Cc: devel@rtems.org; Pragnesh Patel 
>Subject: Re: [PATCH] user: Add a link for the setup of frdme310arty BSP
>
>On Wed, Jan 1, 2020 at 11:21 PM Sebastian Huber
> wrote:
>>
>> On 31/12/2019 10:55, Pragnesh Patel wrote:
>> >> -Original Message-
>> >> From: Pragnesh Patel
>> >> Sent: 29 November 2019 19:14
>> >> To:sebastian.hu...@embedded-brains.de
>> >> Cc:devel@rtems.org; Pragnesh Patel
>> >> Subject: [PATCH] user: Add a link for the setup of frdme310arty BSP
>> >>
>> >> Signed-off-by: Pragnesh Patel
>> >> ---
>> >> user/bsps/bsps-riscv.rst | 3 +++
>> >> 1 file changed, 3 insertions(+)
>> >>
>> >> diff --git a/user/bsps/bsps-riscv.rst b/user/bsps/bsps-riscv.rst
>> >> index
>> >> 0799ad6..40d7606 100644
>> >> --- a/user/bsps/bsps-riscv.rst
>> >> +++ b/user/bsps/bsps-riscv.rst
>> >> @@ -93,6 +93,9 @@ The following options are available at the
>> >> configure command line.
>> >>   Enables support sifive Freedom E310 Arty board if defined to a non-
>zero
>> >>   value,otherwise it is disabled (disabled by default)
>> >>
>> >> + Please seehttps://github.com/pragnesh26992/rtems  and follow
>> >> + README-frdme310arty.md
>> >> +
>> > Any update on this patch ?
>>
>> It would be nice if most of the content of
>>
>> https://github.com/pragnesh26992/rtems/blob/master/README-
>frdme310arty
>> .md
>>
>> could move to the User Manual.
>>
>> In general, this repository gives rise to an RTEMS Project question.
>> Should it provide BIT files, device tree files, debugger configuration
>> files, etc. to set up a target (evaluation board)? If yes, where?
>> Maybe rtems-docs?
>>
>
>These things are certainly useful. Putting them in 'docs' is misleading though.
>rtems-tools or a new high-level repo might be a better fit. It should be
>discussed separately from the issue of this patch.

I agreed with @Gedare Bloom.

Right now, this repo "https://github.com/pragnesh26992/rtems/; will provide a 
BIT file,
device tree files, OpenOCD config file, a bootloader, cfg and ini files, 
.gdbinit file.

We can discuss this separately if needed.

>
>> --
>> 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  : sebastian.hu...@embedded-brains.de
>> PGP : Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>> ___
>> 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: Error while building the rtems-libbsd

[Christian Mauderer]

On 01/01/2020 16:14, Utkarsh Rai wrote:
> I have been successful in building the rtems-libbsd using 'python3
> ./waf'. Although, I had to do some weird changes to some of the files in
> the libbsd package. (These changes were done as there were several build
> errors even after the 'python ./waf' command )
> 
> 1. In the  ../freebsd/sys/netinet/in_mcast.c
> and ../../freebsd/sys/netpfil/pf/if_pfsync.c files I had to change
> the IP_MIN_MEMBERSHIPS with IP_MAX_MEMBERSHIPS .
> 
> 2. In the ../../freebsd/sys/netinet6/in6_mcast.c  and
> .../freebsd/sys/netinet/ip_carp.c files I had to
> change  IPV6_MIN_MEMBERSHIPS, to IPV6_MAX_MEMBERSHIPS,
> 
> 3. In the ../testsuite/syscalls01/test_main.c I changed the IPPROTO_SEP
> to IPPROTO_EGP .
> 
> Now, I suspect that these changes will come back to bite me as I proceed
> further as I have simply overwritten them based on build error
> messages.  It would be helpful if the community can provide its views on
> my changes and whether this is a bug or something that I am doing wrong.

I would too expect that these changes are not a good idea. In normal
case libbsd builds without any trouble.

Can you give some more information about the exact versions you use:

- Which commit of libbsd are you trying to build?
- Which rtems commit do you use?
- Which tool version do you use? If RSB: Which commit?
- What BSP do you use?

Best regards

Christian

> 
> On Tue, Dec 31, 2019 at 6:28 PM Christian Mauderer  > wrote:
> 
> On 31/12/2019 12:41, Utkarsh Rai wrote:
> > My host system has an x-86_64  architecture with ubuntu-18.04
> running on
> > top of it, I have a python2 installed.
> > Interestingly enough, when I clean up the libbsd directory and try to
> > build as a super-user, I have two observations:-
> 
> Please note that building as super user is generally not a good idea for
> any sane build environment. Although I have to say that in this case it
> provided an interesting error output ...
> 
> > 1. The build fails with the following error message:-
> > [1/4] Creating
> >
> 
> ///h/o/m/e///u/r/1/0///s/a/n/d/b/o/x///r/t/e/m/s/-/l/i/b/b/s/d///b/u/i/l/d///a/r/m/-/r/t/e/m/s/5/-/b/e/a/g/l/e/b/o/n/e/b/l/a/c/k/-/d/e/f/a/u/l/t/build-include/rtems/bsd/modules.h
> 
> ... here. That looks like some join went horrible wrong. I assume that
> there is some location in the build system where an array of paths
> should be joined but only one is given. Looks like a bug.
> 
> > [2/4] Compiling rtemsbsd/rtems/generate_kvm_symbols
> > [3/4] Compiling
> testsuite/include/rtems/bsd/test/network-config.h.in
> 
> > 
> > /bin/sh: 1:
> > .//home/ur10/sandbox/rtems-libbsd/rtemsbsd/rtems/generate_kvm_symbols:
> 
> The ./ in front is a bit odd here. Looks like an absolute path which
> (for some reason) has been forced to be local...
> 
> > not found
> >
> > Now I have checked, and the file in question is present at its
> location.
> >
> > 2. The traceback of the last calls is something like this:-
> >   File
> >
> 
> "/home/ur10/sandbox/rtems-libbsd/.waf-2.0.13-4c5a17779813574907c253ab5418388d/waflib/Build.py",
> > line 100, in execute_build
> >     self.compile()
> >   File
> >
> 
> "/home/ur10/sandbox/rtems-libbsd/.waf-2.0.13-4c5a17779813574907c253ab5418388d/waflib/Build.py",
> > line 174, in compile
> >     self.store()
> >   File
> >
> 
> "/home/ur10/sandbox/rtems-libbsd/.waf-2.0.13-4c5a17779813574907c253ab5418388d/waflib/Build.py",
> > line 153, in store
> >     Utils.writef(db+'.tmp',x,m='wb')
> >   File
> >
> 
> "/home/ur10/sandbox/rtems-libbsd/.waf-2.0.13-4c5a17779813574907c253ab5418388d/waflib/Utils.py",
> > line 155, in writef
> >     with open(fname,m)as f:
> > IOError: [Errno 2] No such file or directory:
> >
> 
> u'/home/ur10/sandbox/rtems-libbsd/build/arm-rtems5-beagleboneblack-default/.wafpickle-linux2-34017264-20.tmp'
> >
> > If I am correct,  this is a python exception for invalid file
> handling.
> > Since I have already removed the  'build'  directory, I suppose
> the call
> > should be 'w+' or 'wb+' but this does not seem to be the case. (I am
> > going out on a limb with this assumption, I may be wrong !)
> 
> You are right that it's a python exception. Most likely it's a follow up
> bug due to the wrong paths further up.
> 
> >
> > It would be very helpful if you could provide your views on the
> problem
> > and as to how I should proceed to resolve this.
> >
> 
> The solution is to find the bug in the path handling from further above.
> As a workaround could you try to use python3? Some string handling is
> different there so it might work or give a better error message.
> Just use
> 
>   python3 ./waf ...
> 

[PATCH] bsp/raspberrypi: Updated the console API.

[G S Niteesh]

Replaces the legacy termios API with new termios API (#3034)
Replaces the custom PL011 serial driver with RTEMS arm-pl011.
Update #3034
---
 bsps/arm/raspberrypi/console/console-config.c | 148 
 bsps/arm/raspberrypi/console/console_select.c | 114 
 bsps/arm/raspberrypi/console/fbcons.c |  78 
 bsps/arm/raspberrypi/console/usart.c  | 167 --
 bsps/arm/raspberrypi/include/bsp.h|   2 +
 bsps/arm/raspberrypi/include/bsp/fbcons.h |  17 +-
 .../arm/raspberrypi/include/bsp/raspberrypi.h |  54 ++
 bsps/arm/raspberrypi/include/bsp/usart.h  |   5 +-
 bsps/arm/raspberrypi/start/bspstart.c |  15 ++
 c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   6 +-
 10 files changed, 199 insertions(+), 407 deletions(-)
 delete mode 100644 bsps/arm/raspberrypi/console/console_select.c
 delete mode 100644 bsps/arm/raspberrypi/console/usart.c

diff --git a/bsps/arm/raspberrypi/console/console-config.c 
b/bsps/arm/raspberrypi/console/console-config.c
index d2186c918b..4000fd1c50 100644
--- a/bsps/arm/raspberrypi/console/console-config.c
+++ b/bsps/arm/raspberrypi/console/console-config.c
@@ -19,50 +19,132 @@
  */
 
 #include 
-
-#include 
+#include 
+#include 
 
 #include 
-#include 
-#include 
+#include 
 #include 
+#include 
+#include 
 #include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define UART0 "/dev/ttyS0"
+#define FBCONS"/dev/fbcons"
+
+arm_pl011_context pl011_context;
+
+rpi_fb_context fb_context;
+
+static void output_char_serial(char c)
+{
+  arm_pl011_write_polled(_context.base, c);
+}
+
+void output_char_fb(char c)
+{
+  fbcons_write_polled(_context.base, c);
+}
 
-console_tbl Console_Configuration_Ports [] = {
-{
-  .sDeviceName = "/dev/ttyS0",
-  .deviceType = SERIAL_CUSTOM,
-  .pDeviceFns = _usart_fns,
-  .deviceProbe = NULL,
-  .pDeviceFlow = NULL,
-  .ulCtrlPort1 = BCM2835_UART0_BASE,
-  .ulCtrlPort2 = 0,
-  .ulClock = USART0_DEFAULT_BAUD,
-  .ulIntVector = BCM2835_IRQ_ID_UART
-},
-{
-  .sDeviceName ="/dev/fbcons",
-  .deviceType = SERIAL_CUSTOM,
-  .pDeviceFns = _fns,
-  .deviceProbe = fbcons_probe,
-  .pDeviceFlow = NULL,
-},
-};
-
-#define PORT_COUNT \
-  (sizeof(Console_Configuration_Ports) \
-/ sizeof(Console_Configuration_Ports [0]))
-
-unsigned long Console_Configuration_Count = PORT_COUNT;
+static void init_ctx_arm_pl011(
+  const void *fdt,
+  int node
+)
+{
+  arm_pl011_context *ctx = _context;
+  rtems_termios_device_context_initialize(>base, "UART");
+  ctx->regs = raspberrypi_get_reg_of_node(fdt, node);
+}
+
+static void register_fb( void )
+{
+  if (fbcons_probe(_context.base) == true) {
+rtems_termios_device_install(
+  FBCONS,
+  _fns,
+  NULL,
+  _context.base);
+  }
+}
+
+static void console_select( void )
+{
+  const char *opt;
+
+  opt = rpi_cmdline_get_arg("--console=");
+
+  if ( opt ) {
+if ( strncmp( opt, "fbcons", sizeof( "fbcons" ) - 1 ) == 0 ) {
+  if ( rpi_video_is_initialized() > 0 ) {
+BSP_output_char = output_char_fb;
+link(FBCONS, CONSOLE_DEVICE_NAME);
+return ;
+  }
+}
+  }
+  BSP_output_char = output_char_serial;
+  link(UART0, CONSOLE_DEVICE_NAME);
+}
+
+static void uart_probe(void)
+{
+  static bool initialized = false;
+  const void *fdt;
+  int node;
+
+  if ( initialized ) {
+return ;
+  }
+
+  fdt = bsp_fdt_get();
+  node = fdt_node_offset_by_compatible(fdt, -1, "brcm,bcm2835-pl011");
+
+  init_ctx_arm_pl011(fdt, node);
+
+  initialized = true;
+}
 
 static void output_char(char c)
 {
-  const console_fns *con =
-Console_Configuration_Ports [Console_Port_Minor].pDeviceFns;
+  uart_probe();
+  output_char_serial(c);
+}
+
+rtems_status_code console_initialize(
+  rtems_device_major_number major,
+  rtems_device_minor_number minor,
+  void *arg
+)
+{
+  rtems_termios_initialize();
 
-  con->deviceWritePolled((int) Console_Port_Minor, c);
+  uart_probe();
+  rtems_termios_device_install(
+UART0,
+_pl011_fns,
+NULL,
+_context.base
+  );
+
+  register_fb();
+
+  console_select();
+
+  return RTEMS_SUCCESSFUL;
 }
 
 BSP_output_char_function_type BSP_output_char = output_char;
 
 BSP_polling_getchar_function_type BSP_poll_char = NULL;
+
+RTEMS_SYSINIT_ITEM(
+  uart_probe,
+  RTEMS_SYSINIT_BSP_START,
+  RTEMS_SYSINIT_ORDER_LAST
+);
\ No newline at end of file
diff --git a/bsps/arm/raspberrypi/console/console_select.c 
b/bsps/arm/raspberrypi/console/console_select.c
deleted file mode 100644
index bd246ca868..00
--- a/bsps/arm/raspberrypi/console/console_select.c
+++ /dev/null
@@ -1,114 +0,0 @@
-/**
- * @file
- *
- * @ingroup raspberrypi_console
- *
- * @brief console select
- */
-
-/*
- * Copyright (c) 2015 Yang Qiao
- *
- *  The license and distribution terms for this file may be
- *  found in the file LICENSE in this distribution or at
- *
- *  http://www.rtems.org/license/LICENSE
- *
- */
-

Re: [PATCH] bsp/raspberry: Enabled FDT support for console.

[Niteesh]

On Fri, Jan 3, 2020 at 1:51 PM Christian Mauderer 
wrote:

> On 03/01/2020 04:50, Niteesh wrote:
> > On Fri, Jan 3, 2020 at 2:26 AM Christian Mauderer  > > wrote:
> >
> > Sorry, it seems I missed some parts in the last mail. Beneath that I
> > caused a misunderstanding again.
> >
> > On 02/01/2020 20:08, G S Niteesh wrote:
> > > Replaced the older console api with newer FDT based
> > > console driver.
> > > Replaces the custom pl011 driver with RTEMS arm-pl011
> > > driver.
> > > ---
> > >  bsps/arm/raspberrypi/console/console-config.c | 156
> 
> > >  bsps/arm/raspberrypi/console/console_select.c | 114 
> > >  bsps/arm/raspberrypi/console/fbcons.c |  78 
> > >  bsps/arm/raspberrypi/console/usart.c  | 167
> > --
> > >  bsps/arm/raspberrypi/include/bsp.h|   6 +
> > >  bsps/arm/raspberrypi/include/bsp/fbcons.h |  17 +-
> > >  .../arm/raspberrypi/include/bsp/raspberrypi.h |  53 ++
> > >  bsps/arm/raspberrypi/include/bsp/usart.h  |   5 +-
> > >  bsps/arm/raspberrypi/start/bspstart.c |  15 ++
> > >  c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   7 +-
> > >  c/src/lib/libbsp/arm/raspberrypi/configure.ac
> >  |  13 ++
> > >  11 files changed, 225 insertions(+), 406 deletions(-)
> > >  delete mode 100644 bsps/arm/raspberrypi/console/console_select.c
> > >  delete mode 100644 bsps/arm/raspberrypi/console/usart.c
> > >
> > > diff --git a/bsps/arm/raspberrypi/console/console-config.c
> > b/bsps/arm/raspberrypi/console/console-config.c
> > > index d2186c918b..c306db439b 100644
> > > --- a/bsps/arm/raspberrypi/console/console-config.c
> > > +++ b/bsps/arm/raspberrypi/console/console-config.c
> > > @@ -19,50 +19,140 @@
> > >   */
> > >
> > >  #include 
> > > -
> > > -#include 
> > > +#include 
> > > +#include 
> > >
> > >  #include 
> > > -#include 
> > > -#include 
> > > +#include 
> > >  #include 
> > > +#include 
> > > +#include 
> > >  #include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +#include 
> > > +#include 
> > > +
> > > +arm_pl011_context pl011_context;
> > > +
> > > +rpi_fb_context fb_context;
> > > +
> > > +static void output_char_serial(char c)
> > > +{
> > > +  arm_pl011_write_polled(_context.base, c);
> > > +}
> > > +
> > > +void output_char_fb(char c)
> > > +{
> > > +  fbcons_write_polled(_context.base, c);
> > > +}
> > > +
> > > +static void init_ctx_arm_pl011(
> > > +  const void *fdt,
> > > +  int node
> > > +)
> > > +{
> > > +  arm_pl011_context *ctx = _context;
> > > +  rtems_termios_device_context_initialize(>base, "UART");
> > > +  ctx->regs = raspberrypi_get_reg_of_node(fdt, node);
> > > +}
> > > +
> > > +static void register_fb( void )
> > > +{
> > > +  if (fbcons_probe(_context.base) == true) {
> > > +rtems_termios_device_install(
> > > +  "/dev/fbcons",
> > > +  _fns,
> > > +  NULL,
> > > +  _context.base);
> > > +  }
> > > +}
> > >
> > > -console_tbl Console_Configuration_Ports [] = {
> > > -{
> > > -  .sDeviceName = "/dev/ttyS0",
> > > -  .deviceType = SERIAL_CUSTOM,
> > > -  .pDeviceFns = _usart_fns,
> > > -  .deviceProbe = NULL,
> > > -  .pDeviceFlow = NULL,
> > > -  .ulCtrlPort1 = BCM2835_UART0_BASE,
> > > -  .ulCtrlPort2 = 0,
> > > -  .ulClock = USART0_DEFAULT_BAUD,
> > > -  .ulIntVector = BCM2835_IRQ_ID_UART
> > > -},
> > > -{
> > > -  .sDeviceName ="/dev/fbcons",
> > > -  .deviceType = SERIAL_CUSTOM,
> > > -  .pDeviceFns = _fns,
> > > -  .deviceProbe = fbcons_probe,
> > > -  .pDeviceFlow = NULL,
> > > -},
> > > -};
> > > -
> > > -#define PORT_COUNT \
> > > -  (sizeof(Console_Configuration_Ports) \
> > > -/ sizeof(Console_Configuration_Ports [0]))
> > > -
> > > -unsigned long Console_Configuration_Count = PORT_COUNT;
> > > +static void console_select( void )
> > > +{
> > > +  const char *opt;
> > > +  const void *fdt;
> > > +  const char *console;
> > > +  int node;
> > > +
> > > +  fdt = bsp_fdt_get();
> > > +  node = fdt_path_offset(fdt, "/chosen");
> > > +
> > > +  console = fdt_getprop(fdt, node, "stdout-path", NULL);
> >
> > Sorry that I missed that on your earlier patch:
> >
> > I had a look at all the "chosen" nodes in the dtb files here:
> >
> >
> https://github.com/raspberrypi/firmware/tree/0c01dbefba45a08c47f8538d5a071a0fba6b7e83/boot
> >
> >
> > I was using the dtb file from freeBSD, that one had the chosen 

Re: [PATCH] bsp/raspberry: Enabled FDT support for console.

[Christian Mauderer]

On 03/01/2020 04:50, Niteesh wrote:
> On Fri, Jan 3, 2020 at 2:26 AM Christian Mauderer  > wrote:
> 
> Sorry, it seems I missed some parts in the last mail. Beneath that I
> caused a misunderstanding again.
> 
> On 02/01/2020 20:08, G S Niteesh wrote:
> > Replaced the older console api with newer FDT based
> > console driver.
> > Replaces the custom pl011 driver with RTEMS arm-pl011
> > driver.
> > ---
> >  bsps/arm/raspberrypi/console/console-config.c | 156 
> >  bsps/arm/raspberrypi/console/console_select.c | 114 
> >  bsps/arm/raspberrypi/console/fbcons.c         |  78 
> >  bsps/arm/raspberrypi/console/usart.c          | 167
> --
> >  bsps/arm/raspberrypi/include/bsp.h            |   6 +
> >  bsps/arm/raspberrypi/include/bsp/fbcons.h     |  17 +-
> >  .../arm/raspberrypi/include/bsp/raspberrypi.h |  53 ++
> >  bsps/arm/raspberrypi/include/bsp/usart.h      |   5 +-
> >  bsps/arm/raspberrypi/start/bspstart.c         |  15 ++
> >  c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   7 +-
> >  c/src/lib/libbsp/arm/raspberrypi/configure.ac
>  |  13 ++
> >  11 files changed, 225 insertions(+), 406 deletions(-)
> >  delete mode 100644 bsps/arm/raspberrypi/console/console_select.c
> >  delete mode 100644 bsps/arm/raspberrypi/console/usart.c
> >
> > diff --git a/bsps/arm/raspberrypi/console/console-config.c
> b/bsps/arm/raspberrypi/console/console-config.c
> > index d2186c918b..c306db439b 100644
> > --- a/bsps/arm/raspberrypi/console/console-config.c
> > +++ b/bsps/arm/raspberrypi/console/console-config.c
> > @@ -19,50 +19,140 @@
> >   */
> > 
> >  #include 
> > -
> > -#include 
> > +#include 
> > +#include 
> > 
> >  #include 
> > -#include 
> > -#include 
> > +#include 
> >  #include 
> > +#include 
> > +#include 
> >  #include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +
> > +arm_pl011_context pl011_context;
> > +
> > +rpi_fb_context fb_context;
> > +
> > +static void output_char_serial(char c)
> > +{
> > +  arm_pl011_write_polled(_context.base, c);
> > +}
> > +
> > +void output_char_fb(char c)
> > +{
> > +  fbcons_write_polled(_context.base, c);
> > +}
> > +
> > +static void init_ctx_arm_pl011(
> > +  const void *fdt,
> > +  int node
> > +)
> > +{
> > +  arm_pl011_context *ctx = _context;
> > +  rtems_termios_device_context_initialize(>base, "UART");
> > +  ctx->regs = raspberrypi_get_reg_of_node(fdt, node);
> > +}
> > +
> > +static void register_fb( void )
> > +{
> > +  if (fbcons_probe(_context.base) == true) {
> > +    rtems_termios_device_install(
> > +      "/dev/fbcons",
> > +      _fns,
> > +      NULL,
> > +      _context.base);
> > +  }
> > +}
> > 
> > -console_tbl Console_Configuration_Ports [] = {
> > -    {
> > -      .sDeviceName = "/dev/ttyS0",
> > -      .deviceType = SERIAL_CUSTOM,
> > -      .pDeviceFns = _usart_fns,
> > -      .deviceProbe = NULL,
> > -      .pDeviceFlow = NULL,
> > -      .ulCtrlPort1 = BCM2835_UART0_BASE,
> > -      .ulCtrlPort2 = 0,
> > -      .ulClock = USART0_DEFAULT_BAUD,
> > -      .ulIntVector = BCM2835_IRQ_ID_UART
> > -    },
> > -    {
> > -      .sDeviceName ="/dev/fbcons",
> > -      .deviceType = SERIAL_CUSTOM,
> > -      .pDeviceFns = _fns,
> > -      .deviceProbe = fbcons_probe,
> > -      .pDeviceFlow = NULL,
> > -    },
> > -};
> > -
> > -#define PORT_COUNT \
> > -  (sizeof(Console_Configuration_Ports) \
> > -    / sizeof(Console_Configuration_Ports [0]))
> > -
> > -unsigned long Console_Configuration_Count = PORT_COUNT;
> > +static void console_select( void )
> > +{
> > +  const char *opt;
> > +  const void *fdt;
> > +  const char *console;
> > +  int node;
> > +
> > +  fdt = bsp_fdt_get();
> > +  node = fdt_path_offset(fdt, "/chosen");
> > +
> > +  console = fdt_getprop(fdt, node, "stdout-path", NULL);
> 
> Sorry that I missed that on your earlier patch:
> 
> I had a look at all the "chosen" nodes in the dtb files here:
> 
> 
> https://github.com/raspberrypi/firmware/tree/0c01dbefba45a08c47f8538d5a071a0fba6b7e83/boot
> 
> 
> I was using the dtb file from freeBSD, that one had the chosen node.
> https://github.com/freebsd/freebsd/blob/41655e1cf1451b788f6437c91ec74bcecd2192b7/sys/gnu/dts/arm/bcm283x.dtsi#L31
> But there is no standalone DTB file from freeBSD, we have to build it so
> I'll move to the DTB
> that you mentioned, since it's more commonly used. 

OK. How did you change that? Did you remove it 

Glossary of Terms

[Sebastian Huber]

Hello,

we have currently only two glossary of terms in the RTEMS documentation set:

https://docs.rtems.org/branches/master/user/glossary/index.html

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

We also need one in the RTEMS Software Engineering manual. Sphinx has 
currently some limitations in the way glossary terms are managed:


https://github.com/sphinx-doc/sphinx/issues/3559

It would be nice if it worked like the TeX acronym package:

https://ctan.org/pkg/acronym?lang=en

The problem is that the Sphinx maintainer is not really interested in 
this feature and I don't have enough knowledge/time/skill to implement 
it myself.


How do we want to deal with glossaries in the documentation?

1. Should we use one shared glossary which is included in all documents?

2. Do we want to use document-specific glossaries and maintain 
copy-and-paste entries by hand?


With option 1. the glossary may contain a lot of things which are 
unrelated to a specific document. However, if the Sphinx glossary 
support gets improved, this problem may vanish. With 2. we have a 
maintenance problem, e.g. keeping the copy and paste definitions in 
synchronization.


What do you think?

A proper glossary is very important from my point of view, especially 
for the pre-qualification activity. Different standards define terms 
differently. We need a clear definition of terms for the RTEMS Project, 
otherwise the will have a lot of confusion if people from different 
domains task with each other.


--
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  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel