INTL 3:770/1 3:770/3   
   REPLYADDR theom+news@chiark.greenend.org.uk   
   REPLYTO 3:770/3.0 UUCP   
   MSGID:  b63b7bb6   
   REPLY:  746cca33   
   PID: SoupGate-Win32 v1.05   
   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-Win32 v1.05   
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)   
   SEEN-BY: 19/10 105/81 106/201 128/187 129/305 153/757 7715 154/110   
   SEEN-BY: 218/700 840 220/70 221/1 6 242 360 226/17 30 100 227/114   
   SEEN-BY: 229/110 111 114 200 206 275 300 317 400 426 428 470 550 616   
   SEEN-BY: 229/664 700 705 230/0 266/512 267/800 280/5003 291/111 292/854   
   SEEN-BY: 292/2226 8125 301/1 310/31 320/219 322/757 335/364 341/66   
   SEEN-BY: 342/200 396/45 410/9 423/81 460/58 633/280 712/848 770/1   
   SEEN-BY: 770/3 100 330 340 772/210 220 230 902/26 2320/105 5020/400   
   SEEN-BY: 5075/35   
   PATH: 770/3 1 218/840 221/6 1 292/854 229/426