I'm already more than capable of making a system image, the problem is that it's surprisingly difficult to find actual informations about booting SBCs boot process.
Say:
MBR boot is recognized by bios based on a magic number in a certain position in the first disk sector; back in the days writing a bootloader was included in "write your on OS" howto, including the exact values, assembler tricks needed to pull them of, and hello-world type example in C.
BIOS starts executing code from the beginning of the device, so that's where bootloader's code needs to be flashed directly, without any filesystem.
Bootloader must understand the root filesystem enough to find the kernel by filename, and kernel's image structure enough to hand over execution without any additional user input, so we only need to ensure the bootloader of choice is compatible with the root filesystem of choice, and basically all popular FSs are supported by all popular bootloaders, so it just works.
EFI boot looks for a GPT partition of type ef00, which must be formatted with FAT, and the bootloader or efi-compatible kernel goes there as a file; linux kernel image can be made efi-compatible by setting a few options in at build time, and you can figure out the rest based on prior knowledge of MBR boot.
For more context:
A long time ago I've built a Gentoo image for a Banana Pi, and although I succeeded by just following some manual, I still have no idea what the hell was I doing. I remember there was a need to set an entry point, there was something about a a boot script, device tree for the particular board (and basically all linux for arm images on the internet come with tones of device trees for compatibility with different devices, so how does it know which one to load?) and so on.
It has never been explained what the entry point is and how do I find it or what the boot script is or does, or how to make my own, and if I'm not supposed to touch it, why isn't it just a static part of the bootloader image in the first place
So, what do ARM boards expect from disk images they use? What makes it bootable, what the important parts, and how do I get the information required to bridge gaps between all the pieces until kernel is loaded an running? I'm particularly interested in rpi4b right now, but this question is not limited to just a single model, since there clearly are a lot of similarities between lines from different manufacturers.
What makes rpi4 image bootable?
Message
- NeddySeagoon
- Administrator
- Posts: 56107
- Joined: Sat Jul 05, 2003 9:37 am
- Location: 56N 3W
szatox,
arm SBCs are all different, you need to ask about the SBC of interest.
the Pi4 in you topic title starts by holding the arm CPU reset and runs som fixed (fused in) code on the GPU.
This code reads and executes the SPI EEPROM.
This loads start and fixup and reads config.txt.
All this loads the kernel, the dtb and optionallal, the initrd.
Only when the arm code is loaded into RAM is the CPU released from resed.
Other SBCs do sometthing different.
The kernel above can be EFI, u-boot, or anything else that brings up the system.
The above is not even universal among Raspperry Pis. Before the Pi 4, the GPU loaded bootcode.bin as t_ere was no SPI EEPROM.
-- edit --
The Pi GPU startup code can detect what sort of Pi is executing it and automatically load the right the start. fixup, kernel and dtb, so its possible to make a boot on any Pi SD card image.
arm SBCs are all different, you need to ask about the SBC of interest.
the Pi4 in you topic title starts by holding the arm CPU reset and runs som fixed (fused in) code on the GPU.
This code reads and executes the SPI EEPROM.
This loads start and fixup and reads config.txt.
All this loads the kernel, the dtb and optionallal, the initrd.
Only when the arm code is loaded into RAM is the CPU released from resed.
Other SBCs do sometthing different.
The kernel above can be EFI, u-boot, or anything else that brings up the system.
The above is not even universal among Raspperry Pis. Before the Pi 4, the GPU loaded bootcode.bin as t_ere was no SPI EEPROM.
-- edit --
The Pi GPU startup code can detect what sort of Pi is executing it and automatically load the right the start. fixup, kernel and dtb, so its possible to make a boot on any Pi SD card image.
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
szatox,
beside what Neddy already said, modern ARM board usually require "Trusted Boot", one reference specification "Arm Trusted Board Boot Requirements)". You will find many reference to word "BL1", "BL2", "BL3" they are roughly match X86_64 ring concept.
Just for fun,
If you ever think want to have a uniform boot sequence for all devices at hand, you can try https://github.com/pftf/RPi4[b][/b], this will make your RPI4 boot sequence like most PC today and within the Linux kernel you can use efibootmgr to manage boot entries. (I don't remember all the detail but this implementation have a limit of number of entries. And it limit how much kernel can see total memory)
P.S. device tree roughly equal to ACPI, when SBC capable use EFI they usually will not use device tree but use ACPI.
[Administrator edit: Excluded spurious comma from URL. -Hu]
beside what Neddy already said, modern ARM board usually require "Trusted Boot", one reference specification "Arm Trusted Board Boot Requirements)". You will find many reference to word "BL1", "BL2", "BL3" they are roughly match X86_64 ring concept.
Just for fun,
If you ever think want to have a uniform boot sequence for all devices at hand, you can try https://github.com/pftf/RPi4[b][/b], this will make your RPI4 boot sequence like most PC today and within the Linux kernel you can use efibootmgr to manage boot entries. (I don't remember all the detail but this implementation have a limit of number of entries. And it limit how much kernel can see total memory)
P.S. device tree roughly equal to ACPI, when SBC capable use EFI they usually will not use device tree but use ACPI.
[Administrator edit: Excluded spurious comma from URL. -Hu]
Well, I do know that rpi4 uses GPU for hardware initialization, but it doesn't help me know how to prepare disk so it's recognized and can be booted from.
I'm specifically looking for detailed information about the things that go on the removable memory. Basically everyone talks about uboot, like it was the only bootloader in existence, but following the step-by-step guides that don't explain anything only guarantees I'm going to need those guides every single time I touch it. I want to know enough about its boot process to let me throw those guides out, or pick a different line of devices and still succeed.
Trusted boot on arm is a first for me. Is it true for pocket-size SBCs, or are you talking about server boards and so on?
When I bought my rpis they already came capable of booting from sd-card and from usb memory, I don't think I'll ever have enough of a reason to flash a new firmware into them. I can physically change the boot device in a matter of seconds, and it doesn't even require me to have a keyboard around.
I'm specifically looking for detailed information about the things that go on the removable memory. Basically everyone talks about uboot, like it was the only bootloader in existence, but following the step-by-step guides that don't explain anything only guarantees I'm going to need those guides every single time I touch it. I want to know enough about its boot process to let me throw those guides out, or pick a different line of devices and still succeed.
Trusted boot on arm is a first for me. Is it true for pocket-size SBCs, or are you talking about server boards and so on?
When I bought my rpis they already came capable of booting from sd-card and from usb memory, I don't think I'll ever have enough of a reason to flash a new firmware into them. I can physically change the boot device in a matter of seconds, and it doesn't even require me to have a keyboard around.
Do you want to know RPI specific? or ARM in general?szatox wrote:Well, I do know that rpi4 uses GPU for hardware initialization, but it doesn't help me know how to prepare disk so it's recognized and can be booted from.
I'm specifically looking for detailed information about the things that go on the removable memory. Basically everyone talks about uboot, like it was the only bootloader in existence, but following the step-by-step guides that don't explain anything only guarantees I'm going to need those guides every single time I touch it. I want to know enough about its boot process to let me throw those guides out, or pick a different line of devices and still succeed.
Trusted boot on arm is a first for me. Is it true for pocket-size SBCs, or are you talking about server boards and so on?
When I bought my rpis they already came capable of booting from sd-card and from usb memory, I don't think I'll ever have enough of a reason to flash a new firmware into them. I can physically change the boot device in a matter of seconds, and it doesn't even require me to have a keyboard around.
what is "removable memory" reference here?things that go on the removable memory
the "Trusted boot" for SBC is not always necessary but many SBC were development board so they usually have it. It usually is always on for servers.
- NeddySeagoon
- Administrator
- Posts: 56107
- Joined: Sat Jul 05, 2003 9:37 am
- Location: 56N 3W
szatox,
The Pi4 and Pi5 can boot from GPT. The others need an MSDOS disk label.
Some need the bootable flag set too.
The first partition must be VFAT
It needs to contain at least one of each of the following groups.to suit your Pi
cd means cut down. This will be used if you squeeze the GPU RAM so some features cannot work.
db means debug.
The fixup and start files are matching pairs.
Pi3 and older, with no EEPROM, need bootcode.bin
You need a kernel, pick one for your board They are all for different Pi versions.
Choose either /boot/kernel7l.img /boot/kernel8.img for a Pi4, the former is a 32 bit kernel, the latter is 64 bit.
A /boot/config.txt is good but only required on the Pi5 and may not be empty.
If you use the default names for everything, the automatics will find it, so before the Pi5, this file can be missing.
/boot/cmdline.txt is required unless what is in the kernel is correct.
If you provide your own kernel, initrd or dtb with non default names, you must give them in /boot/config.txt
e.g.
The dtbs and /boot/overlays are built with the kernel.
The Pi4 and Pi5 can boot from GPT. The others need an MSDOS disk label.
Some need the bootable flag set too.
The first partition must be VFAT
It needs to contain at least one of each of the following groups.
Code: Select all
/boot/bcm2708-rpi-b-plus.dtb /boot/bcm2710-rpi-3-b-plus.dtb /boot/bcm2711-rpi-cm4.dtb /boot/bcm2712d0-rpi-5-b.dtb
/boot/bcm2708-rpi-b-rev1.dtb /boot/bcm2710-rpi-3-b.dtb /boot/bcm2711-rpi-cm4s.dtb /boot/bcm2837-rpi-3-a-plus.dtb
/boot/bcm2708-rpi-b.dtb /boot/bcm2710-rpi-cm0.dtb /boot/bcm2712-d-rpi-5-b.dtb /boot/bcm2837-rpi-3-b-plus.dtb
/boot/bcm2708-rpi-cm.dtb /boot/bcm2710-rpi-cm3.dtb /boot/bcm2712-rpi-5-b.dtb /boot/bcm2837-rpi-3-b.dtb
/boot/bcm2708-rpi-zero-w.dtb /boot/bcm2710-rpi-zero-2-w.dtb /boot/bcm2712-rpi-500.dtb /boot/bcm2837-rpi-cm3-io3.dtb
/boot/bcm2708-rpi-zero.dtb /boot/bcm2710-rpi-zero-2.dtb /boot/bcm2712-rpi-cm5-cm4io.dtb /boot/bcm2837-rpi-zero-2-w.dtb
/boot/bcm2709-rpi-2-b.dtb /boot/bcm2711-rpi-4-b.dtb /boot/bcm2712-rpi-cm5-cm5io.dtb
/boot/bcm2709-rpi-cm2.dtb /boot/bcm2711-rpi-400.dtb /boot/bcm2712-rpi-cm5l-cm4io.dtb
/boot/bcm2710-rpi-2-b.dtb /boot/bcm2711-rpi-cm4-io.dtb /boot/bcm2712-rpi-cm5l-cm5io.dtbCode: Select all
/boot/fixup.dat /boot/fixup4cd.dat /boot/fixup4x.dat /boot/fixup_db.dat
/boot/fixup4.dat /boot/fixup4db.dat /boot/fixup_cd.dat /boot/fixup_x.datdb means debug.
The fixup and start files are matching pairs.
Code: Select all
/boot/start.elf /boot/start4cd.elf /boot/start4x.elf /boot/start_db.elf
/boot/start4.elf /boot/start4db.elf /boot/start_cd.elf /boot/start_x.elfYou need a kernel, pick one for your board
Code: Select all
/boot/kernel.img /boot/kernel7.img /boot/kernel7l.img /boot/kernel8.img /boot/kernel_2712.imgChoose either /boot/kernel7l.img /boot/kernel8.img for a Pi4, the former is a 32 bit kernel, the latter is 64 bit.
A /boot/config.txt is good but only required on the Pi5 and may not be empty.
If you use the default names for everything, the automatics will find it, so before the Pi5, this file can be missing.
/boot/cmdline.txt is required unless what is in the kernel is correct.
If you provide your own kernel, initrd or dtb with non default names, you must give them in /boot/config.txt
e.g.
Code: Select all
...
kernel 6.12.32-v8-16k+
initramfs initramfs_1.cpio followkernel
device_tree=bcm2712-rpi-cm5-cm5io.dtb_6.12.32-v8-16k+
...Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Thanks, that's some good info right there.
[x] kernel
[x] initramfs
[x] dtb
[x] config.txt
What are those fixup and start files, and where do they come from? It's been a damn long time since I made that image for my banana, but I'm pretty sure they weren't a thing yet.
7 and 8 in kernel file name refer their target arm architecture version, don't they? Do you happen to know what do 4, x, and _x in the other files' names stand for?
For boards without EEPROM, where does this bootcode.bin come from, where does it go, and what are its key features? Funny, I actually see it as a file in raspbian's /boot partition, but if it's some early stage boot code, I doubt a board that actually needs it would even find it on a filesystem. And I kinda wanted to revive that ancient bpi too.
Any idea how does bootloader know which dtb to load in the absense of config.txt? Said raspbian for example came with dtbs for 22 boards. Is there some standard for hardware discovery which lets boards introduce themselves to loader?
Since you mentioned rpi 4 and 5 understand GPT, does using one over the other require (or allow) for any changes in the disk setup? Is there any reason to chose either of them (other than redundancy in GPT and compatibility with other boards for MBR)? Like using EFI on x86, which requires GPT?
[x] kernel
[x] initramfs
[x] dtb
[x] config.txt
What are those fixup and start files, and where do they come from? It's been a damn long time since I made that image for my banana, but I'm pretty sure they weren't a thing yet.
7 and 8 in kernel file name refer their target arm architecture version, don't they? Do you happen to know what do 4, x, and _x in the other files' names stand for?
For boards without EEPROM, where does this bootcode.bin come from, where does it go, and what are its key features? Funny, I actually see it as a file in raspbian's /boot partition, but if it's some early stage boot code, I doubt a board that actually needs it would even find it on a filesystem. And I kinda wanted to revive that ancient bpi too.
Any idea how does bootloader know which dtb to load in the absense of config.txt? Said raspbian for example came with dtbs for 22 boards. Is there some standard for hardware discovery which lets boards introduce themselves to loader?
Since you mentioned rpi 4 and 5 understand GPT, does using one over the other require (or allow) for any changes in the disk setup? Is there any reason to chose either of them (other than redundancy in GPT and compatibility with other boards for MBR)? Like using EFI on x86, which requires GPT?
- NeddySeagoon
- Administrator
- Posts: 56107
- Joined: Sat Jul 05, 2003 9:37 am
- Location: 56N 3W
szatox,
In Gentoo,They are raspberry pi specific. Other fruit pis will do their own thing.
All the Pi kernels are there too.
The 32 bit kernels are
kernel.img is for armv6 based Pis
kernel7.img is for armv7 based pi without PAE
kernel7l.img adds PAE support.
kernel8.img is a 64 bit kernel for the Pi3 and newer. If you are cheeky, the Pi2 rev 1.2 too.
kernel8_rt.img ??
kernel_2712.img is optimised for the Pi5
See this Hardware table Again its all Raspberry Pi specfic.
Other vendors will have their own downstream kernels.
The sources for bootcode.bin are not open.
Understanding GPT allows booting for a volume bigger than 2TiB without throwing some of it away.
That's a thing for USB and NVMe already. microSD cards were not far away last time I looked. (2TB without the i)
If you want EFI on a Raspberry Pi, its experimental but it is reported to load grub.
The GPU loads EFI, in place of the kernel.
EFI loads Grub.
Grub does its usual thing and loads the kernel/initrd.
Again, its all Raspberry Pi specific.
They come from raspberrypi firmware/. Look in /boot.="szatox"What are those fixup and start files, and where do they come from? It's been a damn long time since I made that image for my banana, but I'm pretty sure they weren't a thing yet.
In Gentoo,
Code: Select all
emerge raspberrypi-firmwareAll the Pi kernels are there too.
The 32 bit kernels are
kernel.img is for armv6 based Pis
kernel7.img is for armv7 based pi without PAE
kernel7l.img adds PAE support.
kernel8.img is a 64 bit kernel for the Pi3 and newer. If you are cheeky, the Pi2 rev 1.2 too.
kernel8_rt.img ??
kernel_2712.img is optimised for the Pi5
See this Hardware table Again its all Raspberry Pi specfic.
Other vendors will have their own downstream kernels.
See the github repo above. Looi in /boot again.szatox wrote:For boards without EEPROM, where does this bootcode.bin come from, where does it go, and what are its key features?
The sources for bootcode.bin are not open.
? Banana Pi? All this is irrelevant to you.bpi
I suspect that there are lots of standards. One for every vendor and a few left over.szatox wrote:Is there some standard for hardware discovery which lets boards introduce themselves to loader?
Understanding GPT allows booting for a volume bigger than 2TiB without throwing some of it away.
That's a thing for USB and NVMe already. microSD cards were not far away last time I looked. (2TB without the i)
If you want EFI on a Raspberry Pi, its experimental but it is reported to load grub.
The GPU loads EFI, in place of the kernel.
EFI loads Grub.
Grub does its usual thing and loads the kernel/initrd.
Again, its all Raspberry Pi specific.
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Huh, I didn't know rpi3 can even run 64 bit code.
Anyway, do rpis understand FAT and should just_work™ if I dump bootloader and kernel files there, or is there some additional step necessary to prepare the disk?
Like e.g. flashing the loader with filesystem support into the "empty" space in front of the first partition? I've been testing some ready-made systems for rpi, and it's a bit of hit and miss. E.g. Raspbian distributed as a disk image worked, while Arch distributed as a tarball made a fancy paperweight.
I'd rather know how to initialize the disk before I spend time making the system from scratch. Building kernel, I'll probably just use raspberrypi-sources again. The one I patched and implanted into raspbian works fine, but that whole system is getting old, and it's about time to make the mistake of moving it to Gentoo.
We can leave the banana for another day
I'm not really in a hurry with it, though it has a full blown SATA port capable of running a 3.5" HDD and I'm thinking of turning it into a home fileserver.
I can pass on EFI too, at least for now. The stock firmware has been doing its job well enough.
Anyway, do rpis understand FAT and should just_work™ if I dump bootloader and kernel files there, or is there some additional step necessary to prepare the disk?
Like e.g. flashing the loader with filesystem support into the "empty" space in front of the first partition? I've been testing some ready-made systems for rpi, and it's a bit of hit and miss. E.g. Raspbian distributed as a disk image worked, while Arch distributed as a tarball made a fancy paperweight.
I'd rather know how to initialize the disk before I spend time making the system from scratch. Building kernel, I'll probably just use raspberrypi-sources again. The one I patched and implanted into raspbian works fine, but that whole system is getting old, and it's about time to make the mistake of moving it to Gentoo.
We can leave the banana for another day
I'm not really in a hurry with it, though it has a full blown SATA port capable of running a 3.5" HDD and I'm thinking of turning it into a home fileserver.I can pass on EFI too, at least for now. The stock firmware has been doing its job well enough.
szatox,
understand you want to know more about rpi boot, so below is a example of rpi4 boot with EFI and Grub. you can ignore where it said "Failed to open command line file 'cmdline.txt'" that is because I am using EFI therefor I don't want any kernel command interfering.
understand you want to know more about rpi boot, so below is a example of rpi4 boot with EFI and Grub. you can ignore where it said "Failed to open command line file 'cmdline.txt'" that is because I am using EFI therefor I don't want any kernel command interfering.
Code: Select all
8.56 [sdcard] pieeprom.upd not found
8.56 [sdcard] recover4.elf not found
8.57 [sdcard] recovery.elf not found
8.50 Read start4.elf bytes 2263968 hnd 0x4b09
8.55 Read fixup4.dat bytes 5456 hnd 0x481f
8.57 0x00c03112 0x00000000 0x00001fff
8.60 MEM GPU: 76 ARM: 948 TOTAL: 1024
8.50 Starting start4.elf @ 0xfec00200 partition 1
8.90 XHCI-STOP
8.90 xHC0 ver: 256 HCS: 05000420 fc000031 00e70004 HCC: 002841eb
8.91 USBSTS 18
8.91 PCI0 reset
9.00 +
MESS:00:00:09.106724:0: arasan: arasan_emmc_open
MESS:00:00:09.108385:0: arasan: arasan_emmc_set_clock C0: 0x00800000 C1: 0x000e0047 emmc: 200000000 actual: 390625 div: 0x00000100 target: 400000 min: 400000 max: 400000 delay: 5
MESS:00:00:09.228626:0: arasan: arasan_emmc_set_clock C0: 0x00800000 C1: 0x000e0047 emmc: 200000000 actual: 390625 div: 0x00000100 target: 400000 min: 400000 max: 400000 delay: 5
MESS:00:00:09.241498:0: arasan: arasan_emmc_set_clock C0: 0x00800f00 C1: 0x000e0047 emmc: 200000000 actual: 390625 div: 0x00000100 target: 400000 min: 390000 max: 400000 delay: 5
MESS:00:00:09.288509:0: boot-part: 1 fs-type: 0
MESS:00:00:09.289921:0: boot-part: 1 fs-type: 3
MESS:00:00:09.294306:0: arasan: arasan_emmc_set_clock C0: 0x00800f06 C1: 0x000e0207 emmc: 200000000 actual: 50000000 div: 0x00000002 target: 50000000 min: 0 max: 50000000 delay: 1
MESS:00:00:09.386042:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:09.389049:0: brfs: File read: 595 bytes
MESS:00:00:09.571607:0: HDMI1:EDID error reading EDID block 0 attempt 0
MESS:00:00:09.576108:0: HDMI1:EDID giving up on reading EDID block 0
MESS:00:00:09.587219:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:10.349609:0: gpioman: gpioman_get_pin_num: pin DISPLAY_DSI_PORT not defined
MESS:00:00:10.355159:0: gpioman: gpioman_get_pin_num: pin DISPLAY_DSI_PORT not defined
MESS:00:00:10.364193:0: *** Restart logging
MESS:00:00:10.365968:0: brfs: File read: 595 bytes
MESS:00:00:10.536801:0: hdmi: HDMI1:EDID error reading EDID block 0 attempt 0
MESS:00:00:10.541884:0: hdmi: HDMI1:EDID giving up on reading EDID block 0
MESS:00:00:10.647659:0: hdmi: HDMI1:EDID error reading EDID block 0 attempt 0
MESS:00:00:10.652733:0: hdmi: HDMI1:EDID giving up on reading EDID block 0
MESS:00:00:10.658330:0: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
MESS:00:00:10.667090:0: HDMI0: hdmi_pixel_encoding: 300000000
MESS:00:00:10.672562:0: HDMI1: hdmi_pixel_encoding: 300000000
MESS:00:00:10.699204:0: dtb_file 'bcm2711-rpi-4-b.dtb'
MESS:00:00:10.715871:0: brfs: File read: /mfs/sd/bcm2711-rpi-4-b.dtb
MESS:00:00:10.719160:0: Loaded 'bcm2711-rpi-4-b.dtb' to 0x3e0000 size 0xdb93
MESS:00:00:10.760592:0: brfs: File read: 56211 bytes
MESS:00:00:10.782804:0: brfs: File read: /mfs/sd/overlays/overlay_map.dtb
MESS:00:00:10.848413:0: brfs: File read: 5627 bytes
MESS:00:00:10.853671:0: brfs: File read: /mfs/sd/config.txt
MESS:00:00:10.856339:0: dtparam: sd_poll_once=true
MESS:00:00:10.888203:0: dtparam: audio=on
MESS:00:00:10.899715:0: brfs: File read: 595 bytes
MESS:00:00:10.905001:0: brfs: File read: /mfs/sd/overlays/disable-bt.dtbo
MESS:00:00:10.946799:0: Loaded overlay 'disable-bt'
MESS:00:00:11.033338:0: brfs: File read: 1073 bytes
MESS:00:00:11.037683:0: brfs: File read: /mfs/sd/overlays/disable-wifi.dtbo
MESS:00:00:11.064288:0: Loaded overlay 'disable-wifi'
MESS:00:00:11.102744:0: brfs: File read: 387 bytes
MESS:00:00:11.107816:0: brfs: File read: /mfs/sd/overlays/upstream-pi4.dtbo
MESS:00:00:11.268966:0: Loaded overlay 'upstream-pi4'
MESS:00:00:11.693024:0: brfs: File read: 2775 bytes
MESS:00:00:11.700529:0: Failed to open command line file 'cmdline.txt'
MESS:00:00:12.846735:0: brfs: File read: /mfs/sd/RPI_EFI.fd
MESS:00:00:12.849243:0: Loaded 'RPI_EFI.fd' to 0x0 size 0x3d0000
MESS:00:00:12.854993:0: No compatible kernel found
MESS:00:00:12.859481:0: Device tree loaded to 0x3e0000 (size 0xe1dc)
MESS:00:00:12.869698:0: uart: Set PL011 baud rate to 103448.300000 Hz
MESS:00:00:12.875938:0: uart: Baud rate change done...
MESS:00:00:12.877961:0: uart: Baud rate change done...
MESS:00:00:12.886930:0: gpioman: gpioman_get_pin_num: pin SDCARD_CONTROL_POWER not defined
NOTICE: BL31: v2.9(release):v2.9
NOTICE: BL31: Built : 17:09:05, May 24 2023
UEFI firmware (version UEFI Firmware v1.41 built at 15:58:53 on Feb 21 2025)
ESC (setup), F1 (shell), ENTER (boot).....
/------------------------------------------------------------------------------\
| File Explorer |
\------------------------------------------------------------------------------/
> EFI41,
[VenHw(100C2CFA-B586-4198-9B4C-1683D195B1DA)/HD(1,MB
R,0xFC19AF42,0x2000,0x100000)]
/------------------------------------------------------------------------------\
| |
| ^v=Move Highlight <Enter>=Select Entry Esc=Exit |
\------------------------------------------------------------------------------/
Raspberry Pi 4 Model B
BCM2711 (ARM Cortex-A72) 1.50 GHz
UEFI Firmware v1.41 4096 MB RAM
Select Language <English> Continue
> Device Manager
> Boot Manager
> Boot Maintenance Manager
Continue
Reset
^v=Move Highlight <Enter>=Select Entry
>>Start PXE over IPv4. GNU GRUB version 2.12
PXE-E18: Server response timeout.
Minimal BASH-like line editing is supported. For the first word, TAB
lists possible command completions. Anywhere else TAB lists possible
device or file completions. To enable less(1)-like paging, "set
pager=1".
grub>
grub>
grub>
grub>
grub> insmod part_msdos
grub> set root=(hd0,1)
grub> source /boot/grub/t-basic2.cfg
grub> boot
EFI stub: Booting Linux Kernel...
EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services...
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd083]
[ 0.000000] Linux version 6.12.25+rpt-rpi-v8 (serge@raspberrypi.com) (aarch64-linux-gnu-gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT Debian 1:6.12.25-1+rpt1 (2025-04-30)
[ 0.000000] KASLR enabled
[ 0.000000] random: crng init done
[ 0.000000] Machine model: Raspberry Pi 4 Model B Rev 1.2
[ 0.000000] efi: EFI v2.7 by https://github.com/pftf/RPi4
,,,
- NeddySeagoon
- Administrator
- Posts: 56107
- Joined: Sat Jul 05, 2003 9:37 am
- Location: 56N 3W
szatox,
Everything to get booted is in the /boot partition.
There is no dd to unpartioned space.
Indeed, with GPT, there is no unpartioned space to dd to.
Well, kernel modules are not in /boot but they would need to be in an initrd if they were required to boot.
Everything to get booted is in the /boot partition.
There is no dd to unpartioned space.
Indeed, with GPT, there is no unpartioned space to dd to.
Well, kernel modules are not in /boot but they would need to be in an initrd if they were required to boot.
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Well... I tried a few things and here we are:
I pulled the repo with rpi firmware files and used it to prepare boot for my rpi gentoo. Dead. Like: not even a blink from the leds.
I copied over contents of boot from raspios into gentoo. Dead
I copied over contents of gentoo boot into raspios. Works fine.
There must be something missing that has to do with disk preparation and not with the files.
I see that raspios has a suspiciously large amount of empty space in front of boot. Kinda makes it hard to believe it's just for disk alignment... On a partition that doesn't see much access, let alone writes.
The only other difference I notice is that when I plug in the card with my gentoo image into my pc it automagically mounts both, boot and root, and when I plug in raspios, it only mounts boot.
Both cards are same brand and model; bought in one order.
I pulled the repo with rpi firmware files and used it to prepare boot for my rpi gentoo. Dead. Like: not even a blink from the leds.
I copied over contents of boot from raspios into gentoo. Dead
I copied over contents of gentoo boot into raspios. Works fine.
There must be something missing that has to do with disk preparation and not with the files.
Code: Select all
# fdisk -l /dev/sdb
Disk /dev/sdb: 59.63 GiB, 64021856256 bytes, 125042688 sectors
Disk model: TF CARD Storage
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x31c350a6
Device Boot Start End Sectors Size Id Type
/dev/sdb1 2048 524287 522240 255M c W95 FAT32 (LBA)
/dev/sdb2 524288 125042687 124518400 59.4G 83 Linux
Code: Select all
Disk /dev/sdb: 59.63 GiB, 64021856256 bytes, 125042688 sectors
Disk model: TF CARD Storage
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x96831db9
Device Boot Start End Sectors Size Id Type
/dev/sdb1 16384 1064959 1048576 512M c W95 FAT32 (LBA)
/dev/sdb2 1064960 125042687 123977728 59.1G 83 Linux
The only other difference I notice is that when I plug in the card with my gentoo image into my pc it automagically mounts both, boot and root, and when I plug in raspios, it only mounts boot.
Both cards are same brand and model; bought in one order.
- NeddySeagoon
- Administrator
- Posts: 56107
- Joined: Sat Jul 05, 2003 9:37 am
- Location: 56N 3W
szatox,
Just over five years ago I shared http://bloodnoc.org/~roy/Pi4/samo/
That's everything to go in /boot on a Pi4 plus a dir that goes into /lib/modules/
A couple of tests.
1. Unplug everything from the Pi4, including the SD card.
Connect the PSU. The red LED should light and the green LED should flash. The sequence of flashes will be repeated as it goes round and round the boot order. Disconnect the PSU when you get bored.
If you get any other LED indications, stop and post.
2. The Pi's don't need anything outside the filesystem to boot.
Using a spare SD card, make a new MSDOS disk lable on it. Mark the first partition as boot and format it VFAT.
Now copy the files from my link to the /boot you have just made.
No config.txt or cmdline.txt required. Yet.
No root filesystem either.
Rename the kernel to kernel8.img so that the automatics can load the kernel.
Connect a display to the Pi, so you can see it crash :)
Insert the /boot only SD card. Power up.
You should get the rainbow, followed by the early kernel messages.
It will fail to mount root ... there isn't one.
I can't remembei if early Pi4's need to be told to start in 64 bit mode or not.
You may need an SPI EEPROM update to make that automation.
It's possible to add a line to config.txt to force 64 bit too. I'm not on Gentoo right now, or I would tell you what it was.
Just over five years ago I shared http://bloodnoc.org/~roy/Pi4/samo/
That's everything to go in /boot on a Pi4 plus a dir that goes into /lib/modules/
A couple of tests.
1. Unplug everything from the Pi4, including the SD card.
Connect the PSU. The red LED should light and the green LED should flash. The sequence of flashes will be repeated as it goes round and round the boot order. Disconnect the PSU when you get bored.
If you get any other LED indications, stop and post.
2. The Pi's don't need anything outside the filesystem to boot.
Using a spare SD card, make a new MSDOS disk lable on it. Mark the first partition as boot and format it VFAT.
Now copy the files from my link to the /boot you have just made.
No config.txt or cmdline.txt required. Yet.
No root filesystem either.
Rename the kernel to kernel8.img so that the automatics can load the kernel.
Connect a display to the Pi, so you can see it crash :)
Insert the /boot only SD card. Power up.
You should get the rainbow, followed by the early kernel messages.
It will fail to mount root ... there isn't one.
I can't remembei if early Pi4's need to be told to start in 64 bit mode or not.
You may need an SPI EEPROM update to make that automation.
It's possible to add a line to config.txt to force 64 bit too. I'm not on Gentoo right now, or I would tell you what it was.
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Both leds lit up permanently.
I checked the display as well, got into a raspberry-pink boot selection screen with a qrcode pointing to https://www.raspberrypi.com/software/
The thing that's really bugging me is that I can transplant my own files into a stock image and it works, but I can't make either my files nor stock files work on a filesystem I created manually. And yes, I did use vfat for boot.
I checked the display as well, got into a raspberry-pink boot selection screen with a qrcode pointing to https://www.raspberrypi.com/software/
The thing that's really bugging me is that I can transplant my own files into a stock image and it works, but I can't make either my files nor stock files work on a filesystem I created manually. And yes, I did use vfat for boot.
- NeddySeagoon
- Administrator
- Posts: 56107
- Joined: Sat Jul 05, 2003 9:37 am
- Location: 56N 3W
szatox,
I don't know how you get boot selection screen.
NOOBS does it but it cheats. It boots twice.
Once to the selection screen, then to whatever you select.
It's not with any of the files you need to boot.
I don't know how you get boot selection screen.
NOOBS does it but it cheats. It boots twice.
Once to the selection screen, then to whatever you select.
It's not with any of the files you need to boot.
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
- NeddySeagoon
- Administrator
- Posts: 56107
- Joined: Sat Jul 05, 2003 9:37 am
- Location: 56N 3W
szatox,
That's the SPI EEPROM searching for something to boot.
That's normal.
The boot media only needs to be prepared as I said above.
Only the VFAT filesystem is required to get kernel messages.
When the SD card is read, one of the first things it does is to output the four pixel 'rainbow'.
If you don't see that, the card is not being read.
That's the SPI EEPROM searching for something to boot.
That's normal.
The boot media only needs to be prepared as I said above.
Only the VFAT filesystem is required to get kernel messages.
When the SD card is read, one of the first things it does is to output the four pixel 'rainbow'.
If you don't see that, the card is not being read.
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.