Worlds Simplest Bootloader :: Bare Metal Programming Series 4

In this episode of the bare metal programming series, we're taking our first steps into building a fully fledged bootloader! To do this, we need to split the application in two, build some supporting scripts, learn how to use linker scripts, and understand some of the internal CPU registers for relocating the interrupt vector table at runtime.

=[ 🔗 Links 🔗 ]=

[TimDrogin]

Casting region of memory to a struct(vector table) was probably the most awesome use of c as a language I have ever seen. So clever and elegant in a way!

[weshowl]

Big help to my understanding. BTW: In a linker map, BSS stands for Block Started by Symbol. It refers to a section of an object file or executable that contains statically allocated variables that are declared but not yet assigned a value. These variables are typically initialized to zero by the operating system or the runtime environment before the program starts executing.

The BSS section helps reduce the size of the object file, as it only stores the length of the BSS segment, not the actual data. When the program is loaded into memory, the BSS segment is allocated and initialized to zero.

[stevezhou]

like your video so much. bootloader is flying everywhere, but nobody explains exactly what "bootloader" is. This is problem of software, everyone coins their own concept, then use the popular NAME to name it. like your clearness

[ivsuk]

Thank you very much. Very clear and articulate explanation. My windows toolchain with stlink debug on WSL was a bit tricky but got there in the end. Anyone struggling: multiarch-gdb symlinked to arm + usbipd.

[nhanNguyen-wofy]

10:30 flash memory
15:50 fix make file
17:10 what bootloader do
50:40 main
59:30 vector table offset register

[alexyoung]

I like how you linked two otherwise separated projects together to paint a complete picture of how they are allocated in the memory and how they work together, or at least not against each other. It's worth pointing out that some applications also jump back to the bootloader to trigger the firmware update feature. Assuming the worst scenario where main application hadn't done a good cleanup by resetting the interrupt vector offset register, it's recommended to force reset that exact register in the very beginning of the bootloader execution.

[AbidAli-mjcu]

At @46:51, the first 4 bytes represents Main stack pointer, which is end of the RAM (from where stack starts), + 0x18000U (96KB) = 0x20018000U

[フィリップフーベル]

Again, I realy like your project! Some improvement-suggestions: to really understand the content of the jump_to_main function (better name would be jump_to_app_main), it is essential that the listener understand that the linker will do all the main work for us. The address of the jump_fn which we are digging out of the addresses with the pointer joggling is correct BECAUSE the linker puts it there (will/has put it there) with the linker script of the app.

[stevekoehn]

Your thinking is so clear, your explanations so clear and logical I Get It! (I'm older and learning on my own so I need all the help I can get, ha)

[CuriousCyclist]

Thank you for taking the time to make this video. Really good educational content. 👍

[anshulmaurya]

It's been done really really nicely - Thank You

[johnhansson]

Regarding the padding of the bootloader to 32kb, couldn’t you configure that in your linker script, so that it is done for you when linking?

[MarvinPranajaya]

Great content! It has helped me learn so much about bootloaders. Just wondering why do you not set the Stack Pointer to the APP before jumping to APP. I believe we need to do so to utilize all the RAM space? I also realized the reset handler by Libopencm3 doesnt include a Stack Pointer intialisation.

[john]

Thank you very much for your tutorial. It is so kind of you, to give us this free and easy to understand introduction into bootloaders.
When I started to experiment with bootloaders, I was overwhelmed by the whole documentation of the chip. And of course it did not work, so I was thrown off, not knowing why it failed.
With this start-to-finish mini-demo it is a lot easier to get going and building from that on forward.

Would be nice if you could mention some ways of including your handmade changes of the linker script to IDEs (e.g. Eclipse). Like, where you can use the settings of the project to change the memory layout or add sections.
Maybe this helps other to include your bootloader to their current project w/o too much editing of linker files that are handled by the autogen of the IDE.

[u-ux]

Amazing content as usual. Thank you for sharing.

[kilwo]

Just wondering why you do a C++ function call in the bootloader? If you did an assembly jump (branch I think in ARM) then you could reset the vector table offset address before the jump and the main app wouldn't need to know anything about the size of the bootloader. The main app would just work as if it was the only thing in memory and you could change the bootloader size without needing to update the main app.

[gionag]

in linker, why don't use FILL to pad the bootloader ?

[dty]

I'm not a C programmer, but at 25:10, why don't you let the compiler do the pointer math for you, and use reset_vector[1] instead of adding 4 to the address?

[LaSDetta]

Really nice video! I was wondering if you could use the FILL command in the linker script to ensure that the bootloader binary is always 0x8000 bytes?

[bobweiram]

Is it possible to pad the bootloader using the assembler. You can create a data section and then include your bin .