raceflight
raceflight copied to clipboard
rs2k
PR for RFBL support
@MJ666 @blckmn @kc10kevin
F3 support will be dropped in Next. I'm considering removing DFU and OPBL support. What do you guys think? F3s won't be compatible with RFBL and the new way config on the firmware will be used. Below is the document I've created while designing RFBL. It's a bit out of date. I've made a few improvements since last updating it.
RFBL document:
Proposed flash layout: 0X08000000 - 0x08004000 : RFBL Boot loader loader. Only exists to updae RFBL. 0X08004000 - 0x08008000 : RFBL proper. Does all the work 0X08008000 - 0x0800C000 : RFBL Config. Config for RFBL kept here 0X0800C000 - 0x08010000 : RFFW Config. RaceFlight config saved here. 0x08010000 - 0x08020000 : MSv2 storage. Cool features for MSv2 stored here 0x08020000 - XXXXXXXXX : RFFW. Firmware proper.
Normal boot cycle:
- STM32 boots into RFBL.
- RFBL checks boot config and increments the boot cycle number.
- If boot cycle number is too high RFBL continues into boot loader mode.
- If boot cycle number is not too high, unless config is marked for bootloader the bootloader will boot directly to the firmware.
- Firmware resets boot cycle number after a successful boot after FC is able to arm.
FW upgrade boot cycle. A. 1. FW will mark RFBL config file to boot into bootloader. 2. STM32 system restart command 3. STM32 boots into RFBL. 4. RFBL checks boot config and increments the boot cycle number. 5. RFBL continues bootloader start as the boot direction is marked for RFBL bootup.
B. (Optional) (Needs some more thought) 1. STM32 boots into RFBL. 2. RFBL checks boot config and increments the boot cycle number. 2. RFBL checks to see if certain pins are grounded (our own BL pins). 3. RFBL continues bootloader start as if those pins are grounded. 4. RFBL will look for a connection for 6 seconds. If none is received it'll restart and jump to FW.
RFBU boot cycle. 1. RFBL marks boot direction as RFBU 2. STM32 system restart command 3. STM32 boots into RFBL. 4. RFBL checks boot config and increments the boot cycle number. 5. RFBL reset firmware direction to RFBL and jumps directly to the RFBU. 6. RFBU connects via HID and listens for firmware upgrade or restart command.
Bootloader Upgrade Command Parameters:
FwInfo.size = 0; //size in bytes of the FW FwInfo.type = 0; //RFBL, RFBU, RFFW FwInfo.address = 0; //Address to place firmware. FwInfo.mode = 0; //Auto, Manu (Manual will place the FW into the location specified by address. Auto will use compiled defaults.) FwInfo.erase = 0; //All, FW, FWCF, (All only the RFBL will do) (FW will only replace the FW area) (FW + Config will erase FW area and config location for it)
RFBL Commands: RFBLC_NONE, //No command. RFBLC_REBOOT_TO_DFU, //Will reboot device into Factory DFU mode RFBLC_REBOOT_TO_RFBL, //Will reboot device into RFBL RFBLC_REBOOT_TO_APP, //Will reboot device into App RFBLC_TOGGLE_LEDS, //Will toggle all LEDs RFBLC_UPGRADE_FW, //Will start FW upgrade process. Must include upgrade parameters. RFBLC_ERASE_CFG1_FLASH, //Will erase RFBL config flash sector RFBLC_ERASE_CFG2_FLASH, //Will erase RFFW config flash sector RFBLC_ERASE_ALL_FLASH, //Will erase all flash except the RFBU and RFBL RFBLC_ERROR, //Will put the device into error mode RFBLC_LAST, //Last enumeration. Same as RFBLC_ERROR
RFBL States: RFBLS_IDLE, //RFBL is Idle and awaiting command RFBLS_REBOOT_TO_DFU, //RFBL is rebooting into DFU RFBLS_REBOOT_TO_RFBL, //RFBL is rebooting into RFBL RFBLS_REBOOT_TO_APP, //RFBL is rebooting into APP RFBLS_PREPARING_FOR_UPDATE, //RFBL is preparing for update RFBLS_LOAD_TO_BL, //RFBL is upgrading firmware from PC RFBLS_LOAD_FROM_BL, //RFBL is reading firmware to PC RFBLS_TOGGLE_LEDS, //RFBL is toggling the LEDs RFBLS_ERASE_CFG1_FLASH, //RFBL is erasing config1 flash RFBLS_ERASE_CFG2_FLASH, //RFBL is erasing config2 flash RFBLS_ERASE_ALL_FLASH, //RFBL is erasing chip flash RFBLS_ERROR, //RFBL is in error mode RFBLS_LAST, //Last enumeration. Same as RFBLS_ERROR
I'm all for removing F3 support anyway. A majority of folks will probably agree. More time can be spent on F4 improvements. Never liked OPBL. I'm still trying to get my head around RFBL, but from what you've said on the blog, it seems like the next logical step.
Awesome work on this @rs2k.
Maybe this is obvious to some, but I don't get why we would want to spend time here vs working on other more valuable things.
What opbl limitations are driving this? Is it memory layout? If so, can we just update that and spend time elsewhere?
@nathantsoi The time has already been spent. I have a working RFBL. Integrating it into RaceFlight won't take too much time. https://www.youtube.com/watch?v=Jgjt22BYVPo
The reason for doing this is to get rid of the need for DFU and OPBL. I don't like the 6 second delay OPBL has using DFU when you have several windows computers is a huge pain. RFBL can be used to make upgrades easier to do as well.
Sounds interesting, flashing looks to be very fast. What will be te impact for the configurator and the firmware itself. For us on windows we have never seen real isues with dfu flasing. We have never used an FC with an OPBL so we can not comment.
hey @rs2k what if we put the boot loader at the top of the memory, and then only execute from within the RFFW if the boot option is enabled - either via a pin, via a flash flag and reset, or both?
That way the RFFW still sits at 0X08000000
@blckmn I thought abut that, but I want to keep the BL at 0X08000000 for times when the FW is corrupt. Keeping a DFU option of the RFFW might be the best way to go. RACEFLIGHT_REVO_DFU and RACEFLIGHT_REVO_RFBL for example. I don't see a point in keeping OPBL support since RFC can just flash the OPBL back onto the FC in DFU mode if it needs to. I'm willing to trade compatibility for ease of use in this case. Thoughts?
yeah i did think about the corruption issue, but figured it would be possible for DFU to repair a bricked board worst case.
The DFU option only needs to reload the RFBL, and a stub RFFW that puts it into boot mode every power up. The stub gets replaced on first flash.
The only reason i thought that would be better is that 99% of times the board is started up it won't be for boot loading, it'll be for RFFW, and the RFFW hex can then remain as is in the make file (no need to support building to a different start address).
Only musing my thoughts...
Thanks, I still haven't decided which route to go. I think it'll be time to test the boot loader soon though.