Limitation of bss section


I’m trying to create a large buffer in kernel without initialize, like:

static char buffer[256*1024*1024];

It works as my expect.
But when I set the buffer size up to 512MB and reboot,it will stuck at “Starting kernel …”
here is log message:

U-Boot 2016.07-dirty (Jan 16 2019 - 11:48:53 +0800)

Model: NVIDIA P2771-0000-500
DRAM:  7.8 GiB
MC:   Tegra SD/MMC: 0, Tegra SD/MMC: 1
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@2490000
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1...
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
213 bytes read in 91 ms (2 KiB/s)
p2771-0000 eMMC boot options
1:      primary kernel
Enter choice: 1:        primary kernel
Retrieving file: /boot/Image
14039216 bytes read in 385 ms (34.8 MiB/s)
append: root=/dev/mmcblk0p1 rw rootwait console=ttyS0,115200n8 console=tty0 OS=l4t fbcon=map:0 net.ifnames=0 memtype=0 video=tegrafb no_console_suspend=1 earlycon=uart8250,mmio32,0x03100000 nvdumper_reserved=0x2772e0000 gpt tegraid= tegra_keep_boot_clocks maxcpus=6 boot.slot_suffix= boot.ratchetvalues=0.2.1 androidboot.serialno=0423318020259 bl_prof_dataptr=0x10000@0x277040000 sdhci_tegra.en_boot_part_access=1 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4

## Flattened Device Tree blob at 92000000
   Booting using the fdt blob at 0x92000000
   reserving fdt memory region: addr=80000000 size=10000
   Using Device Tree in place at 0000000092000000, end 0000000092039e4b

Starting kernel ...

So it seems like there is a limitation size for bss section,please tell me where to set it.

Why need to do this for?
Didn’t have problem on any others platform?

It’s just a buffer using experiment in our team.
We had try on TI’s OMAP4, and it doesn’t show any problem.

Take a look at this URL (specifically the second paragraph of this location):

The part which sticks out for me is the quote from Peter van der Linden:
“The size that BSS will require at runtime is recorded in the object file, but BSS (unlike the data segment) doesn’t take up any actual space in the object file.” “Runtime” could be important for your case.

I am thinking that perhaps the size you give is not actually allocated until runtime, and that at that time there isn’t enough memory available. Although you are likely thinking that there is a lot of unused memory (which is probably “mostly” correct), the trick is that this likely has to be contiguous physical memory since you are allocating it in kernel space and this is not a user space program.

I am curious, if you check with and without the “static char buffer[25610241024]” (since both cases are bootable), after boot, what do you see from:

dmesg | egrep '( Memory:|bss)'

The above won’t necessarily solve anything, but I am curious if the whole 256MB shows up in the reserved bss or not (I suspect that since actual memory allocation only occurs at runtime the bss at the start of boot won’t increment by a full 256MB when you add this). If the full amount does not show up, then you can be certain that your declaration isn’t actually being implemented until some later event when the memory is required. In that case perhaps there is a way to reserve the memory for your application.

Is your code in the form of a module? If so, then perhaps integrating it rather than using a module format would help.