DPL not deployed, DPAA2 ethernet not work

Ten64 Forum
1

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?

2

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_bootcmd → bootcmd_mmc0 → scan_dev_for_boot_part → scan_dev_for_boot → scan_dev_for_efi → boot_efi_binary → setup_distroboot_efi → sf 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?

3

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.

4

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.

5

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

distro_bootcmd → bootcmd_nvme0 → scan_dev_for_boot_part → scan_dev_for_boot → scan_dev_for_extlinux → boot_extlinux

There is no EFI involved.

6

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.

7

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?

Thanks