enormous .BSS size while building tests/subsys/fs/nffs_fs_api

[nvlsianpu]

Describe the bug
While building the test suite for nrf52840_pca10056 encountered oversize of SRAM. last logg I've got is

-- Build files have been written to: /home/anpu/codedev/zephyr/tests/subsys/fs/nffs_fs_api/basic/build/nrf52840_pca10056
[196/216] Linking C executable zephyr/priv_stacks_prebuilt.elf
FAILED: zephyr/priv_stacks_prebuilt.elf
: && ccache /opt/zephyr-sdk-0.9.5/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-gcc    zephyr/CMakeFiles/priv_stacks_prebuilt.dir/misc/empty_file.c.obj  -o zephyr/priv_stacks_prebuilt.elf  -T zephyr/linker_priv_stacks.cmd -Wl,-Map=/home/anpu/codedev/zephyr/tests/subsys/fs/nffs_fs_api/basic/build/nrf52840_pca10056/zephyr/zephyr.map -u_OffsetAbsSyms -u_ConfigAbsSyms -Wl,--whole-archive app/libapp.a zephyr/libzephyr.a zephyr/arch/arm/core/libarch__arm__core.a zephyr/arch/arm/core/cortex_m/libarch__arm__core__cortex_m.a zephyr/arch/arm/core/cortex_m/mpu/libarch__arm__core__cortex_m__mpu.a zephyr/lib/libc/minimal/liblib__libc__minimal.a zephyr/ext/fs/nffs/libext__fs__nffs.a zephyr/subsys/bluetooth/common/libsubsys__bluetooth__common.a zephyr/subsys/bluetooth/host/libsubsys__bluetooth__host.a zephyr/subsys/bluetooth/controller/libsubsys__bluetooth__controller.a zephyr/subsys/fs/libsubsys__fs.a zephyr/subsys/net/libsubsys__net.a zephyr/drivers/gpio/libdrivers__gpio.a zephyr/drivers/flash/libdrivers__flash.a zephyr/drivers/serial/libdrivers__serial.a zephyr/drivers/entropy/libdrivers__entropy.a zephyr/tests/ztest/libtests__ztest.a -Wl,--no-whole-archive zephyr/kernel/libkernel.a zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj -L"/opt/zephyr-sdk-0.9.5/sysroots/armv5-zephyr-eabi/usr/lib/arm-zephyr-eabi/6.2.0/armv7e-m" -L/home/anpu/codedev/zephyr/tests/subsys/fs/nffs_fs_api/basic/build/nrf52840_pca10056/zephyr -lgcc -mthumb -nostdlib -static -no-pie -Wl,-X -Wl,-N -Wl,--gc-sections -Wl,--build-id=none -Wl,--orphan-handling=warn -mabi=aapcs && :
/opt/zephyr-sdk-0.9.5/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-zephyr-eabi/gcc/arm-zephyr-eabi/6.2.0/real-ld: zephyr/priv_stacks_prebuilt.elf section `bss' will not fit in region `SRAM'
/opt/zephyr-sdk-0.9.5/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-zephyr-eabi/gcc/arm-zephyr-eabi/6.2.0/real-ld: region `SRAM' overflowed by 61838 bytes
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

Generally this test used to consume lot of RAM - but oversize by 60 KB is very unlikely for something which previously fit into memory.

To Reproduce
build the test against nrf52840_pca10056 using current master
(I have used 5ea8454)

Additional context
Build without user space memory fit into SRAM - so succeed
CONFIG_TEST_USERSPACE=n
CONFIG_APPLICATION_MEMORY=n
Is this a resolution or just hotfix?

[carlescufi]

@andrewboie @ioannisg

I cheated by adding more "virtual RAM" and generated ram_report for both userspace and no userspace, but I have no real clue where the RAM is going.

ram_report:
userspace.txt
no-userspace.txt

.map files:
userspace.map.txt
no-userspace.map.txt

[andyross]

This looks roughly as expected to me. ARM's MPU requires power-of-two sized regions, and the application data in this app looks to me like it wants a little over 176k of space. That needs to be rounded up to a 256k area, and then sit adjacent to a region containing the rest of the kernel, and also to other regions containing stacks (I'm not the expert on how these are laid out). Needless to say, none of that stuff is going to fit when the app alone wants to use the entire SRAM.

Assuming I didn't mix up the numbers, this app won't work with userspace on this board as written. It either needs to shrink to fit the constraints of how the MPU works, or just configure out the userspace setting with an appropriate comment explaining the issue.

[galak]

Not sure about the userspace stuff as I can't get it to build if I set:

CONFIG_TEST_USERSPACE=n
CONFIG_APPLICATION_MEMORY=n

However, the test has a lot of memory / ram buffers:

common/test_ram_backend.c:static u8_t rambuf[FLASH_AREA_STORAGE_SIZE];
common/nffs_test_utils.c:#define AREA_BUF_MAX_SIZE (128 * 1024)

So that's 144K right off the top of SRAM.

• k

[andrewboie]

stuff is getting rounded up to the nearest power of 2 size due to the way the MPU works.
just set CONFIG_TEST_USERSPACE=n in the prj.conf for this test, you should be good