Boot process

[matosys]

Hi,
thanks! This is already very useful. Where does idbloader come from? (I presume I could just copy it off EMMC and into the SD card, but that's not really the idea...)

Same for TrustedFirmware-A: Is it this? https://github.com/ARM-software/arm-trusted-firmware

Or do I need to find a fork that supports the right SoC?

Also, if in the first step I decide not to mess with the bootloader, what files on the SD card does the preloaded bootloader try to use?

The idbloader comes from building U-Boot. I don't know for certain what it is, but I think it's the initialization code for the SoC.

The TrustedFirmware-A can come from multiple places. It appears to be the run code for the management processors. Meaning after boot, what the management processors actually do. Again I am not certain.

Anyway, their are multiple places to start with U-Boot. Eventually I'd like that Wiki page to describe how to build mainline U-Boot, with USB & NVMe support. As well as how to use Grub, with video & keyboard support, as a target. Make it work a bit like x86/x64 PCs.

@Syonyk - After they changed the Wiki to the new cluster server, I was forced to change my password on the Wiki. But not on the Forum site. So I am guessing something is broke between them. Simply report it.

idbloader is a sort-of boot loader for u-boot. it doesn't really do much else.

The SoC gets initialized by the boot rom and once it's initialized, whatever is located at block 64 starts to run by convention. that's why we dd idbloader with a seek=64 command. since we got no complex file system, it's formated in a FAT format. that limits the available addressable space which is the reason we have a bootloader for our bootloader/firmware (the u-boot binary). usb/nvme/video/keyboard/pxe/... and the u-boot shell is implemented inside the u-boot binary and the rest of the hardware gets initialized. then the kernel is loaded into memory and control over hardware is turned over to the kernel/init.