Locked out of mtdblock edk2 updates on orangepi 5 plus

[zuzzurro]

I am using Fedora 40/rawhide on my orangepi 5 plus after having installed edk2 on the mtdblock device (latest nightly release version in order to get a working keyboard). I can't update the firmware anymore because fedora doesn't see any mtd devices (using ACPI, it won't work, that's understood) and if I try using dtb the system just fails rebooting. Do you have a suggestion on how to break the deadlock?

[mariobalanica]

You need to use a DTB compatible with your kernel version. The one bundled with the firmware only works along Rockchip's SDK kernel.

Updating the firmware on SPI NOR is not currently supported with ACPI boot, so you'd have to use a separate computer.

[zuzzurro]

OK, so let me have another go at this. Just to be clear, when you say "you need to use a DTB compatible with your kernel version" what do you mean precisely? Are you talking about https://github.com/edk2-porting/edk2-rk3588?tab=readme-ov-file#custom-device-tree-blob-dtb-override-and-overlays?

[mariobalanica]

Yes.

[zuzzurro]

OK, thanks. So I actually have tried doing that but the system crashes and I cannot really see where. Initially it seemed to crash when accessing my nvme SATA 5 ports card but I will have to test again. One more thing, if I understand correctly the dtb needs to be stored in the /boot/uefi vfat partition under /dtb/base, but Fedora puts the dtbs in /boot if I'm not wrong. Are you saying that this copy would need to be done manually every time there is a change in the dtb?

[mariobalanica]

It needs to be placed in the same partition as the bootloader, that is the FAT32 EFI System Partition.

Are you saying that this copy would need to be done manually every time there is a change in the dtb?

Yes, the firmware only looks in that specific location. You could probably load the DTB from another path with Grub instead.

[zuzzurro]

Thanks, I was able to move on by using a separate computer. Can you explain what can be expected to happen once the mainline kernel fully supports the rk3588 hardware? I think you mentioned somewhere that you use fedora as you development platform, so I assume you should know this very well. In particular, is it going to be necessary to use edk2 for booting fedora or an update to u-boot will be enough? I'm thinking about arm-image-installer adding support for the various rk3588 boards out of the box.

[mariobalanica]

EDK2 vs U-Boot is just a matter of preference in this case, either will do provided you use a compatible device tree.

I am not up-to-date on the mainlining efforts, but the plan is to eventually include mainline DTBs for a few of the supported boards in EDK2, which would greatly simplify booting off-the-shelf distro images.

[zuzzurro]

This is interesting. Are you actually testing it? And who's going to declare that a board is "supported"? From what I see the level of "support" is never black and white... Are you going to provide both a mainline DTB and a legacy one?

[mariobalanica]

Are you actually testing it?

Yeah, I'd need to test a few distros that have recent enough kernel by that time. So Fedora would be a candidate.

And who's going to declare that a board is "supported"?

"Supported" in the sense that I have validated it to boot and has reasonable functionality (goal is better than ACPI). For this, I am only going to pick popular boards that have decent mainline support.

Still missing functionality in Linux falls outside the scope of this project. Mainline DTBs will only be provided for convenience.

From what I see the level of "support" is never black and white

True. As soon as you leave Rockchip's legacy BSP, your mileage will greatly vary. Since most board vendors don't care about investing in mainline, proper firmware, etc, users are at the mercy of community support (i.e. if it even exists for the board in question). This has always been the case with SBCs.

Are you going to provide both a mainline DTB and a legacy one?

Yes, that's the plan.

[zuzzurro]

So, 6.10.0rc1 exists on koji and I tried to run it. However (as I kind of expected) while panthor is compiled, is not loaded and if I try force loading it it doesn't get used. I suspect this is again a matter of using a legacy DTB, but it also means I'm kind of stuck because as I said previously I suspect that if I try using the included DTB, SATA won't work and therefore I won't be able to load my installation. I guess I'm still stuck until I find out how to unblock the SATA thing

[mariobalanica]

SATA likely needs a DT overlay. See: https://github.com/edk2-porting/edk2-rk3588?tab=readme-ov-file#device-tree-configuration for more info.

[zuzzurro]

You mean something like this?

https://github.com/radxa/kernel/blob/linux-5.10-gen-rkr3.4/arch/arm64/boot/dts/rockchip/overlay/rock-5b-sata.dts

But for the pcie3 nvme slot?

