SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 random: get_random_u64 called from kmem_cache_open+0x30/0x290 with crng_init=0 mem auto-init: stack:off, heap alloc:off, heap free:off Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes, linear) Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes, linear) Built 1 zonelists, mobility grouping on. CPU features: detected: ARM erratum 1319367 ARM_SMCCC_ARCH_WORKAROUND_1 missing from firmware CPU features: detected: Kernel page table isolation (KPTI) CPU features: kernel page table isolation forced ON by KASLR CPU features: detected: EL2 vector hardening Machine model: Raspberry Pi 4 Model B Rev 1.2 Booting Linux on physical CPU 0x0000000000 Thanks to everyone taking the time to take a look at this!Ĭode: Select all Starting start4x.elf 0xfec00200 The kernel and initrd I'm using for the RPI4B is the official Fedora 32 AARCH64 version which should be compatible with what the RPI4B needs when specifying arm_64bit=1 in config.txt or am I lacking a piece of knowledge as to what the RPI expects from the kernel to be loaded? Neither my RPI3B+ nor my new RPI4B manage to make due without some form of U-Boot + Bootloader. I could not find any resources as to why the start.elf (as well as start4.elf) would be unable to boot the PXE kernel + initrd.img. Has anyone done something like this successfully?.As I'm moving to RPI4B devices with 4G memory, this will be the past hopefully.įor the RPI4B I had to move to Fedora 32 (which is in BETA freeze but has full support for the RPI4B) and managed to get to step 8 (U-Boot still has DHCP issues) but when GRUB is trying to load vmlinuz + initrd.img, the kernel doesn't load with no error messages visible on the UART console. The RPI3B+ only has 1G of memory but the modern decompressed stage2 images seem to need more than that so I had to point the kernel to a NFS volume to read it from NFS instead which makes it not have to decompress it into memory. Hack 2: When supplying install.img (stage2 image) via HTTP, the PXE needs to download it first and then expand it into memory. The only way I was able to run that kernel + initrd.img is to put U-Boot and the GRUB2 EFI binary in front of the kernel load. It downloads the files but then all I get is a frozen UART console output. Hack 1: I did not get start.elf to load the Fedora 31 PXE kernel + initrd.img nor the GRUB2 EFI binary directly. Anaconda is loaded and installs Fedora 31 on SD card according to kickstart.Kernel boots, loads stage2 + kickstart file.Grub loads vanilla Fedora 31 vmlinuz + initrd.img PXE images.Script makes U-Boot pull down grubaa64.efi as well as the DTB.Pull bootcode.bin, fixupx.elf, startx.elf, upstream.dtbo and u-boot.bin from TFTP server assigned in DHCP lease.I managed to achieve this with the Raspberry Pi 3 B+ with full vanilla Fedora 31 AARCH64 (ARM64) support: Install OS to SD card according to kickstart instructions.Pull stage2 + kickstart file from HTTP server.My goal is to have a PXE similar to what x86_64 is doing: I don't want to make all of my RPIs dependent on a NFS volume. Most network boot projects out there revolve around booting a RPI from a NFS share that has the Raspbian root filesystem residing on the network. I've been working on a RPI PXE for a while and I'm a bit stuck right now.
0 Comments
Leave a Reply. |