Bootloader stm32 Boot0 vs Boot1

[lawrence11]

Hello.

In my application, an stm32f3 can control the pins of a bigger MCU, an F4. By reset, Boot0, and SPI4 wich is capable of accessing system memory.

How should I setup  Boot1,  whats the point of SRAM bootloader.

Why should is be better to write the boot in SRAM vs System memory?

With the system memory I can write, read, jump to, anything I order basically.

I am aiming for secure bootloader, with some sort of encryption.

I was thinking that a going boot0 I can achieve this ? Since I can write and read and jump anywhere ?

[DDunfield]

What is it exactly that you are trying to accomplish?

The Boot0/Boot1 pins control where the processor begins executing code from. The exact options vary from one STM32 type to another, but generally you can boot from:

Main memory:      This is for starting in on-board flash (most commonly used)

System memory:  On-board bootloader in ROM
  Exact functions vary with the device and bootloader revision,  you should refer to ST AN2606 for details, it lets you do things like bootstrap flash from UART, boot from I2C, SPI etc.

SRAM: This is used to run code you have previously loaded into SRAM, possible uses:
  Load code via hardware debugger, then reset & run.
  Load code via download protocol from bootloader then reset & run (you can also run directly from bootloader, but if you want it to "cold start" the code this would do it).
  Load code via application then reset to "cold start" it.

If you are writing a custom bootloader, then it will most likely reside in main flash and you would boot it using "Main memory". It would then look after launching the application, and providing whatever other services you need (secure updates etc.).

The only time you might boot otherwise would if your bootloader got corrupted and you need to reflash it (assuming the smaller MCU has this capability). What you do with Boot1 would depend on what you implemented to accomplish that, and what it means on the particular STM32 variant that you are using. For the STM's I use Boot1=1 means to run the on-board bootstrap ROM, Boot1=0 means run from SRAM. To recover the system via the bootloader you need an external source to bootstrap an image from (UART, I2C, SPI, USB etc.), To recover from SRAM you would have to have a way to place bootstrap code there first (debugger etc.) and also a way to feed the application image to it as it re-installs it.

If your design does not include the capability to recover the bootloader in the larger MCU, then just tie off Boot0 to always boot from main flash (Bootloader would have to be recovered via debug interface).

Dave

[westfw]

You can load RAM with bootloader code using relatively "easy" SWD/JTAG commands (RAM is generic, while programming flash usually involves interacting with a vendor-specific Flash controller peripheral.)  This allows you to have zero impact on your flash address space, yet implement relatively complex bootloaders for odd connections/media.
I believe that this is essentially how the PJRC Teensy3 boot process works - they have a very small microcontroller that jams a bootloader into the ARM RAM using dedicated debug pins, which is then run and boots over USB.  Since the pins are dedicated, has very "low impact" on any of the rest of the system.

[DDunfield]

You can load RAM with bootloader code using relatively "easy" SWD/JTAG commands (RAM is generic, while programming flash usually involves interacting with a vendor-specific Flash controller peripheral.)  This allows you to have zero impact on your flash address space, yet implement relatively complex bootloaders for odd connections/media.
I believe that this is essentially how the PJRC Teensy3 boot process works - they have a very small microcontroller that jams a bootloader into the ARM RAM using dedicated debug pins, which is then run and boots over USB.  Since the pins are dedicated, has very "low impact" on any of the rest of the system.

You could also write RAM via the on-board boot ROM if SWD/JTAG is beyond the capability of the bootstrapping processor - the simplest way to talk to it is via a UART (assuming you have one connected between the two MCUs).

After loading, you can simply execute by jumping to it from the boot rom, or if you need it to start cold, you could reset and boot from SRAM - but being able to do both of these would require controlling Boot1 as well as Boot0.

