4 ms·

A fun thing to do is write a bootloader for Raspberry Pi. It doesn't have some of the cruft of x86 while still being a real bootloader.

AlyssaRowan 12y ago
But the VideoCore IV is kind of a weird vector processor, there's still a lot of official documentation we don't have, there are those ring buffers, you have to wake the— Oh, you meant the ARM? Oh, my, no, the Pi doesn't boot from that. The ROM loader starts the SDCard and loads BOOTCODE.BIN to the VC4 with cache-in-RAM mode; that's its equivalent of the bootblock. The ARMv6 isn't even turned on until the next chain later (used to be two, from memory?). So, you know, if you fancy a much more fun, more advanced, challenge, it's right there waiting for you, under the crust. Have fun. Let me know if you find a diagonal vector addressing mode or a good way of shuffling words! <grin> (PS: There is actually someone at Broadcom working on open-source firmware for the Raspberry Pi, or was last I checked. They're going to have to rewrite it: the ThreadX RTOS they used is commercial. But he has firmware documentation, at least. You have… some of it.)
exDM69 12y ago
A problem with all ARM system on chips is that they don't have any kind of standard like the PC is for x86. There's some work going on on that field but at the moment, each ARM SoC has their own conventions for booting. It is typical that there is a smaller ARM bootstrap core on the SoC that does the early boot process and kicks up the actual (bigger) ARM core(s) and then hands over control to a bootloader (like u-boot) or boots the OS using a device-specific bootstrap code. In other words: it would not be fun to do this using a RasPi (depending on your definition of "fun" of course). You would be spending lots of time with scarce documentation, dealing with practically no debugging aids and the only way to know if your code is working is whether a LED lights up and no way to debug failures. If you had a development board, perhaps you'd have JTAG or other debugging means available but I'm not sure if you can find this on a RasPi. You'd end up with very little transferable knowledge from this project. Of course, working with scarce documentation in a harsh early boot environment is a valuable skill in itself, but not the kind of stuff I'd voluntarily get into. This stuff is hard enough to do on a well documented, widely available platform like the x86 PC.
- sigjuice 12y ago
  The ARM core on the Raspberry Pi is accessible via JTAG. It requires a board with an FT4232H or FT2232H chip. See https://github.com/dwelch67/raspberrypi/tree/master/armjtag https://github.com/dwelch67/raspberrypi/tree/master/armjtag for details.
  - exDM69 12y ago
    Ok, nice to know that it has a JTAG even on the production device. However, if that plugs into the "big" ARM core, that's of no use with the early boot process (which uses the VideoCore, according to the post below).

AlyssaRowan 12y ago

But the VideoCore IV is kind of a weird vector processor, there's still a lot of official documentation we don't have, there are those ring buffers, you have to wake the— Oh, you meant the ARM? Oh, my, no, the Pi doesn't boot from that. The ROM loader starts the SDCard and loads BOOTCODE.BIN to the VC4 with cache-in-RAM mode; that's its equivalent of the bootblock. The ARMv6 isn't even turned on until the next chain later (used to be two, from memory?). So, you know, if you fancy a much more fun, more advanced, challenge, it's right there waiting for you, under the crust. Have fun. Let me know if you find a diagonal vector addressing mode or a good way of shuffling words! <grin> (PS: There is actually someone at Broadcom working on open-source firmware for the Raspberry Pi, or was last I checked. They're going to have to rewrite it: the ThreadX RTOS they used is commercial. But he has firmware documentation, at least. You have… some of it.)

exDM69 12y ago

A problem with all ARM system on chips is that they don't have any kind of standard like the PC is for x86. There's some work going on on that field but at the moment, each ARM SoC has their own conventions for booting. It is typical that there is a smaller ARM bootstrap core on the SoC that does the early boot process and kicks up the actual (bigger) ARM core(s) and then hands over control to a bootloader (like u-boot) or boots the OS using a device-specific bootstrap code. In other words: it would not be fun to do this using a RasPi (depending on your definition of "fun" of course). You would be spending lots of time with scarce documentation, dealing with practically no debugging aids and the only way to know if your code is working is whether a LED lights up and no way to debug failures. If you had a development board, perhaps you'd have JTAG or other debugging means available but I'm not sure if you can find this on a RasPi. You'd end up with very little transferable knowledge from this project. Of course, working with scarce documentation in a harsh early boot environment is a valuable skill in itself, but not the kind of stuff I'd voluntarily get into. This stuff is hard enough to do on a well documented, widely available platform like the x86 PC.

sigjuice 12y ago
The ARM core on the Raspberry Pi is accessible via JTAG. It requires a board with an FT4232H or FT2232H chip. See https://github.com/dwelch67/raspberrypi/tree/master/armjtag https://github.com/dwelch67/raspberrypi/tree/master/armjtag for details.
- exDM69 12y ago
  Ok, nice to know that it has a JTAG even on the production device. However, if that plugs into the "big" ARM core, that's of no use with the early boot process (which uses the VideoCore, according to the post below).