DPL not deployed, DPAA2 ethernet not work

The U-Boot scripts for booting “OpenWrt from NAND” and “Built-in recovery” both contain the commands

mtd read dpl 0x80100000 && fsl_mc apply DPL 0x80100000

However, the scripts for the other boot variants do not, resulting in the DPL not getting loaded:

fsl-mc: Booting Management Complex ... SUCCESS
fsl-mc: Management Complex booted (version: 10.20.4, boot status: 0x1)
Hit any key to stop autoboot:  0

  *** U-Boot Boot Menu ***

     Normal boot
     Built-in recovery
     Boot from NVMe
     Boot from USB
     Boot from SD
     Boot OpenWrt from NAND
     Boot from network
     Boot from SATA
     U-Boot console

  Press UP/DOWN to move, ENTER to select

Device 0: Vendor: 0x15b7 Rev: 211070WD Prod: 2051A5445110
            Type: Hard Disk
            Capacity: 953869.7 MB = 931.5 GB (1953525168 x 512)
... is now current device
Scanning nvme 0:1...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
209 bytes read in 1 ms (204.1 KiB/s)
1:      Gentoo
Retrieving file: /vmlinuz-5.10.56
15211008 bytes read in 45 ms (322.4 MiB/s)
append: root=/dev/nvme0n1p3 rootfstype=ext4 rootwait console=ttyS0,115200 default_hugepagesz=2m hugepagesz=2m hugepages=256
Retrieving file: /fsl-ls1088a-ten64.dtb
21761 bytes read in 0 ms
## Flattened Device Tree blob at 90000000
   Booting using the fdt blob at 0x90000000
   Loading Device Tree to 000000009fff7000, end 000000009ffff500 ... OK
TEN64 ft_board_setup start, blob 000000009fff7000
INFO:    RNG Desc SUCCESS with status 0
INFO:    result 5959373965891544
TEN64 ft_board_setup end
fsl-mc: DPL not deployed, DPAA2 ethernet not work

Starting kernel ...

and sure enought no eth interfaces show up in Linux.

Is this intentional? Is a “normal boot” expected to load the DPL in some other way?

Following Normal Boot of Debian Bullseye from the bare metal store installed to mmc, I have working network interfaces. The relevant path through u-boot looks like

distro_bootcmdbootcmd_mmc0scan_dev_for_boot_partscan_dev_for_bootscan_dev_for_efiboot_efi_binarysetup_distroboot_efisf read 0x80001000 0x580000 0x40000 && fsl_mc lazyapply dpl 0x80001000

Looks like yours should be the same but passing through bootcmd_nvme0 instead of bootcmd_mmc0?

There is a different boot path for EFI/distroboot and ubifs/FIT images. Both need to load the DPAA2 DPL before handing off to the operating system.

The EFI path runs setup_distroboot_efi as late as possible as it invokes a device tree fixup (this can only be done once per boot, see this FAQ entry).

It looks like you are using a syslinux script, so you will need to add a hook for setup_distroboot_efi in a similar way to how boot_efi_binary does it.

I tried adding

run setup_distroboot_efi &&

to the beginning of the boot_extlinux variable, but then the serial console became all jumbled for some reason. If I just add

mtd read dpl 0x80100000 && fsl_mc apply DPL 0x80100000 &&

instead then everything works perfectly.

Just to clarify, in my case the u-boot path looks like


There is no EFI involved.

Ah, if you are loading the device tree yourself then applying the DTB is all you need to do. EFI is slightly different as the firmware supplies the blob.

Hm, if I remove the “dtb” line from extlinux.conf and change boot_extlinux to say

run setup_distroboot_efi && setenv fdt_addr ${fdt_addr_r} && sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}${boot_syslinux_conf}

then that also works. Maybe that’s better since then I get the benefit of “the fixup process” (whatever those are)? Perhaps this version should be in the u-boot defaults?