For just programming the main STM32 flash, that is built into the on-board boot rom, but it's not "secure". Write records are send in the clear.
FWIW programming the flash "bare metal" is quite easy on the STM32 (at least the one's I've used, I don't know exactly which variant is being discussed here).

Dave

[lawrence11]

Ok, My F4 has much

Yes the ROM code provided by ST gives me alot of power over the chip, this is what I am confused, since I dont see what I need boot1 type bootloader.

Boot1 will either be connected by a via to either VCC or GND.

Its impossible to reach it with a resistor or anything, this is a PCB that is finish and ready to order and this was the last remaining sticking point.

So now, will the via be GND or VCC, is the question.

[westfw]

Yes the ROM code provided by ST gives me alot of power over the chip, this is what I am confused, since I dont see what I need boot1 type bootloader.

Does it boot over Ethernet, say, using TFTP?
cisco Routers would (at one time) uncompress code from EPROM into RAM, then run the RAM code to download a "Secondary Bootstrap" via TFTP (which could also be compressed), run that code, which would then download the final image, potentially uncompress and relocate that, and start the code...  Because: RAM was bigger than EPROM, but not big enough to hold two copies of the uncompressed code (plus the runtime data needed to run TFTP over a dozen or so possible network media.)  (The point being that your bootload procedure can get a lot more complex than anything a hardware vendor is likely to stick in ROM.)

[lawrence11]

Interresting story west.

But what about my pin?

I think Im gonna go flip a coin.

Why should I even need RAM mode Boot1 if I can write to RAM mode with Boot0 mode and jump there and do something else...

Whats the point of having this via GND or VCC.

Seriously I am coming here with a yay or nay... Just go by your hunch and I will total it and decide.

No more info will be provided just vote.

But I will just go Boot0 since I cant have both unless... I somehow....

Wasnt aware some people flipped between both.

So if I understand correctly, the flash cant be written once I exit either Boot1 or Boot0 mode.

And Boot0 mode cant jump to application code that decrypts then write to flash because I have essentially exited the bootloader and dont have access anymore to writing to flash, either it be in application program by me, either in Flash or RAM, I cant write to flash because I'm out of Boot mode?

I think I am starting to get it, that I need to get to that pin? , or am I just confused by all your comments and I can do it all with Boot0?

I thought I could hide the "bootloader" in flash in a write protected and read protected section that has write permissions on all the other flash sections?

Or is this too vulnerable to attack? Or "brickable" and then In that unfortunate and rare/unlikely  radiation event I have to expose the bootloader to customer? Or costs memory and Thus the debate I am having now with myself and you guys.. Go VCC or To GND or to control?

I am trying to foresee and imagine cryptography as we speak, I never even studied the subject but I think I get it... Stuff gets exchanged and I wanna win this war.


BTW... I ust a f469/79. And my application has nothing to do with anything that is "safety critical".

The best of the best of the M4', this momma gots all kinds of bells and whistles that I dont even begin to understand.

[krho]

Just remember boot pins are useless, when you enable readout protection. In such case you need a bootloader in your flash.

[DDunfield]

Just remember boot pins are useless, when you enable readout protection. In such case you need a bootloader in your flash.

Only if you use protection level 2 which locks out debug interfaces, and on-board bootloader completely.

If you use protection level 1, you can still access the bootloader but access to main flash is blocked when boot to system memory (bootloader) or SRAM, there is however a "readout unprotect" command in the on-board bootloader which removes the readout protection from main flash (after erasing it first).

Dave

[dgtl]

Even if you intend to use level 2 in production, for debugging on development boards you still need to have boot pins set up sanely.
* You can ignore the boot from RAM mode, it's a specialized use case thing. You do not need it.
* If your chip has boot1 (not all smaller ones do) and you need system boot bootloader mode (it is wise to leave yourself the option to use it), be careful with boot1 pin - add a pulldown resistor and use it as output.
* In case you plan to program the chips using the bootloader, add pull-down resistor to boot0 and something to pull it high (ie jumper). Otherwise hard-wire boot0 (not a good idea, you may need boot0 for some development tasks). Sometimes the external interfaces of your device and the internal bootloader match so you can use an existing usb or serial port to program the board in the factory without the need for JTAG at the factory, you just need the boot0 jumper.
* As the boot0 does not have pull-up or pull-down, do not leave it floating, you may debug sometimes non-booting complaints for ages.
* For professional production stuff, you still need to add your own bootloader and set level2 for production devices. The internal ROM bootloader will be disabled and unused. Your bootloader is in the beginning of flash and starts first, then jumps to user progam later in flash (and re-programs VTOR to redirect ISR vector table). Your bootloader would implement encrypted and authenticated fw update, secure boot etc. You can either have just copy the new fw from another partition or have communication to download it (serial, Ethernet TFTP, USB etc).

[lawrence11]

Even if you intend to use level 2 in production, for debugging on development boards you still need to have boot pins set up sanely.
* You can ignore the boot from RAM mode, it's a specialized use case thing. You do not need it.
* If your chip has boot1 (not all smaller ones do) and you need system boot bootloader mode (it is wise to leave yourself the option to use it), be careful with boot1 pin - add a pulldown resistor and use it as output.
* In case you plan to program the chips using the bootloader, add pull-down resistor to boot0 and something to pull it high (ie jumper). Otherwise hard-wire boot0 (not a good idea, you may need boot0 for some development tasks). Sometimes the external interfaces of your device and the internal bootloader match so you can use an existing usb or serial port to program the board in the factory without the need for JTAG at the factory, you just need the boot0 jumper.
* As the boot0 does not have pull-up or pull-down, do not leave it floating, you may debug sometimes non-booting complaints for ages.
* For professional production stuff, you still need to add your own bootloader and set level2 for production devices. The internal ROM bootloader will be disabled and unused. Your bootloader is in the beginning of flash and starts first, then jumps to user progam later in flash (and re-programs VTOR to redirect ISR vector table). Your bootloader would implement encrypted and authenticated fw update, secure boot etc. You can either have just copy the new fw from another partition or have communication to download it (serial, Ethernet TFTP, USB etc).

So I should order the Pcb with boot0 as it was, connected to gpio of another chip.

and have boot1 grounded through via, since ram boot is not needed.

This is actually what my hunch was telling me.

Good that I dont have to modifiy my pcb (again) to gain access and control boot1 pin.

[dgtl]

So I should order the Pcb with boot0 as it was, connected to gpio of another chip.

Boot0 is sampled on de-assert of reset. In case the value from the other chip is stable and valid during reset of stm32 (ie it is driving the reset as well), this is fine. If you need triggering of bootloader for some re-programming tasks and the stm32 is de-asserting reset on its own, you may need resistor + open-collector buffer to be sure to have a good value at boot. Remember - this pin chooses the boot mode - if it gets sampled wrong, the stm32 boots wrongly (ie you end up in bootloader instead of running existing code).

[lawrence11]

So I should order the Pcb with boot0 as it was, connected to gpio of another chip.

Boot0 is sampled on de-assert of reset. In case the value from the other chip is stable and valid during reset of stm32 (ie it is driving the reset as well), this is fine. If you need triggering of bootloader for some re-programming tasks and the stm32 is de-asserting reset on its own, you may need resistor + open-collector buffer to be sure to have a good value at boot. Remember - this pin chooses the boot mode - if it gets sampled wrong, the stm32 boots wrongly (ie you end up in bootloader instead of running existing code).

Yes, this chip, the smaller F3 has 2 pins controlling both the reset and the boot0 ( by 2 seperate pins).

SPI4 connected to the F3, and NSS (of F4) is grounded by via, as it says in the app note, NSS must be low.

the reset pin on the F4 is connecting to a pin of  the F3 and to a pull-up.

So yes, I'll configure the F3's gpio as  open drain If I remember correctly, also the swd debugger mini cortex header has ability to reset this.

Since this is open drain I dont have to worry about bus contention accidents that cna damage my F3's pin.

I guess I did my homework well, I think I am good to go.

[dgtl]

the reset pin on the F4 is connecting to a pin of  the F3 and to a pull-up.
So yes, I'll configure the F3's gpio as  open drain If I remember correctly, also the swd debugger mini cortex header has ability to reset this.

If you have OD + pullup, the F4 will start on boot via the pull-up (when F3 has not configured its pins yet).  The default state of gpios of STM32 is usually floating (with some exceptions). At the same time the boot0 will be sampled at whatever state. The F4 will start in either mode (bootloader or user code) and then the F3 has to reset and re-start it. This behaviour may cause some issues. At least add a pull-up or pull-down to boot0, so that the F4 starts always at a known state.

[lawrence11]

I am using this.

https://electronics.stackexchange.com/questions/156806/arm-cortex-reset-button-and-debug-interface-swd

and with NRST like this, but with no capacitor on reset.

https://southlife.tistory.com/107

should be good to go.

[lawrence11]

So lets say Im gonna control both boot0 and boot1, I found a way.

Since I dont really know my requirements yet I guess the safe bet is getting both, and modify later on v2.0 of the pcb.

You guys recommend pull up on both? What is the safe way to go before my f3 actually decides what level it will be for booto, boot1, once its woken up properly.

Whats the dangerous situation here?