Re: Use of rtems_fdt_* and sp01

[Chris Johns]

On 20/11/2022 10:25 am, Joel Sherrill wrote:
> On Sat, Nov 19, 2022, 4:19 PM Chris Johns  > wrote:
> 
> On 19/11/22 2:13 am, Joel Sherrill wrote:
> > On Fri, Nov 18, 2022, 8:49 AM Kinsey Moore  
> > >> 
> wrote:
> >     On Fri, Nov 18, 2022 at 12:44 AM Sebastian Huber
> >      
> >      >> wrote:
> >         On 18/11/2022 06:32, Kinsey Moore wrote:
> >         > On Thu, Nov 17, 2022 at 4:49 PM Chris Johns  
> >         >
> >         > 
>  >         >
> >         >     On 18/11/2022 2:39 am, Kinsey Moore wrote:
> >         >      > I recently added FDT support to the AArch64 ZynqMP 
> BSPs to
> >         >     support an optional
> >         >      > management console and managing ethernet parameters for
> LibBSD.
> >         >     Use of the
> >         >      > rtems_fdt_* functions implies use of malloc which adds 
> 4
> bytes in
> >         >     the TLS space.
> >         >      > The sp01 test uses rtems_task_construct and specifies a
> maximum
> >         >     TLS size of 0
> >         >      > bytes which causes a failure which the non-zero TLS 
> size is
> >         >     checked against the
> >         >      > maximum TLS size of 0.
> >         >
> >         >     Does this mean there exists a requirement a BSPs cannot
> internally
> >         >     use the heap?
> >         >
> >         >
> >         > That appears to be the case, at least practically. It works
> fine, but it
> >         > causes a test failure...
> >
> >         You can use the heap during system initialization. However, you 
> should
> >         avoid dependencies on errno, so instead of using 
> malloc()/calloc() use
> >         rtems_malloc()/rtems_calloc(). Independent of this, if the BSP
> >         initialization can easily avoid the heap, then it should not use
> the heap.
> >
> >         >
> >         >
> >         >     Maybe the test needs to be adjusted?
> >         >
> >         >
> >         > That's part of why I sent this to the list. I was unsure 
> whether
> it was
> >         > allowed or whether the test had bad assumptions baked into it.
> >
> >         The tests check specific aspects of the thread-local storage
> support and
> >         this works only if the BSP does not depend on TLS objects such 
> as
> errno.
> >
> >     This affects several other tests as well, so I guess my solution 
> here is
> >     either to alter the rtems_fdt_ wrappers to avoid dependencies on 
> TLS or
> >     proceed with the existing patch that uses the non-wrapped FDT 
> functions.
> >
> > I agree with Sebastian that fixing the bsp is right.
> >
> > But also rtems_ fdt methods should be changed to use rtems_malloc. That 
> would
> > leave those methods useful. They are broken now for many intended use 
> cases.
> 
> We are currently reviewing the support for ftbo files in Linux 
> (petalinux) with
> a view to seeing how we can support them on RTEMS. I see FDT being use 
> more and
> more in RTEMS and with a number of different use cases and flows there is 
> a need
> to try and unify how we handle them. I see benefits if we can support a 
> similar
> dtbo model as Linux and if that happens the specific area in question in
> rtems-fst can be move over to using it.
> 
> 
> FWIW Kinsey's patch to the rtems_fdt methods eliminated two coverity issues.

Yes and that is a worth while change. Thanks.

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

Re: Use of rtems_fdt_* and sp01

[Joel Sherrill]

On Sat, Nov 19, 2022, 4:19 PM Chris Johns  wrote:

