[PATCH] Use EAGAIN for POSIX mq wait in ISR error

[Martin Erik Werner]

Modify the status code returned by _CORE_message_queue_Submit() when it
detects a wait bout to happen in an ISR (which would be deadly) to
return a status which translated to EAGAIN instead of ENOMEM.

(This is only relevant for POSIX message queues, since classic message
queues cannot block on send.)

The motivation is to match the "most related" errno value returned from
mq_send() and mq_timedsend() according to POSIX, via opengroup

  [EAGAIN]
  The O_NONBLOCK flag is set in the message queue description
  associated with mqdes, and the specified message queue is full.

or via the RTEMS POSIX users documentation

  EAGAIN
The message queue is non-blocking, and there is no room on the queue
for another message as specified by the mq_maxmsg.

Neither of these matches the case ofi avoided ISR wait perfectly, but
they seem to be the closest equivalent, unless it is desirable to keep a
new non-standard error for this case. It is presumed that this is not
desirable.

The previously returned ENOMEM error value is not documented in either
the opengroup or the RTEMS POSIX uses documentation.

Based on the discussion in:
https://lists.rtems.org/pipermail/devel/2020-January/056891.html
Message-Id: 
---
 cpukit/include/rtems/score/status.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/include/rtems/score/status.h 
b/cpukit/include/rtems/score/status.h
index 34002559aa..fe1f0e87e6 100644
--- a/cpukit/include/rtems/score/status.h
+++ b/cpukit/include/rtems/score/status.h
@@ -90,7 +90,7 @@ typedef enum {
   STATUS_MESSAGE_INVALID_SIZE =
 STATUS_BUILD( STATUS_CLASSIC_INVALID_SIZE, EMSGSIZE ),
   STATUS_MESSAGE_QUEUE_WAIT_IN_ISR =
-STATUS_BUILD( STATUS_CLASSIC_INTERNAL_ERROR, ENOMEM ),
+STATUS_BUILD( STATUS_CLASSIC_INTERNAL_ERROR, EAGAIN ),
   STATUS_MESSAGE_QUEUE_WAS_DELETED =
 STATUS_BUILD( STATUS_CLASSIC_OBJECT_WAS_DELETED, EBADF ),
   STATUS_MINUS_ONE =
-- 
2.20.1

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

Re: Raspberry Pi test report

[Alan Cudmore]

I tried the latest RTEMS master on my collection of single core RPis and
they all worked. I used the kernel_address=0x20 option in the
config.txt file.
The BSP did not identify the RPi Model B (26 pin GPIO header) or the RPi
Model A+ (1.1) since they use the older device ID register format. It's
probably a simple patch to identify these older models. Is it worth it,
given that they are not sold anymore?

I also tried some simple tests on the RPi 2 (v 1.1) and they worked.
However the SMP tests seem to crash on the RPi 2.
Does anyone know if the RPi 2 SMP works on the latest master? I know it has
worked in the past.
I wouldn't mind dropping the Pi 2 once the Pi 3 is working.. The model is
being phased out anyway.

It looks like there is progress being made on the RPi 3. The mini uart
support may also work on the RPi Zero W, since it has the same
wireless/bluetooth model as the 3. I can try the Pi 3 out whenever it is
ready.
Thanks for all of the recent RPI updates!
Alan



On Wed, Jan 8, 2020 at 10:26 AM Alan Cudmore  wrote:

> The Debian Linux variant for the Raspberry Pi (Raspbian) is still 32 bit
> for both the Pi 3 and 4, so I would think 32 bit ports would run on both.
> The Raspberry Pi 4 has a Quad Core A72, 1 to 4 Gigabytes of LPDDR4 SDRAM,
> Gigabit ethernet, USB 3, Wi-fi and bluetooth. I have not looked into it
> enough to see what UARTs it uses.
>
> On Wed, Jan 8, 2020 at 1:18 AM Christian Mauderer <
> christian.maude...@embedded-brains.de> wrote:
>
>> On 08/01/2020 00:24, Joel Sherrill wrote:
>> >
>> >
>> > On Tue, Jan 7, 2020 at 12:42 PM Christian Mauderer > > > wrote:
>> >
>> > Hello Alan,
>> >
>> > I pushed the patches mentioned further below. So the raspberry BSP
>> > should now work again for all raspberry 1 and 2 on the official
>> master
>> > branch. Note that the
>> >
>> > kernel_address=0x20
>> >
>> > is still necessary.
>> >
>> >
>> > This is awesome work. What about the Pi 3 and and Pi 4?  I think Niteesh
>> > has the Pi 3 working so that leaves the 4. Any idea?
>> >
>> > --joel
>> >
>>
>> As far as I followed his work Niteesh had some minimal version working
>> with the mini UART and thought about trying the existing NS16550 (after
>> I suggested that one). But I haven't seen a patch yet. So currently even
>> if some basic stuff runs there will be no console.
>>
>> Beneath that: Pi 3 and Pi 4 are both 64Bit cores. I don't have any
>> experience with aarch64. Therefore I'm not sure whether we can safely
>> use them with 32Bit fallback. It seems to work to some extend but
>> according to
>>
>> https://en.wikipedia.org/wiki/ARM_architecture#AArch64
>>
>> "ARMv8-A allows 32-bit applications to be executed in
>>  a 64-bit OS, and a 32-bit OS to be under the control
>>  of a 64-bit hypervisor."
>>
>> So I'm not sure in which situations we will run into problems. Maybe on
>> interrupts?
>>
>> Best regards
>>
>> Christian
>>
>> >
>> > Best regards
>> >
>> > Christian
>> >
>> > On 06/01/2020 11:10, Christian Mauderer wrote:
>> > > Hello Alan,
>> > >
>> > > thanks for your very detailed tests.
>> > >
>> > > On 05/01/2020 23:42, Alan Cudmore wrote:
>> > >> I finally found the time to try the latest RTEMS head on my
>> > collection
>> > >> of Raspberry Pi models.
>> > >> The last time I tried to run RTEMS on a Pi, I had trouble with
>> the
>> > >> current version of the Raspberry Pi Firmware, so I had to go back
>> > to a
>> > >> specific tag on the Rasberry Pi firmware repository to get RTEMS
>> to
>> > >> work. This time, the head of the firmware repository seems to
>> > work (at
>> > >> least on the single core models)
>> > >>
>> > >> To keep things simple, I'm just going address the single core
>> models
>> > >> here, I can follow up after I finish testing the Raspberry Pi 2.
>> > >>
>> > >> Test Setup:
>> > >> I used the git.rtems.org 
>> >  rtems master from Jan 03
>> > >> 2020.
>> > >> I used the Raspberry Pi firmware from the same date.
>> > >> The firmware can be found here:
>> > >> https://github.com/raspberrypi/firmware/tree/master/boot
>> > >> To boot an RTEMS image, you can copy all files from the above
>> "boot"
>> > >> directory on a DOS formatted SD/MicroSD card along with the RTEMS
>> > image
>> > >> (more about that in a minute).
>> > >> On the SD card, I deleted the "dtb" files, as well as the overlay
>> > >> directory. I dont think these are necessary to boot an RTEMS
>> image.
>> > >>
>> > >> I built a new arm-rtems5 toolchain using the RSB tool (head from
>> the
>> > >> same date) and built the "raspberrypi" BSP. After a quick test
>> > failed, I
>> > >> reviewed the latest mailing list posts, and ended up applying the
>> > linker
>> > >> script patch:
>> > >>
>> https://lists.rtems.o

Re: Raspberry Pi test report

[Christian Mauderer]

On 19/01/2020 20:42, Alan Cudmore wrote:
> I tried the latest RTEMS master on my collection of single core RPis and
> they all worked. I used the kernel_address=0x20 option in the
> config.txt file.
> The BSP did not identify the RPi Model B (26 pin GPIO header) or the RPi
> Model A+ (1.1) since they use the older device ID register format. It's
> probably a simple patch to identify these older models. Is it worth it,
> given that they are not sold anymore?

It's most likely only a wrong output. The memory size should be correct
now. But nonetheless it's a bug and we currently mainly support the 1
and 2. Therefore I would say it's worth a fix. Do you want to add one?

> 
> I also tried some simple tests on the RPi 2 (v 1.1) and they worked.
> However the SMP tests seem to crash on the RPi 2. 
> Does anyone know if the RPi 2 SMP works on the latest master? I know it
> has worked in the past.

I didn't test it. Do you have some details?

> I wouldn't mind dropping the Pi 2 once the Pi 3 is working.. The model
> is being phased out anyway.

Again: Still a lot of boards around. And quite possible that the older
ones that are phased out of some Linux applications are used now for
RTEMS stuff. So I'm not a fan of removing the support.

> 
> It looks like there is progress being made on the RPi 3. The mini uart
> support may also work on the RPi Zero W, since it has the same
> wireless/bluetooth model as the 3. I can try the Pi 3 out whenever it is
> ready.
> Thanks for all of the recent RPI updates! 

Please give a special thanks to Niteesh. He does most of the current
raspberry work. And thank you for the repeated testing.

Best regards

Christian

> Alan
> 
> 
> 
> On Wed, Jan 8, 2020 at 10:26 AM Alan Cudmore  > wrote:
> 
> The Debian Linux variant for the Raspberry Pi (Raspbian) is still 32
> bit for both the Pi 3 and 4, so I would think 32 bit ports would run
> on both.
> The Raspberry Pi 4 has a Quad Core A72, 1 to 4 Gigabytes of LPDDR4
> SDRAM, Gigabit ethernet, USB 3, Wi-fi and bluetooth. I have not
> looked into it enough to see what UARTs it uses.
> 
> On Wed, Jan 8, 2020 at 1:18 AM Christian Mauderer
>  > wrote:
> 
> On 08/01/2020 00:24, Joel Sherrill wrote:
> >
> >
> > On Tue, Jan 7, 2020 at 12:42 PM Christian Mauderer
> mailto:l...@c-mauderer.de>
> > >> wrote:
> >
> >     Hello Alan,
> >
> >     I pushed the patches mentioned further below. So the
> raspberry BSP
> >     should now work again for all raspberry 1 and 2 on the
> official master
> >     branch. Note that the
> >
> >         kernel_address=0x20
> >
> >     is still necessary.
> >
> >
> > This is awesome work. What about the Pi 3 and and Pi 4?  I
> think Niteesh
> > has the Pi 3 working so that leaves the 4. Any idea?
> >
> > --joel
> >
> 
> As far as I followed his work Niteesh had some minimal version
> working
> with the mini UART and thought about trying the existing NS16550
> (after
> I suggested that one). But I haven't seen a patch yet. So
> currently even
> if some basic stuff runs there will be no console.
> 
> Beneath that: Pi 3 and Pi 4 are both 64Bit cores. I don't have any
> experience with aarch64. Therefore I'm not sure whether we can
> safely
> use them with 32Bit fallback. It seems to work to some extend but
> according to
> 
>     https://en.wikipedia.org/wiki/ARM_architecture#AArch64
> 
>     "ARMv8-A allows 32-bit applications to be executed in
>      a 64-bit OS, and a 32-bit OS to be under the control
>      of a 64-bit hypervisor."
> 
> So I'm not sure in which situations we will run into problems.
> Maybe on
> interrupts?
> 
> Best regards
> 
> Christian
> 
> >
> >     Best regards
> >
> >     Christian
> >
> >     On 06/01/2020 11:10, Christian Mauderer wrote:
> >     > Hello Alan,
> >     >
> >     > thanks for your very detailed tests.
> >     >
> >     > On 05/01/2020 23:42, Alan Cudmore wrote:
> >     >> I finally found the time to try the latest RTEMS head on my
> >     collection
> >     >> of Raspberry Pi models.
> >     >> The last time I tried to run RTEMS on a Pi, I had
> trouble with the
> >     >> current version of the Raspberry Pi Firmware, so I had
> to go back
> >     to a
> >     >> specific tag on the Rasberry Pi firmware repository to
> get RTEMS to
> >     >> work. This time, the h

Re: [PATCH 6/7] bsps: Remove uses of BSP_GET_WORK_AREA_DEBUG

[Chris Johns]

On 17/12/19 4:57 pm, Sebastian Huber wrote:
> My experience tells me that doing a BSP development without a debugger is a 
> waste of time.

Sometimes getting a working debugger is more effort than getting a BSP to work.
The Pi is an example. I believe Alan used print statements.

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

Re: RTEMS Project projects?

[Chris Johns]

On 3/1/20 11:30 pm, Sebastian Huber wrote:
> I work currently on the first chapters of the RTEMS Software Engineering 
> manual.
> I came across the term "RTEMS Qualifaction Project" and also "RTEMS
> Documentation Project". What the "RTEMS Project" is, is more or less clear. 

Clear to whom? Yes to you and I and it should be after all these years. To
someone new it may not be as clear at all.

> It
> is the community, infrastructure, and the free and open RTEMS itself. But, do 
> we
> really have to emphasize that there are in addition an "RTEMS Qualifaction
> Project" and an "RTEMS Documentation Project"? 

I am fine with project, it is in common use. Webster defines it as "To form a
project; to scheme." and this seems to fit how we are using it.

> For me these are merely
> activities and components inside the RTEMS Project. What would be the mission
> statement of the projects? 

These things are not precise. KDE refers to itself as a community and encourages
new users to start projects, Fedora is a project and talks about roles users can
take.

> What about overlaps?

There is overlap.

> There is currently an RTEMS pre-qualification activity according to ECSS
> standards ongoing. So, a general term for this activity is useful. I am not 
> sure
> if we should name this "RTEMS Qualification Project". I would name it
> "pre-qualification activity in the RTEMS Project" and short "pre-qualification
> activity".

I am not in favor of this. The RTEMS Tools Project is in lots of places, too
many to change.

The splitting up of these activities into projects helps us attract new users
who may think RTEMS is too complex and not accessible for them. Maybe focusing
on a smaller activity or project may be a way to get started.

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

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

[Chris Johns]

On 3/1/20 11:31 pm, Sebastian Huber wrote:
> ---
>  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";),
>  }
>  

Oh, please do not add references to the online docs. This is rather fragile, ie
branches are broken.

I hope it has not been pushed.

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

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

[Chris Johns]

On 20/1/20 4:38 pm, Chris Johns wrote:
> On 3/1/20 11:31 pm, Sebastian Huber wrote:
>> ---
>>  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";),
>>  }
>>  
> 
> Oh, please do not add references to the online docs. This is rather fragile, 
> ie
> branches are broken.
> 
> I hope it has not been pushed.

It has been. This need to be reverted.

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