tarkshya
Posts: 47
Joined: Tue Nov 03, 2015 7:28 pm

fixup.dat use & start.elf memory layout

Thu Feb 02, 2017 4:03 am

Hello friends,


There are these two firmware files fixup.dat and start.elf. What exactly does the fixup.dat file do? Some say it relocates the start.elf file, to where and from where? Apart from that (other answers state), gpu+arm memory split is governed by it, like if you don't have this file, MailBox won't report the arm memory properly, why is it so?

Regarding start.elf, i've read (here in the forums) that GPU executes this file, if so where in memory is it loaded, GPU memory or ARM memory? if Arm memory, what is the memory layout (start address, end address), what happens when a kernel overwrites this startup.elf file ? common sense tells that this should go inside the GPU mem, and we talk to it using mailboxes.

Can somebody clarify these things?


Thanks
Tarkshya

rst
Posts: 554
Joined: Sat Apr 20, 2013 6:42 pm
Location: Germany

Re: fixup.dat use & start.elf memory layout

Sun Feb 05, 2017 2:48 pm

There is only one physical SDRAM which is shared between the VideoCore (VC aka GPU) and the ARM processor. The ARM uses the lower part of it while the VC uses the upper part. The memory split between the two can be set using the gpu_mem option in the config.txt file. By default the upper 64 MByte are used by the VC.

The fixup.dat file should always be on the boot partition of SD card. The property mailbox call "Get ARM memory" (0x10005) reports the full available ARM memory (lower part) then. You should only use this reported memory range for your bare metal program. It is ensured then, that the code loaded from start.elf is not overwritten. Without fixup.dat your program may also run successfully, but a lot of memory is wasted.

tarkshya
Posts: 47
Joined: Tue Nov 03, 2015 7:28 pm

Re: fixup.dat use & start.elf memory layout

Mon Feb 06, 2017 7:26 pm

Hi Rst,


Its understood that fixup.dat causes the memory to be reported correctly & allows proper access, but in my experiments, i have been able to access the higher parts of the memory (beyond 256 mb) successfully without using the fixup.dat. Then again there is only one fixup.dat (even the _x & _cd variants) file which is used in different models. So surely the firmware knows which board is which and the amount of memory that each board has (viz. b, b+, a, a+, pi2 b, pi3 b, zero etc), why then have a separate fixup.dat file, can they not put that 6-7kb .dat file logic inside the firmware ?

I am not sure, but can the firmware not read the memory controller registers to get the RAM info etc?

If its for relocation, what sort of relocation is done ? (is it like confidential info?)


Also what about the start.elf file, does it get loaded into VC memory & executed there itself or into main memory and then moved to VC memory with the help of fixup.dat ?

rst
Posts: 554
Joined: Sat Apr 20, 2013 6:42 pm
Location: Germany

Re: fixup.dat use & start.elf memory layout

Tue Feb 07, 2017 10:54 am

Hi Tarkshya,
Then again there is only one fixup.dat (even the _x & _cd variants) file which is used in different models.
That is not true. There is a different fixup(*).dat file for each variant:

https://github.com/raspberrypi/firmware ... aster/boot
So surely the firmware knows which board is which and the amount of memory that each board has (viz. b, b+, a, a+, pi2 b, pi3 b, zero etc)
Yes.
If its for relocation, what sort of relocation is done ? (is it like confidential info?)
Perhaps not confidential but never been published.

I will not make guesses for your other questions, because this has already been done by others. But I think with the available info it is possible to write bare metal programs for the ARM. The message is: use fixup.dat and the property mailbox call to get the use-able memory range.

tarkshya
Posts: 47
Joined: Tue Nov 03, 2015 7:28 pm

Re: fixup.dat use & start.elf memory layout

Tue Feb 07, 2017 10:11 pm

thanks @rst

Return to “Bare metal, Assembly language”