Where to start in writing my own bootloader? | Hacker News Reader

Where to start in writing my own bootloader?

8 pointsShanedora10 comments

I would like to write my own bootloader for a arm cortex-m4 processor. Read a few articles, searched a few blogs but I'm still struggling in finding the right resources. I'm looking for a deeper dive into the instruction on how and less "here is the code".

View on HN

I'll recommend two books. I don't know if these are the "best" books on the subject, but I found them useful for some system-level experiments I did on an Odroid. They explain both the big picture and implementation details:

1) Professional Embedded ARM Development, by Langbridge [1]

This one is more about ARM instructions than about bootloaders or embedded OSes, but it does cover bootloaders in detail with case studies of some relatively unknown embedded boards, of the well-known Raspberry Pi, and of modern bootloader software like u-boot.

2) Building Embedded Systems, by Gu [2]

This book is broader than the one above, covering all kinds of embedded systems. It's the better book to understand the big picture, and understand how all the components (bootloader, OS, SoC, hardware buses, storage) interact. It does cover bootloaders but not in depth and not with case studies.

[1]: https://www.amazon.com/Professional-Embedded-Development-Jam...

[2]: https://www.amazon.com/Building-Embedded-Systems-Programmabl...

Some bootloaders can be really simple. Here is one I wrote recently for my security key product (this particular code is for an ARM M3).

https://github.com/SoloKeysSec/solo/blob/master/targets/efm3...

Like what others mention, it really depends on documentation from the vendor for the chipset you're working with. I mainly copied and pasted code from a form post by the vendor.

And of course link to the security key product :)

https://solokeys.com/

I'm not sure what you're actually looking for. It might help if you defined what you considered a "bootloader" to be. Are you trying to bring up an existing OS or app? Are you trying to initialize the processor prior to running your own code?

I'm very new to this concept of bootloaders for embedded processors so bare with me. The answer that best aligns to your question is "trying to initialize the processor prior to running to application code".

Some of the critical tasks I would like my bootloader to cover are... 1) Initialize critical parts of the processor (oscillators, clock branches, peripheral enables, etc..) 2) Initialize a few peripherals like UART to provide some useful "readable" output during this process

Some additional "would be nice" features I would like to do are... 1) Load an application from a SD card 2) Parse over the application executable for validity purposes

Let's establish one fact first: when working with the smaller processors and SoCs, there's no such thing as a generic bootloader. The final code for any bootloader will be highly specific to the part.

Your request #1 is on the mark: you want to cold-boot the chip and get the various necessary registers in place to accomplish #2, which is set up some of the peripherals to begin working.

So you have two choices:

1) Start reading the TRM and writing assembly code to do this, then read the TRM again and understand the boot sequence to figure out how and where to load the code.

or...

2) Read existing code to learn from someone else's work, because they did the exact same thing at some earlier point in time.

Then you just need to read the chip docs and initialize "everything" to a reasonable state. There's not much to it beyond that--there's no generic process for doing that.

Loading an app from an SD card is likely harder than you think: it needs to be compiled/assembled correctly, you need to define where it starts, how it's linked, etc.

"Parse over the app executable for validity" is super-broad, and could mean just about anything. If you're trying to validate compiled programs, this will be difficult. If you're trying to validate byte-code programs (or something similar) it's significantly easier (or even unnecessary).

It'd probably be helpful if you were able to define specifically what you're trying to accomplish, and why an existing system doesn't meet your needs. While writing a trivial execution environment is really easy, writing a general-purpose OS is significantly more difficult.

A couple of times I wrote bootloaders for new chips. I relied heavily on the chip vendors documentation. It was usually almost non-existent, and no more than text saying what things I had to do in what sequence. But taking that info, then looking at other bootloaders for operating systems (to see if there was environment specific things I should be considering) I was able to create boot loaders.

Was this part of the datasheet of the chip? Perhaps I've missed this section but I've never recalled the datasheet including this information. Is this usually covered in a separate application note or whitepaper?

It could be anyplace. You might try calling the vendor and asking to speak with one of their Application Engineers. Their job is to encourage chip adoption, so they will usually take such calls if you tell them you are doing a new implementation on their chip.

At the end of the day, a bootloader is just memcpy, and a jump (with a few details like setting up a stack, any serial ports etc).

You usually can have quite a bit of help by looking at the generated code from your compiler that sets up a simple 'main(...){ while(1); }' program. Often it'll be in your toolchain as a .S file or similar.

Reply on news.ycombinator.com