Hi Tomaž, On Thu, 29 Aug 2024 at 03:44, Peter Robinson <[email protected]> wrote: > > On Thu, 29 Aug 2024 at 10:40, Tomaž Zaman <[email protected]> wrote: > > > I get this: > > > > No UEFI binary known at 0x81000000 > >
That is the UEFI hack which we need to clean up at some point. When you load an image, it calls efi_set_bootdev() so EFI knows where it came from. You could check that the call is happening in your case. Can U-Boot use the same DT as Linux? > > Are you building the kernel with all the appropriate UEFI shim bits? > Installing the EFI kernel pieces etc? > > Sorry, I can't help with kernel build process bits, you'll need to google > that. > > > > *Tomaž Zaman, *CEO > > Mono Technologies Inc. > > +386 30 651 645 > > > > > > > > On 29 Aug 2024 at 11:38 +0200, Peter Robinson <[email protected]>, > > wrote: > > > > > > > > On Thu, 29 Aug 2024 at 10:31, Tomaž Zaman <[email protected]> wrote: > > > >> Doesn’t work - at least not correctly: > >> > >> => fatload mmc 0:1 $fdt_addr_r /boot/dtb/fsl-ls1046a-rdb-sdk.dtb > >> 31793 bytes read in 4 ms (7.6 MiB/s) > >> => fatload mmc 0:1 $kernel_addr_r /EFI/boot/grubaa64.efi > >> 3978688 bytes read in 168 ms (22.6 MiB/s) > >> => setenv fman_ucode > >> => bootefi $kernel_addr_r $fdt_addr_r > >> Failed to load EFI variables > >> WARNING failed to get smmu node: FDT_ERR_NOTFOUND > >> WARNING failed to get smmu node: FDT_ERR_NOTFOUND > >> Booting /\EFI\boot\grubaa64.efi > >> Welcome to GRUB! > >> > >> Because of those FDT_ERR_NOTFOUND kernel reports a bunch of errors and > >> doesn’t boot with all the hardware support I need it to. > >> > >> On the other hand, if I run the same kernel/devicetree/initramfs with > >> booti, bypassing the Grub completely, it works fine. The problem is, I need > >> Grub2 for his project. > >> > > > > What if you boot the kernel directly using bootefi rather than booti? > > > > > >> *Tomaž Zaman, *CEO > >> Mono Technologies Inc. > >> +386 30 651 645 > >> > >> > >> > >> On 29 Aug 2024 at 10:02 +0200, Peter Robinson <[email protected]>, > >> wrote: > >> > >> On Thu, 29 Aug 2024 at 05:14, Tomaž Zaman <[email protected]> wrote: > >> > >> > >> I’m working on an arm64 board with an NXP LS1046A CPU and I simply cannot > >> get Grub to load a different device tree than the one that’s provided to it > >> by the EFI Stub. > >> > >> => fatload mmc 0:1 $kernel_addr_r /EFI/boot/grubaa64.efi > >> => fatload mmc 0:1 $fdt_addr_r /boot/dtb/fsl-ls1046a-rdb-sdk.dtb > >> => bootefi $kernel_addr_r $fdt_addr_r > >> > >> At his point, I get a couple of errors like “smmu node not found”. > >> > >> However, if I, instead of "fsl-ls1046a-rdb-sdk.dtb” use > >> "fsl-ls1046a-rdb.dtb”, then I get to Grub without any errors. > >> > >> And this is where I encounter the issue. Because I would like to use a > >> different DTB for booting Linux than the one that’s provided by the EFI > >> configuration table, I set > >> > >> devicetree /boot/dtb/fsl-ls1046a-rdb-sdk.dtb > >> linux /boot/vmlinuz-6.6.3-arm64 > >> initrd /boot/initrd.img-6.6.3-arm64 > >> > >> In this case, the devicetree instruction gets ignored completely, and > >> before I see kernel loading, the message “Using FDT from the EFI > >> configuration table" > >> > >> Is there a way for me to override/replace the device tree that u-boot > >> passed to Grub? I tried passing the “dtb=“ parameter to the kernel boot > >> command, but in that case, I get "EFI stub: ERROR: Failed to handle > >> fs_proto” because kernel when booting doesn’t appear to have access to the > >> same filesystem that Grub does. > >> > >> > >> Why don't you load a new one into memory with u-boot and then grub > >> will already have the one you want to use and grun doesn't need to do > >> anything. Something like this on the U-Boot command line would load > >> the DT and grub and start to boot: > >> > >> load mmc 0:1 ${kernel_addr_r} EFI/BOOT/BOOTAA64.EFI > >> load mmc 0:1 ${fdt_addr_r} dtb/${fdtfile} > >> bootefi ${kernel_addr_r} ${fdt_addr_r} > >> > >> You'll need to adjust for storage, partitions, file paths etc. > >> > >> Thank you! > >> > >> > >> (this is my first time using *any* mailing list, so apologies if this is > >> the wrong address to send this question to) > >> > >> Tomaž Zaman, CEO > >> Mono Technologies Inc. > >> +386 30 651 645 > >> > >> [cid:18EB2FEE485A4DD7A1CE716CE14FCBC7] > >> > >> Regards, Simon
