Hello everyone,
I recently ordered a Raspberry Pi for development purposes, though it hasn't arrived yet.
Now I want to prepare a few things so I can start as soon as it arrives.
From x86 OS development I'm used to a 512 byte sector on a disk which is the "bootloader".
On powering the device it reads this into memory and starts executing.
Now when I read RPi tutorials it says a kernel.img should be present on the SD card ( formatted as FAT32 ).
From this I conclude a RPi has built-in FAT32 support, and it boots from a file rather than a sector.
Is this true? Or has the SD card a built-in boot sector who loads the file boot sector? ( specially formatted )
I hope anyone could give me more insight in the boot process of the RPi.
Thanks in advance,
Dennis
[ RPi ] Strange boot process?
-
ScropTheOSAdventurer
- Member
- Posts: 86
- Joined: Sun Aug 25, 2013 5:47 pm
- Location: Nebraska, USA
Re: [ RPi ] Strange boot process?
Ok, I have done some research, and this is what the boot sequence looks like from a loading perspective(forgive me if I am wrong):
1. The GPU runs the first stage bootloader, which is stored in ROM.
2. The first stage reads the SD card and loads bootcode.bin(the second stage bootloader) from the root directory of the first partition, and then runs it.
3. From the same directory bootcode.bin reads start.elf.
4. start.elf then reads config.txt (configuration file), cmdline.txt, and then kernel.img (all of which are on the SD).
5. kernel.img is run.
So it looks like no special formatting is needed; you just need quite a few files on the SD for it to run.
1. The GPU runs the first stage bootloader, which is stored in ROM.
2. The first stage reads the SD card and loads bootcode.bin(the second stage bootloader) from the root directory of the first partition, and then runs it.
3. From the same directory bootcode.bin reads start.elf.
4. start.elf then reads config.txt (configuration file), cmdline.txt, and then kernel.img (all of which are on the SD).
5. kernel.img is run.
So it looks like no special formatting is needed; you just need quite a few files on the SD for it to run.
"Procrastination is the art of keeping up with yesterday."
Re: [ RPi ] Strange boot process?
That indeed is very different from a x86 bootloader.
but you say the code in bootcode.bin reads on ( it reads start.elf, start.elf reads on, etc. ).
Then I assume this bootcode.bin is a premade file given by raspberry pi ( the company ) itself?
And if I replace bootcode.bin I can define myself what it does, so only one file is needed. ( In theory )
( I won't let my own bootcode.bin read all those other files )
Still it sounds pretty strange to me there isn't a raw boot section used.
Though I believe you, because everything I read about it before come down to the same.
However I would still like to know more about this boot process in detail.
It would be nice if you could give me the sources you researched, so I can read it through myself.
I still like responses from others on this matter.
but you say the code in bootcode.bin reads on ( it reads start.elf, start.elf reads on, etc. ).
Then I assume this bootcode.bin is a premade file given by raspberry pi ( the company ) itself?
And if I replace bootcode.bin I can define myself what it does, so only one file is needed. ( In theory )
( I won't let my own bootcode.bin read all those other files )
Still it sounds pretty strange to me there isn't a raw boot section used.
Though I believe you, because everything I read about it before come down to the same.
However I would still like to know more about this boot process in detail.
It would be nice if you could give me the sources you researched, so I can read it through myself.
I still like responses from others on this matter.
Re: [ RPi ] Strange boot process?
The sequence above is correct. See the bare metal forum at raspberrypi.org for more details, e.g. http://www.raspberrypi.org/phpBB3/viewt ... 4&p=371858. You can obtain the latest firmware from https://github.com/raspberrypi/firmware ... aster/boot. Its actually a quite good scheme - the internal ROM is so simple that it will never need to be updated, and just contains code to read from the first partition of the SD, parse the FAT32 filesystem and read and execute bootcode.bin. Everything else (i.e. setting up all the on board devices and running the actual kernel) is performed by the files on the SD card. Thus no flashing is needed for firmware updates. For OS developers this has the added benefit that you can never brick the device and can just restore the original files by recopying them to the SD.
The boot process is slightly odd though, in that the VideoCore GPU actually runs the first parts of the boot sequence (including initializing the video output, but also stuff like setting up the USB and network). This is not an ARM core, and doesn't understand ARM code and the specifications for it aren't publically available. There is, however, a community effort to understand its machine code here. Note however, that they are purely trying to use it for graphics and GPGPU stuff, rather that rewriting the boot code itself (as this would also require knowledge of the individual registers to set up to initialize the video output). Therefore, I recommend you stick to writing a kernel.img file instead. This should be a flat binary linked to be loaded at 0x8000 and will need to set up a stack prior to executing C code. See http://wiki.osdev.org/Category:ARM_RaspberryPi for more details.
Regards,
John.
The boot process is slightly odd though, in that the VideoCore GPU actually runs the first parts of the boot sequence (including initializing the video output, but also stuff like setting up the USB and network). This is not an ARM core, and doesn't understand ARM code and the specifications for it aren't publically available. There is, however, a community effort to understand its machine code here. Note however, that they are purely trying to use it for graphics and GPGPU stuff, rather that rewriting the boot code itself (as this would also require knowledge of the individual registers to set up to initialize the video output). Therefore, I recommend you stick to writing a kernel.img file instead. This should be a flat binary linked to be loaded at 0x8000 and will need to set up a stack prior to executing C code. See http://wiki.osdev.org/Category:ARM_RaspberryPi for more details.
Regards,
John.