Use of rtems_fdt_* and sp01

[Kinsey Moore]

On Fri, Nov 18, 2022 at 12:44 AM Sebastian Huber <
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>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20221118/1ad11c85/attachment.htm>