Use of rtems_fdt_* and sp01

[Joel Sherrill]

On Sat, Nov 19, 2022, 4:19 PM Chris Johns <chrisj at rtems.org> wrote:

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

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

>
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20221119/52df8c6b/attachment.htm>