Cortex-A appears to be way more vendor-implementation dependent. For example, I remember reading that the Raspberry Pi SoC, which uses a Cortex-A72 core, actually boots off its GPU.
Yes. DRAM initiazization, MMU, exception levels, trusted-firmware, initialization of specialized coprocessors for system power states management, more complicated storage access options (SD card/eMMC), etc. etc.
Most of those aren't Cortex-A specific, you've just listed mostly peripherals that are typically initialized in the application space (except for a secure boot).
E.g. you aren't going to go into power savings mode during boot, nor are you going to initialize peripherals (because their contexts will be lost once you jump to the application).
Initializing assymetric processors can be done in application space with a variety of tools (AMP) as well. I haven't seen a need to initialize them during bootloader1 phase, but there are lot of use cases.
Yes, I wrote one bootloader for a SoC, and read through several other bootloaders to be able to make modifications to them. I've also reverse engineered several binary only bootloaders for undocumented MCUs to be able to write sane Linux based flashing tools for them.
Kinda know what bootloader is. And, while I don't care about the naming, I know several people who would vehemently disagree with you that grub is not a bootloader. They'd say that only grub is a bootloader, and anything else running prior to that is platform firmware.
Cortex-A is not typically used in MCUs, so I don't see what you mean by "The MCU is the first thing to boot".
Yes, an important qualifier! In practice the vast majority of embedded projects out there are on cortex M, with a bit of xtensa (ESP32) and a bit of RISC-V.
For Cortex-M embedded topics, memfault's blog is simply one of the best out there. Consistently great posts even though they are written by a bunch of different authors. I go back to https://interrupt.memfault.com/blog/cortex-m-fault-debug all the time when debugging hard faults on different systems.
Even if you regularly write embedded code for Cortex-M MCUs, scroll through their list of posts and you'll find several that will teach you something new and useful.
I'm a bit jealous of the fact they have such good blog posts. I did a deep dive on a couple of different architectures and always wanted to write something so nice and useful for other people with the stuff I know.
Author here. It's surprising how hard CMSIS-DAP adapters are to find. The two options shared by codys look reasonable, but I'm working on putting together a better option.
19 comments
[ 2.9 ms ] story [ 55.6 ms ] threadE.g. you aren't going to go into power savings mode during boot, nor are you going to initialize peripherals (because their contexts will be lost once you jump to the application).
Initializing assymetric processors can be done in application space with a variety of tools (AMP) as well. I haven't seen a need to initialize them during bootloader1 phase, but there are lot of use cases.
Kinda know what bootloader is. And, while I don't care about the naming, I know several people who would vehemently disagree with you that grub is not a bootloader. They'd say that only grub is a bootloader, and anything else running prior to that is platform firmware.
Cortex-A is not typically used in MCUs, so I don't see what you mean by "The MCU is the first thing to boot".
Even if you regularly write embedded code for Cortex-M MCUs, scroll through their list of posts and you'll find several that will teach you something new and useful.
From zero to main(): How to write a bootloader from scratch - https://news.ycombinator.com/item?id=24635383 - Sept 2020 (44 comments)
Also asked the author here: https://mobile.twitter.com/kaycebasques/status/1585708384531...
- https://makerdiary.com/products/pitaya-link
- https://www.l-tek.com/web-shop/cmsis-dap-debug-probe/