From: theom+news@chiark.greenend.org.uk   
      
   Lawrence D'Oliveiro  wrote:   
   > On Mon, 27 Jan 2025 14:04:07 +0000, The Natural Philosopher wrote:   
   >   
   > > Yup Arm/broadcomm based Pis 'do it their way'   
   > >   
   > > It goes back to the chips inception as a set top box embedded processpor   
   >   
   > Also remember that GRUB depends on BIOS or UEFI, and the former is x86-   
   > specific -- not sure about the latter.   
      
   UEFI isn't x86 specific - Arm uses it as well.   
      
   > Basically, every vendor’s ARM chipset came up with its own way of booting.   
   > In the absence of a BIOS-style interface for querying what hardware is   
   > available, the Linux kernel is built with a “device tree” structure that   
   > hard-codes this information for your specific chipset.   
      
   Yes, although to note that there are typically several stages of booting.   
   The UEFI / u-boot / etc is often the second or third stage of booting.  They   
   come after things like the ROM first-stage bootloader then the second stage   
   bootloader loadered from flash, or similar.  Sometimes boot is handled by a   
   CPU that isn't the main one, such as a 'management' CPU or in the Pi   
   1/2/3's case the GPU.   
      
   In the classic Pi 1, the process is:   
   1st stage: ROM bootloader (enough to read SD card)   
   2nd stage: bootcode.bin on SD card (firmware for GPU)   
   3rd stage: start.elf on SD card (firmware for GPU)   
   4th stage: Linux kernel from SD card (for CPU)   
      
   In Pi 3 and later the ROM bootloader also knows enough to read USB sticks as   
   well as SD cards.  The early stage(s) also move to EEPROM on Pi 4 to make   
   them easier to update.   
      
   > There is now an equivalent spec standardized for the ARM world (adaptation   
   > of UEFI??), but I understand this is only in use on servers with AArch64,   
   > and the Raspberry Pi predates it anyway.   
      
   It's possible to run another bootloader like u-boot or UEFI as your fourth   
   stage, ie:   
      
   1st stage: ROM bootloader (GPU)   
   2nd stage: bootcode.bin on SD card (GPU)   
   3rd stage: start.elf on SD card (GPU)   
   4th stage: UEFI / u-boot on SD card (CPU)   
   5th stage: Linux kernel (CPU)   
      
   This is useful if you need more flexible booting than the regular boot   
   process provides - eg you want to fetch the kernel from an NFS share, which   
   is something not supported in the standard Pi firmware.   
      
   If the board vendor puts the firmware for stages 1-4 into EEPROM/flash, the   
   board now supports UEFI but the boot process didn't change, it just hid the   
   first four stages from you.   
      
   Theo   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)