dts: nxp: kw41z : fix ram size issue

[hakehuang]

frdm_kw41z ram size is 96k if base starting from 0x20000000

fixing: #66154

[thedjnK]

What are you doing, no

[hakehuang]

@thedjnK , the code original list as below

choice LIBC_IMPLEMENTATION
        prompt "C Library Implementation"
        default EXTERNAL_LIBC if NATIVE_BUILD && !(NATIVE_LIBRARY && POSIX_API)
        default PICOLIBC
        default NEWLIB_LIBC if REQUIRES_FULL_LIBC
        default MINIMAL_LIBC

and even we define the REQUIRES_FULL_LIBC, LIBC_IMPLEMENTATION is still PICOLIBC, so this is a strange here, either we change the

 default NEWLIB_LIBC if REQUIRES_FULL_LIBC

to

 default NEWLIB_LIBC

or do what I change above.

Besides, I do think force back the newlibc to solve this problem is not good. and I will try keith-packard's recommandations.

[thedjnK]

It is this way on purpose and it is correct, it will use external if needed, it will use picolibc if it can (which should be the default if at all possible), it will then fall back to newlibc if picolibc cannot be used or minimal libc if a full libc is not needed, leave the ordering alone

[hakehuang]

ok

[keith-packard]

@keith-packard I am new to picolibc and would you look at this issue? just curious why newlibc can work and picolibc does not. Thanks a lot

It's often unrelated to the C library -- picolibc selects thread local storage support, and that often finds bugs in underlying SoC support code. Picolibc also enables the common malloc code and sets the default malloc arena to all available memory. You can work around bugs with the latter by disabling malloc (#65434 does this automatically when malloc is not used) or by setting a smaller size for the malloc arena.

[hakehuang]

It's often unrelated to the C library -- picolibc selects thread local storage support, and that often finds bugs in underlying SoC support code. Picolibc also enables the common malloc code and sets the default malloc arena to all available memory. You can work around bugs with the latter by disabling malloc (#65434 does this automatically when malloc is not used) or by setting a smaller size for the malloc arena.

reduce the malloc size by doing below solve this issue: frdm_kw41z has 128K ram

CONFIG_PICOLIBC_HEAP_SIZE=81920
or
COMMON_LIBC_MALLOC_ARENA_SIZE=81920

however (#65434) does not work for this issue

[keith-packard]

reduce the malloc size by doing below solve this issue:

CONFIG_PICOLIBC_HEAP_SIZE=8192

Ok, sounds like there's a problem on this platform where the default of using 'all available memory' isn't working on this platform. I wonder if it's similar to the problem found in #67009 where the memory size setting was not correct unless the application took steps to configure the platform memory controller?

however (#65434) does not work for this issue

Thanks for checking; it sounds like your application is using malloc and so simply disabling it when unused (as #65434 does) didn't help.

It looks like the default Zephyr config for this platform sets the amount of memory to 128kB. Does all of that memory actually work at startup time? Or is there some additional configuration necessary?

[hakehuang]

Ok, sounds like there's a problem on this platform where the default of using 'all available memory' isn't working on this platform. I wonder if it's similar to the problem found in #67009 where the memory size setting was not correct unless the application took steps to configure the platform memory controller?

Thanks @keith-packard , you are right, the root cause for this failure is because the ram size is wrongly config as 128K starting from 0x20000000 in dts file, which should be 96K. after fixing this in dts file, this issue is fixed.

[thedjnK]

Just revert this

[hakehuang]

ok

[thedjnK]

I assume you would want to update the board's .yml too?

[hakehuang]

I assume you would want to update the board's .yml too?

the overall ram size is 128K, however in our dts file we set to use 96k, as the base address is starting from 0x2000000, so the ox1fff000 to 0x1fffffff, 32K is not used, see below comments in frdm_k64f.yaml

/* The on-chip SRAM is split into SRAM_L and SRAM_U regions that form a
	 * contiguous block in the memory map, however misaligned accesses
	 * across the 0x2000_0000 boundary are not supported in the Arm
	 * Cortex-M4 architecture. For clarity and to avoid the temptation for
	 * someone to extend sram0 without solving this issue, we define two
	 * separate memory nodes here and only use the upper one for now. A
	 * potential solution has been proposed in binutils:
	 * https://sourceware.org/ml/binutils/2017-02/msg00250.html
	 */

and frdm_kw41z has the same issue. Is is OK, if I I keep the frdm_kw41z.yaml as is.

[thedjnK]

I assume you would want to update the board's .yml too?

the overall ram size is 128K, however in our dts file we set to use 96k, as the base address is starting from 0x2000000, so the ox1fff000 to 0x1fffffff, 32K is not used, see below comments in frdm_k64f.yaml

/* The on-chip SRAM is split into SRAM_L and SRAM_U regions that form a
	 * contiguous block in the memory map, however misaligned accesses
	 * across the 0x2000_0000 boundary are not supported in the Arm
	 * Cortex-M4 architecture. For clarity and to avoid the temptation for
	 * someone to extend sram0 without solving this issue, we define two
	 * separate memory nodes here and only use the upper one for now. A
	 * potential solution has been proposed in binutils:
	 * https://sourceware.org/ml/binutils/2017-02/msg00250.html
	 */

and frdm_kw41z has the same issue. Is is OK, if I I keep the frdm_kw41z.yaml as is.

Well not really no, that means any samples/tests which specifically require >96KiB and <=128KiB will wrongly try running on this board which will fail

[hakehuang]

Well not really no, that means any samples/tests which specifically require >96KiB and <=128KiB will wrongly try running on this board which will fail

Good point, I will create another PR tio fix all NXP boards related to this. @thedjnK