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 <kinsey.moore at oarcorp.com
> <mailto:kinsey.moore at oarcorp.com>> wrote:
>     On Fri, Nov 18, 2022 at 12:44 AM Sebastian Huber
>     <sebastian.huber at embedded-brains.de
>     <mailto:sebastian.huber at embedded-brains.de>> wrote:
>         On 18/11/2022 06:32, Kinsey Moore wrote:
>         > On Thu, Nov 17, 2022 at 4:49 PM Chris Johns <chrisj at rtems.org
>         <mailto:chrisj at rtems.org>
>         > <mailto:chrisj at rtems.org <mailto:chrisj at 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.
> 
> 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