-
Notifications
You must be signed in to change notification settings - Fork 13
Bootloaders
bitbox has a 2 step bootloader : here is how it works.
Game programmers shall not worry about this since it's automatically taken care of by standard building scripts.
The principle is the following : a small first bootloader loads a second, more featureful bootloader to RAM and runs it. The second bootloader loads a program and writes it to flash.
The 1st stage bootloader is very simple, and shall very rarely change. It just loads a second stage bootloader from microSD to RAM and runs it if the user button is pressed at reset, or runs the program loaded in main flash if not pressed.
It is located in the first sector of flash (16KB) at 0x800000. Its only task is to check whether there is a second stage bootloader on the uSD card, load it to RAM and run it from RAM, and then report any error (cannot mount microSD, cannot find second stage bootloader) using the user LED. Use DFU, SWD or any other means to (re)program the bootloader, as explained in the preceding post, but that shall not happen often ; the 1st stage bootloader ought to be quite stable and limited in features.
The second stage bootloader is thus located in RAM. This is nice because we can then have a much larger, featureful bootloader (and can simply update it by dropping a new program to the card). Being located in RAM also allows the program to run while the flash data is being erased or written by example. If running from Flash, it would completely stop the execution, letting NO feedback to the user be available since the the CPU couldn't fetch the instructions from the busy flash.
The fact that it is stored in microSD is not an issue since the microSD is the reason why there is a bootloader ! Also, it is located on the microSD, so it can be simply updated and changed, which is a good thing to let the user update its bootloader without bricking its bitbox.
Being more featureful, it can handle USB input devices, display graphics to select the program to load and give feed back.
Current available features :
- Executing bootloader from RAM
- using textmode lib to write simple UI
- Display list of files from µSD
- Using USB gamepad or user button to select file, displaying information (size, logo)
- Flash data from µSD file to flash while giving back information to the use
- Usage of standard bitbox kernel to ease development and factor improvements of drivers & features
More or less serious, additional potential features for the second stage bootloader :
- Use USB keyboard or mouse to select (to finalize)
- Adding USB Mass storage driver to flash from USB key
- have an interpreter in the second stage bootloader to run user scripts & programs directly from µSD / RAM (keep bootloader under 64k to still have 128k for script)
- Color Ansi Art display :) Nice 1ntr0z background music & 1337 GFX Loaders
Here is a list of which memory is involved at each stage of the bootloading process.
| description | address | factory bootloader | 1st bootloader | 2nd boot | game in flash |
|---|---|---|---|---|---|
| internal romboot loader | 0x1FFF_0000 | exec bootloader code | |||
| sram1 (16k) | 0x2001_C000 | 1st boot data (bss) | 2nd boot bss | game data | |
| sram2 (112k) | 0x2000_0000 | write 2nd boot code | code (exec) | game data | |
| ccm ram | 0x1000_0000 | 2nd boot data | game data | ||
| flash sector 0 (16k) | 0x0800_0000 | write 1st bootloader | code (exec) | ||
| flash sector 1..N (16k, 64k) | 0x0800_4000 | write game code | exec game code | ||
| action | uploads code from DFU USBto flash | loads second bootloader from sd or jumps to flash | runs bootloader from RAM | normal game |