> On 19/11/22 2:13 am, Joel Sherrill wrote:
> > On Fri, Nov 18, 2022, 8:49 AM Kinsey Moore  > > wrote:
> > On Fri, Nov 18, 2022 at 12:44 AM Sebastian Huber
> >  > > wrote:
> > On 18/11/2022 06:32, Kinsey Moore wrote:
> > > On Thu, Nov 17, 2022 at 4:49 PM Chris Johns  > 
> > > >> wrote:
> > >
> > > On 18/11/2022 2:39 am, Kinsey Moore wrote:
> > >  > I recently added FDT support to the AArch64 ZynqMP BSPs
> to
> > > support an optional
> > >  > management console and managing ethernet parameters for
> LibBSD.
> > > Use of the
> > >  > rtems_fdt_* functions implies use of malloc which adds
> 4 bytes in
> > > the TLS space.
> > >  > The sp01 test uses rtems_task_construct and specifies a
> maximum
> > > TLS size of 0
> > >  > bytes which causes a failure which the non-zero TLS
> size is
> > > checked against the
> > >  > maximum TLS size of 0.
> > >
> > > Does this mean there exists a requirement a BSPs cannot
> internally
> > > use the heap?
> > >
> > >
> > > That appears to be the case, at least practically. It works
> fine, but it
> > > causes a test failure...
> >
> > You can use the heap during system initialization. However, you
> should
> > avoid dependencies on errno, so instead of using
> malloc()/calloc() use
> > rtems_malloc()/rtems_calloc(). Independent of this, if the BSP
> > initialization can easily avoid the heap, then it should not use
> the heap.
> >
> > >
> > >
> > > Maybe the test needs to be adjusted?
> > >
> > >
> > > That's part of why I sent this to the list. I was unsure
> whether it was
> > > allowed or whether the test had bad assumptions baked into it.
> >
> > The tests check specific aspects of the thread-local storage
> support and
> > this works only if the BSP does not depend on TLS objects such
> as errno.
> >
> > This affects several other tests as well, so I guess my solution
> here is
> > either to alter the rtems_fdt_ wrappers to avoid dependencies on TLS
> or
> > proceed with the existing patch that uses the non-wrapped FDT
> functions.
> >
> > I agree with Sebastian that fixing the bsp is right.
> >
> > But also rtems_ fdt methods should be changed to use rtems_malloc. That
> would
> > leave those methods useful. They are broken now for many intended use
> cases.
>
> We are currently reviewing the support for ftbo files in Linux (petalinux)
> with
> a view to seeing how we can support them on RTEMS. I see FDT being use
> more and
> more in RTEMS and with a number of different use cases and flows there is
> a need
> to try and unify how we handle them. I see benefits if we can support a
> similar
> dtbo model as Linux and if that happens the specific area in question in
> rtems-fst can be move over to using it.
>

FWIW Kinsey's patch to the rtems_fdt methods eliminated two coverity issues.

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

Re: Use of rtems_fdt_* and sp01

[Chris Johns]

On 19/11/22 2:13 am, Joel Sherrill wrote:
> On Fri, Nov 18, 2022, 8:49 AM Kinsey Moore  > wrote:
> On Fri, Nov 18, 2022 at 12:44 AM Sebastian Huber
>  > wrote:
> On 18/11/2022 06:32, Kinsey Moore wrote:
> > On Thu, Nov 17, 2022 at 4:49 PM Chris Johns  
> > >> wrote:
> >
> >     On 18/11/2022 2:39 am, Kinsey Moore wrote:
> >      > I recently added FDT support to the AArch64 ZynqMP BSPs to
> >     support an optional
> >      > management console and managing ethernet parameters for 
> LibBSD.
> >     Use of the
> >      > rtems_fdt_* functions implies use of malloc which adds 4 
> bytes in
> >     the TLS space.
> >      > The sp01 test uses rtems_task_construct and specifies a 
> maximum
> >     TLS size of 0
> >      > bytes which causes a failure which the non-zero TLS size is
> >     checked against the
> >      > maximum TLS size of 0.
> >
> >     Does this mean there exists a requirement a BSPs cannot 
> internally
> >     use the heap?
> >
> >
> > That appears to be the case, at least practically. It works fine, 
> but it
> > causes a test failure...
> 
> You can use the heap during system initialization. However, you should
> avoid dependencies on errno, so instead of using malloc()/calloc() use
> rtems_malloc()/rtems_calloc(). Independent of this, if the BSP
> initialization can easily avoid the heap, then it should not use the 
> heap.
> 
> >
> >
> >     Maybe the test needs to be adjusted?
> >
> >
> > That's part of why I sent this to the list. I was unsure whether it 
> was
> > allowed or whether the test had bad assumptions baked into it.
> 
> The tests check specific aspects of the thread-local storage support 
> and
> this works only if the BSP does not depend on TLS objects such as 
> errno.
> 
> This affects several other tests as well, so I guess my solution here is
> either to alter the rtems_fdt_ wrappers to avoid dependencies on TLS or
> proceed with the existing patch that uses the non-wrapped FDT functions.
> 
> I agree with Sebastian that fixing the bsp is right.
> 
> But also rtems_ fdt methods should be changed to use rtems_malloc. That would
> leave those methods useful. They are broken now for many intended use cases.

We are currently reviewing the support for ftbo files in Linux (petalinux) with
a view to seeing how we can support them on RTEMS. I see FDT being use more and
more in RTEMS and with a number of different use cases and flows there is a need
to try and unify how we handle them. I see benefits if we can support a similar
dtbo model as Linux and if that happens the specific area in question in
rtems-fst can be move over to using it.

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

Re: Use of rtems_fdt_* and sp01

[Joel Sherrill]

On Fri, Nov 18, 2022, 8:49 AM Kinsey Moore  wrote:

