<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 18, 2022, 8:49 AM Kinsey Moore <<a href="mailto:kinsey.moore@oarcorp.com">kinsey.moore@oarcorp.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 18, 2022 at 12:44 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank" rel="noreferrer">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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>>> 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></blockquote><div>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.</div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I agree with Sebastian that fixing the bsp is right.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></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"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>Thanks!</div><div><br></div><div>Kinsey <br></div></div></div>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank" rel="noreferrer">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div></div>