On Fri, Nov 18, 2022 at 12:44 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote:
> On 18/11/2022 06:32, Kinsey Moore wrote: > > On Thu, Nov 17, 2022 at 4:49 PM Chris Johns <chr...@rtems.org > > <mailto:chr...@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
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel