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