Uploading to the bitbox, part II (bootloaders)

Bitbox has now a 2-stage 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.


Check this two-stage bootloader in the github repository

 

First stage

The 1st stage bootloader is very simple, and shall very rarely change. It just loads a second stage bootloader from microSD to RAM and run it if the button is pressed at reset, or runs the pogram loaded at main flash if not pressed.

It is located in the first sector of flash (16KB). 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.

Second stage

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
• VGA textmode usage similar to PC mode 11h b&w BIOS mode (80x30 characters lines w/ DOS 437 font) to write simple UI
• Display list of files from µSD
• Using USB gamepad to select file, displaying information (todo)
• Flash data from µSD  file to flash while giving back information to the use
• Boot from Flash is not handled by this bootloader, as the first bootloader handles this.
• 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)
• Ansi Art display :) Nice 1ntr0z background music & 1337 GFX Loaders

Memories, memories

Here is a list of which memory is involved at each stage of the bootloading process.