Hi, I am currently writing a bare metal OS and I am wondering if there is a non-hardcoded method of detecting all of the free ram (I.e. not used by the VC or by MMIO) on every raspberry PI? I know that the mailbox can be used to detect a single region of memory (on the qemu emulated raspb pi 1a+ I get a base of 0x0, and a length of 0x1c000000), but I know that for other raspberry PIs, the total ram is split in two by the GPU memory.

I know that on the raspberry pi 1, detecting memory after the kernel is as simple as putting a tag in the linker script at the end of the kernel image, and assuming that all memory before that is used by DTB and CLI args, but also know that on other versions the kernel is loaded in 0x200000 or 0x800000, so there must be some free RAM below that region.

Is there any programatic way to solve this or do you have to hardcode all of the memory regions?

the proper method is to use device-tree

it gives you a list of addr+size pairs, telling you exactly which ram is available for use by the arm cores

cleverca22 wrote: ↑

Sun Mar 30, 2025 10:53 am

the proper method is to use device-tree

it gives you a list of addr+size pairs, telling you exactly which ram is available for use by the arm cores

Hmm, when I tried this using the rapberry pi 1 DTB, and looked at the memory map using the device tree dump in DTS format, this is what was in the memory section:

The dtb was called bcm2708-rpi-b-plus.dtb.

picoder90 wrote: ↑

Sun Mar 30, 2025 9:56 pm

cleverca22 wrote: ↑

Sun Mar 30, 2025 10:53 am

the proper method is to use device-tree

it gives you a list of addr+size pairs, telling you exactly which ram is available for use by the arm cores

Hmm, when I tried this using the rapberry pi 1 DTB, and looked at the memory map using the device tree dump in DTS format, this is what was in the memory section:

Code: Select all

	memory@0 {
		device_type = "memory";
		reg = <0x00 0x00>;
	};

The dtb was called bcm2708-rpi-b-plus.dtb.

thats because the firmware changes the DTB at bootup, and provides the final DTB to your kernel

this is because of variables like gpu_mem, that can change the layout, so the final answer can only be known at boot time

Ahh got it, so to use it bare metal side, you would have to write a parser for it. Cheers.