PR for RFBL support

[rs2k]

No description provided.

[rs2k]

@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:

1. STM32 boots into RFBL.
2. RFBL checks boot config and increments the boot cycle number.
3. If boot cycle number is too high RFBL continues into boot loader mode.
4. If boot cycle number is not too high, unless config is marked for bootloader the bootloader will boot directly to the firmware.
5. 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

[kc10kevin]

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.

[opiswahn]

Second that!

[nathantsoi]

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?

[rs2k]

@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.

[nathantsoi]

Rad. Is the code pushed somewhere? I'd love to check it out.

[MJ666]

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.

[blckmn]

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

[rs2k]

@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?

[blckmn]

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...

[rs2k]

Thanks, I still haven't decided which route to go. I think it'll be time to test the boot loader soon though.