And in my case (I'm just trying here...):

// ROCK 5B Pcie M.2 to sata
/dts-v1/;
/plugin/;

/ {
    fragment@0 {
        target = <&pcie3x4>;

        __overlay__ {
            status = "disabled";
        };
    };

    fragment@1 {
        target = <&sata1>;

        __overlay__ {
            status = "okay";
        };
    };
};

Or maybe just:

// ROCK 5B Pcie M.2 to sata
/dts-v1/;
/plugin/;

/ {
    fragment@0 {
        target = <&sata1>;

        __overlay__ {
            status = "okay";
        };
    };
};

[zuzzurro]

Hello @mariobalanica . I did not make any progress here, can you help me? Can you suggest where to look for a device tree overlay that will work with my JMB585 based m.2 adapter? Right now I either stay in ACPI mode with no access to emmc/sd cards and more (that while working well enough for my uses seems to be clearly a dead end) or I have a device that boots but dies as soon as it tries to activate the SATA disks using DTB mode..

[mariobalanica]

So you're trying to use a PCIe SATA adapter on the bottom M.2 slot? In this case you don't need any overlay.

Are you using a DTB that matches the kernel version? The included DTB most certainly won't work properly with mainline kernels.

[zuzzurro]

I am, and it works fine in ACPI mode but in that case I cannot use sd cards or emmc and I cannot access the SPI memory, making managing boot loaders and stuff a big PITA. Yes, I tried the DTB included in Fedora rawhide latest, but as I said it boots and it seems to die when it tries accessing the SATA device.

[mariobalanica]

Please attach full dmesg here.

[zuzzurro]

I need to connect the serial console. It will take a bit of time. One more thing... do you think that 0.10 will change anything compared to 0.9.1+ that I'm using currently?

[mariobalanica]

No. If it works in ACPI mode but not DT, then it's either an issue with the RK PCIe driver in Linux or something missing in the device tree itself.

[zuzzurro]

Here's a fresh capture of the serial console output, hope it helps. By the way, I was wrong when I said that the system would crash. What I think it happens is that the SATA disks are simply not found and fedora waits forever for the boot SATA disk.

Also, the green lights in the controller board are green during boot but at some point they go off. That's what made me think that linux had crashed.

capture.txt

[zuzzurro]

Finally, the difference between this failed boot and a working one is me adding

GRUB_DEFAULT_DTB=dtb/rockchip/rk3588-orangepi-5-plus.dtb

in /etc/default/grub

If I remove the resulting devicetree=... line from the grub menu, the system boots. The fact that I see no mention of loading rk3588-orangepi-5-plus.dtb in the capture.txt is disappointing but I am no expert of device tree loading...

[mariobalanica]

You're still booting in ACPI mode:

Loading driver at 0x000EF8CB000 EntryPoint=0x000EF8D0EE4 FdtPlatformDxe.efi
FdtPlatform: FDT support is disabled by the settings.
Error: Image at 000EF8CB000 start failed: Unsupported

See https://github.com/edk2-porting/edk2-rk3588?tab=readme-ov-file#device-tree-configuration for how to configure the firmware to boot using DTB (and override the internal one with a copy from mainline).

Once that's done, it should print to the serial console that ACPI is disabled and later on (after selecting the boot option) the DTB file path.

[mariobalanica]

Ah, nevermind. I see Linux booted successfully with DTB (passed by Grub?)

However, the PCIe controllers are not being loaded: platform a41000000.pcie: deferred probe pending: rockchip-dw-pcie: missing PHY

Sounds like the DTB is missing something regarding the PHYs or the kernel modules are not there. That would be a question for the folks involved in rk3588 upstreaming and/or the person who worked on adding OPi 5 Plus support, as it's not a firmware issue.

[zuzzurro]

Ah, that's the breakthrough I was hoping for. Thanks very much for it. Is the pcie controller part of the platform or is it device specific? Also, can you pinpoint where exactly you see that the kernel booted in DTB mode?

[mariobalanica]

Is the pcie controller part of the platform or is it device specific?

It's part of the SoC, but each board can route things slightly differently.

Also, can you pinpoint where exactly you see that the kernel booted in DTB mode?

I'm judging by the devices being loaded (e.g. rockchip-dw-pcie and others) that are otherwise not present in ACPI.

I don't know if it's possible to make Grub more verbose in this regard. But if you use the documented firmware DTB override facility instead, it will print which file got loaded precisely. Note that this is completely pointless if you still have any devicetree= option in the grub config.