> Someone asked about the Pi's bootloader situation. My understanding is that > the GPU runs first when the board is powered up. It looks for an executable > to load & run on the first (VFAT) partition on the SD card, and that this > executable is closed-source, provided by the Pi foundation (and/or Broadcom), > and does traditional boot-loader-y things, like set up memory (which is > shared between the GPU and the ARM CPU, I believe), and load a kernel. I > suppose there's no reason we couldn't then run uBoot instead of a linux > kernel, but there seems little point. There is no ROM part, so the device > must boot from the SD card.
We do something similar with a Freescale chip. We a wrote a little microcode program that is flashed into the eeprom on the processor. It's just enough the get the processor to read the bootloader (in this case u-boot) from the first partition of a microSD card. The 2nd partition contains the rootfs and kernel. A modified u-boot (or modified u-boot parameters tucked in the same partition) allows us to use a tftp/nfs dev enviroment since pulling a card to image just takes to long. Production units get a hard-coded u-boot to do sdcard boot sequence. Seems there has been some work to get u-bbot working on RPi: http://kernelnomicon.org/?p=127 https://github.com/gonzoua/u-boot-pi/tree/rpi Apologies for wandering off-topic. I've ordered an RPi this morning and should have it in a few days. _______________________________________________ LTIB home page: http://ltib.org Ltib mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/ltib
