Re: Grub doesn’t load devicetree

Sat Aug 31 01:48:23 CEST 2024

Update on this, it’s not the smmu node that is problematic, regardless if I add or remove it, the drivers for the DPAA architecture aren’t working:

[ 5.756406] cpu 1: ! CRITICAL FM Error [CPU01, drivers/net/ethernet/freescale/sdk_fman/Peripherals/FM/fm.c:3311 FM_Config]: Invalid Value;
[ 5.756412] cpu 1:
[ 5.768943] cpu 1:
[ 5.773220] cpu 1: ! MAJOR FM Error [CPU01, drivers/net/ethernet/freescale/sdk_fman/src/wrapper/lnxwrp_fm.c:1136 InitFmDev]: Invalid Handle;
[ 5.773223] cpu 1: FM
[ 5.785917] cpu 1:
[ 5.790388] fsl-fman: probe of 1a00000.fman failed with error -5
[ 5.796469] Freescale FM module, FMD API version 21.1.0
[ 5.801866] fsl-fman-port: probe of 1a82000.port failed with error -5
[ 5.808360] fsl-fman-port: probe of 1a83000.port failed with error -5
[ 5.814858] fsl-fman-port: probe of 1a84000.port failed with error -5
[ 5.821351] fsl-fman-port: probe of 1a85000.port failed with error -5
[ 5.827846] fsl-fman-port: probe of 1a86000.port failed with error -5
[ 5.834349] fsl-fman-port: probe of 1a87000.port failed with error -5

interestingly, they’re working fine if I bypass the EFI stub and load the kernel with booti (and give it the exact same device tree)

Any pointers as to where to look for a probable cause of this?

Tomaž Zaman, CEO
Mono Technologies Inc.
+386 30 651 645

[cid:0BC8C304A1D64EE6B1E9C0F91B0A388F]

On 29 Aug 2024 at 15:25 +0200, Tomaz Zaman <tomaz at mono.si>, wrote:
This is exactly what I’m testing now.

The board I’m working on has an SDK device tree which deletes the smmu node that’s defined in another dts file, and the lack of that node makes uboot throw errors, but if it’s there, then kernel doesn’t load correclty.

Tomaž Zaman, CEO
Mono Technologies Inc.
+386 30 651 645

[cid:9597EA2EB3714038B2BF48BCAAC0C1F8]

On 29 Aug 2024 at 14:18 +0200, Simon Glass <sjg at chromium.org>, wrote:
Hi Tomaž,

On Thu, 29 Aug 2024 at 03:44, Peter Robinson <pbrobinson at gmail.com> wrote:

On Thu, 29 Aug 2024 at 10:40, Tomaž Zaman <tomaz at mono.si> 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 <pbrobinson at gmail.com>,
wrote:

On Thu, 29 Aug 2024 at 10:31, Tomaž Zaman <tomaz at mono.si> 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 <pbrobinson at gmail.com>,
wrote:

On Thu, 29 Aug 2024 at 05:14, Tomaž Zaman <tomaz at mono.si> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0BC8C304A1D64EE6B1E9C0F91B0A388F.png
Type: image/png
Size: 5014 bytes
Desc: 0BC8C304A1D64EE6B1E9C0F91B0A388F.png
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20240830/4d4d4ec4/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 9597EA2EB3714038B2BF48BCAAC0C1F8.png
Type: image/png
Size: 5014 bytes
Desc: 9597EA2EB3714038B2BF48BCAAC0C1F8.png
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20240830/4d4d4ec4/attachment-0001.png>