>
> On Fri, Nov 18, 2022 at 12:44 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 18/11/2022 06:32, Kinsey Moore wrote:
>> > On Thu, Nov 17, 2022 at 4:49 PM Chris Johns > > > wrote:
>> >
>> > On 18/11/2022 2:39 am, Kinsey Moore wrote:
>> >  > I recently added FDT support to the AArch64 ZynqMP BSPs to
>> > support an optional
>> >  > management console and managing ethernet parameters for LibBSD.
>> > Use of the
>> >  > rtems_fdt_* functions implies use of malloc which adds 4 bytes in
>> > the TLS space.
>> >  > The sp01 test uses rtems_task_construct and specifies a maximum
>> > TLS size of 0
>> >  > bytes which causes a failure which the non-zero TLS size is
>> > checked against the
>> >  > maximum TLS size of 0.
>> >
>> > Does this mean there exists a requirement a BSPs cannot internally
>> > use the heap?
>> >
>> >
>> > That appears to be the case, at least practically. It works fine, but
>> it
>> > causes a test failure...
>>
>> You can use the heap during system initialization. However, you should
>> avoid dependencies on errno, so instead of using malloc()/calloc() use
>> rtems_malloc()/rtems_calloc(). Independent of this, if the BSP
>> initialization can easily avoid the heap, then it should not use the heap.
>>
>> >
>> >
>> > Maybe the test needs to be adjusted?
>> >
>> >
>> > That's part of why I sent this to the list. I was unsure whether it was
>> > allowed or whether the test had bad assumptions baked into it.
>>
>> The tests check specific aspects of the thread-local storage support and
>> this works only if the BSP does not depend on TLS objects such as errno.
>>
>> This affects several other tests as well, so I guess my solution here is
> either to alter the rtems_fdt_ wrappers to avoid dependencies on TLS or
> proceed with the existing patch that uses the non-wrapped FDT functions.
>

I agree with Sebastian that fixing the bsp is right.

But also rtems_ fdt methods should be changed to use rtems_malloc. That
would leave those methods useful. They are broken now for many intended use
cases.


> Thanks!
>
> Kinsey
> ___
> 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: Use of rtems_fdt_* and sp01

[Sebastian Huber]

On 18/11/2022 15:49, Kinsey Moore wrote:


On Fri, Nov 18, 2022 at 12:44 AM Sebastian Huber 
> wrote:


On 18/11/2022 06:32, Kinsey Moore wrote:
 > On Thu, Nov 17, 2022 at 4:49 PM Chris Johns mailto:chr...@rtems.org>
 > >> wrote:
 >
 >     On 18/11/2022 2:39 am, Kinsey Moore wrote:
 >      > I recently added FDT support to the AArch64 ZynqMP BSPs to
 >     support an optional
 >      > management console and managing ethernet parameters for
LibBSD.
 >     Use of the
 >      > rtems_fdt_* functions implies use of malloc which adds 4
bytes in
 >     the TLS space.
 >      > The sp01 test uses rtems_task_construct and specifies a
maximum
 >     TLS size of 0
 >      > bytes which causes a failure which the non-zero TLS size is
 >     checked against the
 >      > maximum TLS size of 0.
 >
 >     Does this mean there exists a requirement a BSPs cannot
internally
 >     use the heap?
 >
 >
 > That appears to be the case, at least practically. It works fine,
but it
 > causes a test failure...

You can use the heap during system initialization. However, you should
avoid dependencies on errno, so instead of using malloc()/calloc() use
rtems_malloc()/rtems_calloc(). Independent of this, if the BSP
initialization can easily avoid the heap, then it should not use the
heap.

 >
 >
 >     Maybe the test needs to be adjusted?
 >
 >
 > That's part of why I sent this to the list. I was unsure whether
it was
 > allowed or whether the test had bad assumptions baked into it.

The tests check specific aspects of the thread-local storage support
and
this works only if the BSP does not depend on TLS objects such as errno.

This affects several other tests as well, so I guess my solution here is 
either to alter the rtems_fdt_ wrappers to avoid dependencies on TLS or 
proceed with the existing patch that uses the non-wrapped FDT functions.


Your patch is pretty straight forward and gets rid of a heap usage 
during initialization. I would check it in anyway.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Use of rtems_fdt_* and sp01

[Kinsey Moore]

