| View previous topic :: View next topic |
| Author |
Message |
twork
Apprentice
Joined: 28 Jul 2006
Posts: 185
|
 Posted: Mon Apr 29, 2024 4:33 pm Post subject: Fresh Pi4, fails on Boot00001 and Boot00002 |
 |
|
I'm (still) setting up my initial Pi4, on a QEMU image. Current hangup:
The VM boots and functions fine with a CD image. We fdisk an existing .raw file, install the OS, chroot into it, everything seems fine, but after the setup I can't make that disk image appear, much less boot. I'm leaving something out or set something wrong.
I'm reading:
https://wiki.gentoo.org/wiki/Raspberry_Pi4_64_Bit_Install#Kernel_command_line:_.2Fboot.2Fcmdline.txt
I've tried various entries in '/boot/cmdline.txt', nothing seems to make any difference, and I've started to suspect that my mistake is somewhere earlier in the boot sequence. It gets this far:
| Code: | BdsDxe: failed to load Boot0001 "UEFI Misc Device" from VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00): Not Found
BdsDxe: failed to load Boot0002 "UEFI Misc Device 2" from VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000): Not Found |
...pauses a while, then starts looking to net boot. To me that indicates I've declared no boot disk at all, no matter what's written in the boot commands.
That said, here are some cmdline.txt entries I've tried:
I know about the '/dev/vda1' vs. '/dev/mmcblk0p1' switch, so for example here's one of the lines I've tried:
| Code: | | dwc_otg.lpm_enable=0 console=tty root=/dev/mmcblk0p1 rootfstype=vfat rootwait cma=256M@256M net.ifnames=0 |
More like the page I'm following, tried:
| Code: | | dwc_otg.lpm_enable=0 console=tty root=PARTUUID=7e9d18fd-7238-4442-9869-c7b6c4316431 rootfstype=ext4 rootwait cma=256M@256M net.ifnames=0 |
Other variations abound; but obviously I'm lost. Clues?
Thanks. |
|
| Back to top |
|
 |
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54340
Location: 56N 3W
|
| Posted: Mon Apr 29, 2024 5:29 pm Post subject: |
|
|
twork,
It's not clear if you boot problems are in the QEMU VM or on the Pi itself.
The two boot differently. An arm64 VM will expect to use UEFI to get started.
On the Pi itself, the GPU loads the kernel, initrd (if any) and dtb into RAM while the CPU is held reset. When the CPU is released from reset, it begins executing the kernel.
Self extracting compressed kernel images are not supported on arm64, so the boot loader must do the decompression if you want to do that.
/boot/cmdline.txt is only useful on the Pi. There is no UEFI firmware on the Pi, so trying to use is expected to end badly.
| Code: | | dwc_otg.lpm_enable=0 console=tty root=/dev/mmcblk0p1 rootfstype=vfat rootwait cma=256M@256M net.ifnames=0 |
is certainly not correct.
The real root filesystem may not be rootfstype=vfat as it does not support lots of features that Linux depends on. e.g. permissions and symbolic links.
root=/dev/mmcblk0p1 will really be boot. The first partition on the boot media must be VFAT and contain all the things required to start the PI.
Now it gets more confusing to me. There is an embryonic UEFI 'firmware' for the Pi. The GPU loads it in the same way as it would load any other boot file.
Are you attempting to use that?
Its not something I've tried.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54340
Location: 56N 3W
|
| Posted: Mon Apr 29, 2024 5:30 pm Post subject: |
|
|
Moved from Installing Gentoo to Gentoo on ARM.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
twork
Apprentice
Joined: 28 Jul 2006
Posts: 185
|
| Posted: Mon Apr 29, 2024 10:59 pm Post subject: |
|
|
| NeddySeagoon wrote: |
It's not clear if you boot problems are in the QEMU VM or on the Pi itself. |
I have Pi4 hardware, which I want to run Gentoo.
In order to enable that, the only way I can think of is to boot a QEMU VM running ARM, put Pi Gentoo on that, finish the setup steps (right, the way one does on new hardware since time immemorial...?), then copy that back to the Pi4 hardware (dd, or...).
That's one of the reasons for there being a QEMU-or-hardware option, isn't it? Prep it here, run it there?
| NeddySeagoon wrote: |
/boot/cmdline.txt is only useful on the Pi. There is no UEFI firmware on the Pi, so trying to use is expected to end badly. |
Yeah, I knew that, and I expected there to be a process that I don't yet grok, something like: after we've constructed the system we want, shut down the VM, scratch in the "real" firmware on its /boot (or wherever), then transfer that to the Pi hardware.
| NeddySeagoon wrote: |
| Code: | | dwc_otg.lpm_enable=0 console=tty root=/dev/mmcblk0p1 rootfstype=vfat rootwait cma=256M@256M net.ifnames=0 |
is certainly not correct.
The real root filesystem may not be rootfstype=vfat as it does not support lots of features that Linux depends on. e.g. permissions and symbolic links.
root=/dev/mmcblk0p1 will really be boot. The first partition on the boot media must be VFAT and contain all the things required to start the PI. |
I've come to expect (incorrectly?) that the /boot partition of a Pi is DOS/FAT/whatever (why? dunno, maybe just because it's going to be tiny? maybe because some part of the RaspberryPi approach relies on FAT...? No idea, I'm cargo-culting here) and the main partition is ext4.
| NeddySeagoon wrote: |
Now it gets more confusing to me. There is an embryonic UEFI 'firmware' for the Pi. The GPU loads it in the same way as it would load any other boot file.
Are you attempting to use that?
Its not something I've tried. |
Yeah this is a scenario that's new to me; I've run Ubuntu and the "native" Pi OS on these machines. Both appear to have different approaches from each other, and from Gentoo, so I'm thumbing my way into this. Cargo culting, like I said. So when that fails (as it is currently), I have to go find the "right way".
My guess is, the Gentoo page has parts that Everybody Just Knows, but I'm unaware.
I could plug in the Pi4 hardware and work from that, but I don't know how to make it boot from a CD; I don't have a CD drive that plugs into Pi hardware; it'd also be inconvenient (give it a monitor, etc.). And, I think, the problem I'm having would still be there: having booted the OS from the CD, how would I attach the firmware between the SD and the fresh OS?
Obvious answers to those questions, I'm sure, but I Google and Google and Bard and Bard... |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54340
Location: 56N 3W
|
| Posted: Tue Apr 30, 2024 9:56 am Post subject: |
|
|
twork,
You can do a Gentoo install for a Pi an amd64 host without ever needing to chroot.
This Wiki Page has a good chance of covering the Pi6 too. :)
The Pi4 can build its own kernel in about an hour.
If you man to cross compile binary packages (no QEMU) that mostly works. too. See the bottom of that page
Cross compiling, where your native build host emits target binary code. is by far the fastest.
QEMU emulates the target CPU in software so its slow, but it does execute target code (via the emulation layer). A few thing can only built this way.
As it says at the top of Raspberry Pi4 64 Bit InstallThis page is in the process of being merged into the universal Raspberry Pi Install Guide.
About all that needs to be wove over is the WiFi and bluetooth sections.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo on ARM
