[davelnewton]

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?

[Shanedora]

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

[joezydeco]

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.

[davelnewton]

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.