On Fri, Nov 18, 2022 at 12:44 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 18/11/2022 06:32, Kinsey Moore wrote:
> > On Thu, Nov 17, 2022 at 4:49 PM Chris Johns  > > wrote:
> >
> > On 18/11/2022 2:39 am, Kinsey Moore wrote:
> >  > I recently added FDT support to the AArch64 ZynqMP BSPs to
> > support an optional
> >  > management console and managing ethernet parameters for LibBSD.
> > Use of the
> >  > rtems_fdt_* functions implies use of malloc which adds 4 bytes in
> > the TLS space.
> >  > The sp01 test uses rtems_task_construct and specifies a maximum
> > TLS size of 0
> >  > bytes which causes a failure which the non-zero TLS size is
> > checked against the
> >  > maximum TLS size of 0.
> >
> > Does this mean there exists a requirement a BSPs cannot internally
> > use the heap?
> >
> >
> > That appears to be the case, at least practically. It works fine, but it
> > causes a test failure...
>
> You can use the heap during system initialization. However, you should
> avoid dependencies on errno, so instead of using malloc()/calloc() use
> rtems_malloc()/rtems_calloc(). Independent of this, if the BSP
> initialization can easily avoid the heap, then it should not use the heap.
>
> >
> >
> > Maybe the test needs to be adjusted?
> >
> >
> > That's part of why I sent this to the list. I was unsure whether it was
> > allowed or whether the test had bad assumptions baked into it.
>
> The tests check specific aspects of the thread-local storage support and
> this works only if the BSP does not depend on TLS objects such as errno.
>
> This affects several other tests as well, so I guess my solution here is
either to alter the rtems_fdt_ wrappers to avoid dependencies on TLS or
proceed with the existing patch that uses the non-wrapped FDT functions.

Thanks!

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

Re: Use of rtems_fdt_* and sp01

[Sebastian Huber]

On 18/11/2022 06:32, Kinsey Moore wrote:
On Thu, Nov 17, 2022 at 4:49 PM Chris Johns > wrote:


On 18/11/2022 2:39 am, Kinsey Moore wrote:
 > I recently added FDT support to the AArch64 ZynqMP BSPs to
support an optional
 > management console and managing ethernet parameters for LibBSD.
Use of the
 > rtems_fdt_* functions implies use of malloc which adds 4 bytes in
the TLS space.
 > The sp01 test uses rtems_task_construct and specifies a maximum
TLS size of 0
 > bytes which causes a failure which the non-zero TLS size is
checked against the
 > maximum TLS size of 0.

Does this mean there exists a requirement a BSPs cannot internally
use the heap?


That appears to be the case, at least practically. It works fine, but it 
causes a test failure...


You can use the heap during system initialization. However, you should 
avoid dependencies on errno, so instead of using malloc()/calloc() use 
rtems_malloc()/rtems_calloc(). Independent of this, if the BSP 
initialization can easily avoid the heap, then it should not use the heap.





Maybe the test needs to be adjusted?


That's part of why I sent this to the list. I was unsure whether it was 
allowed or whether the test had bad assumptions baked into it.


The tests check specific aspects of the thread-local storage support and 
this works only if the BSP does not depend on TLS objects such as errno.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Use of rtems_fdt_* and sp01

[Kinsey Moore]

On Thu, Nov 17, 2022 at 4:49 PM Chris Johns  wrote:

> On 18/11/2022 2:39 am, Kinsey Moore wrote:
> > I recently added FDT support to the AArch64 ZynqMP BSPs to support an
> optional
> > management console and managing ethernet parameters for LibBSD. Use of
> the
> > rtems_fdt_* functions implies use of malloc which adds 4 bytes in the
> TLS space.
> > The sp01 test uses rtems_task_construct and specifies a maximum TLS size
> of 0
> > bytes which causes a failure which the non-zero TLS size is checked
> against the
> > maximum TLS size of 0.
>
> Does this mean there exists a requirement a BSPs cannot internally use the
> heap?
>

That appears to be the case, at least practically. It works fine, but it
causes a test failure...

>
> Maybe the test needs to be adjusted?
>

That's part of why I sent this to the list. I was unsure whether it was
allowed or whether the test had bad assumptions baked into it.

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

Re: Use of rtems_fdt_* and sp01

[Chris Johns]

On 18/11/2022 2:39 am, Kinsey Moore wrote:
> I recently added FDT support to the AArch64 ZynqMP BSPs to support an optional
> management console and managing ethernet parameters for LibBSD. Use of the
> rtems_fdt_* functions implies use of malloc which adds 4 bytes in the TLS 
> space.
> The sp01 test uses rtems_task_construct and specifies a maximum TLS size of 0
> bytes which causes a failure which the non-zero TLS size is checked against 
> the
> maximum TLS size of 0.

Does this mean there exists a requirement a BSPs cannot internally use the heap?

Maybe the test needs to be adjusted?
> It appears that other BSPs that use FDT data avoid the rtems_fdt_* calls,
> possibly because they weren’t available until recently, and this is the path
> that I’ll be following to resolve this issue for the moment.
> 
> I thought it would be good to bring this up if the rtems_fdt_* wrappers are to
> be more widely useful.

FDT support seems to be based around isolated BSPs and how they use the FDT. I
guess this approach has been done to minimise the impact on RTEMS and I would
have most likely followed a similar path.

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