usual user

And since it contains no firmware payload output, no one can tell what you are running.

My rk3588 devices are e.g. exposing this: v4l2-compliance-odroid-m2.txt And here is the visualization of a video pipeline: video-pipeline.pdf Watch out for the v4l2slh265dec component.

https://lore.kernel.org/linux-media/Z4e9wNxZjvnytXlL@pengutronix.de/

The mainline kernel has currently a shortcoming in USB-TYPEC support. FUKAUMI Naoki demonstrated a workaround for other devices that also works for the ODROID-M2.

Out of curiosity, does it work if you drop my firmware build in place? dd bs=512 seek=1 conv=notrunc,fsync if=u-boot-meson.bin of=/dev/${entire-device-to-be-used} u-boot-meson.bin.tgz

A phandle is a magical number assigned during DTB assembly, whose value is irrelevant as long as it references the same node with the phandle property. The magic value can change when the structure changes because it is assigned arbitrarily; for example, by inserting an additional node.

In an XWindow environment, these are realistically expected numbers. In a Wayland environment, this is somewhat better; see glmark2-wayland-odroid-m1.log as a reference. But it is in no way comparable to a Mali G610; see glmark2-wayland-odroid-m2.log as a reference. Use WebGL Report to be sure.

Since you have now confirmed the HDMI functionality, the time has come for me to retire further support. I am only interested in generic support; for Armbian-specific issues, you'll have to wait for others who are interested.

Just out of curiosity, are you able to run your device with firmware loaded from microSD? I. e. firmware area on eMMC cleared. If so, you can try my kernel build and see how it works for you.

ODROID M1: dmesg | grep -i hdm [ 0.132185] /vop@fe040000: Fixed dependency cycle(s) with /hdmi@fe0a0000 [ 0.132325] /hdmi@fe0a0000: Fixed dependency cycle(s) with /vop@fe040000 [ 0.170085] /hdmi@fe0a0000: Fixed dependency cycle(s) with /hdmi-con [ 0.170254] /hdmi-con: Fixed dependency cycle(s) with /hdmi@fe0a0000 [ 1.180141] dwhdmi-rockchip fe0a0000.hdmi: Detected HDMI TX controller v2.11a with HDCP (DWC HDMI 2.0 TX PHY) [ 1.181147] dwhdmi-rockchip fe0a0000.hdmi: registered DesignWare HDMI I2C bus driver [ 1.182413] rockchip-drm display-subsystem: bound fe0a0000.hdmi (ops dw_hdmi_rockchip_ops) ODROID M2: dmesg | grep -i hdm [ 0.104853] /vop@fdd90000: Fixed dependency cycle(s) with /hdmi@fde80000 [ 0.104911] /hdmi@fde80000: Fixed dependency cycle(s) with /vop@fdd90000 [ 0.121323] /hdmi@fde80000: Fixed dependency cycle(s) with /hdmi-con [ 0.121364] /hdmi-con: Fixed dependency cycle(s) with /hdmi@fde80000 [ 0.547910] dwhdmiqp-rockchip fde80000.hdmi: registered DesignWare HDMI QP I2C bus driver [ 0.548835] rockchip-drm display-subsystem: bound fde80000.hdmi (ops dw_hdmi_qp_rockchip_ops) ODROID N2+: dmesg | grep -i hdm [ 0.079885] /soc/bus@ff600000/hdmi-tx@0: Fixed dependency cycle(s) with /soc/vpu@ff900000 [ 0.080281] /soc/vpu@ff900000: Fixed dependency cycle(s) with /soc/bus@ff600000/hdmi-tx@0 [ 0.080908] /soc/bus@ff600000/hdmi-tx@0: Fixed dependency cycle(s) with /soc/vpu@ff900000 [ 0.081352] /soc/bus@ff600000/hdmi-tx@0: Fixed dependency cycle(s) with /soc/vpu@ff900000 [ 0.090819] /soc/bus@ff600000/hdmi-tx@0: Fixed dependency cycle(s) with /soc/vpu@ff900000 [ 0.090892] /soc/vpu@ff900000: Fixed dependency cycle(s) with /soc/bus@ff600000/hdmi-tx@0 [ 0.097002] /soc/bus@ff600000/hdmi-tx@0: Fixed dependency cycle(s) with /hdmi-connector [ 0.097080] /hdmi-connector: Fixed dependency cycle(s) with /soc/bus@ff600000/hdmi-tx@0 [ 0.561480] meson-dw-hdmi ff600000.hdmi-tx: Detected HDMI TX controller v2.01a with HDCP (meson_dw_hdmi_phy) [ 0.561810] meson-dw-hdmi ff600000.hdmi-tx: registered DesignWare HDMI I2C bus driver [ 0.562112] meson-drm ff900000.vpu: bound ff600000.hdmi-tx (ops meson_dw_hdmi_ops) NanoPC-T6-LTS: dmesg | grep -i hdm [ 0.119431] /vop@fdd90000: Fixed dependency cycle(s) with /hdmi@fde80000 [ 0.119475] /hdmi@fde80000: Fixed dependency cycle(s) with /vop@fdd90000 [ 0.137536] /vop@fdd90000: Fixed dependency cycle(s) with /hdmi@fdea0000 [ 0.137589] /hdmi@fdea0000: Fixed dependency cycle(s) with /vop@fdd90000 [ 0.139716] /hdmi@fde80000: Fixed dependency cycle(s) with /hdmi0-con [ 0.139765] /hdmi0-con: Fixed dependency cycle(s) with /hdmi@fde80000 [ 0.139922] /hdmi@fdea0000: Fixed dependency cycle(s) with /hdmi1-con [ 0.139960] /hdmi1-con: Fixed dependency cycle(s) with /hdmi@fdea0000 [ 0.579865] dwhdmiqp-rockchip fde80000.hdmi: registered DesignWare HDMI QP I2C bus driver [ 0.580803] rockchip-drm display-subsystem: bound fde80000.hdmi (ops dw_hdmi_qp_rockchip_ops) [ 0.582184] dwhdmiqp-rockchip fdea0000.hdmi: registered DesignWare HDMI QP I2C bus driver [ 0.583115] rockchip-drm display-subsystem: bound fdea0000.hdmi (ops dw_hdmi_qp_rockchip_ops) At all HDMI ports work perfectly. And yes, they all use the same system booted from a USB enclosure. The only difference is the loaded DTB at system startup.

Maybe another important data point to consider – are both of you running the same firmware?

That was just a simple one-liner (fdtoverlay -i rk3588-nanopc-t6.dtb -o rk3588-nanopc-t6.dtb rk3588-nanopc-t6-emmc.dtbo). In order to carry out the test in my environment, the typing task was a little more complex: It apparently depends on how the overlay was applied, because fundamentally it should also work when applied dynamically. However, the static application of an overlay has the disadvantage that in the case of an incompatibility, one is only confronted with an error message and does not experience a system that fails to start. It is not very difficult to get it out. It is held only by the slight adhesive strength of the thermal pad between the SoC and the casing when the bottom plate is removed. A cautious light steady pull releases it. The only difficulty is in gripping the board to make apply this pull. I screwed a bolt into one of the mounting PCB nuts and used it as a handle. With such a socket in one of the SMA antenna connection ports, the UART connection can be permanently routed to the outside without modifying the casing. I use it to route the fan connector outside. Without the possibility of providing meaningful serial console logs, you will probably be left on your own with it.

Admittedly, I had not tested the DTBO at runtime so far, but only applied it statically to the base DTB and checked whether all desired changes were made as intended. Now I am running my device with the applied overlay and I get the following: [ 0.940862] mmc0: new HS200 MMC card at address 0001 [ 0.941665] mmcblk0: mmc0:0001 A3A561 57.6 GiB [ 0.943039] mmcblk0: p1 p2 [ 0.943767] mmcblk0boot0: mmc0:0001 A3A561 4.00 MiB [ 0.945199] mmcblk0boot1: mmc0:0001 A3A561 4.00 MiB [ 0.946661] mmcblk0rpmb: mmc0:0001 A3A561 16.0 MiB, chardev (506:0) So everything is as expected, and yes, I have ensured that my system is running with the applied overlay. In the past, I have at least once noticed far too late that my system was running in a fallback, and a feature to be tested was not applied at all. That's just the disadvantage of a fail-safe system that only leaves a non-functional system in an extreme exceptional situation. Since you haven't provided meaningful logs, I can't say what is going wrong on your end. To rule out an error when applying the overlay, you could start your system with this DTB (rk3588-nanopc-t6.dtb) , which already contains the overlay applied statically.

You will certainly gain many grateful users whose devices are not equipped with an affected eMMC, but who still have to suffer from the slowdown nonetheless. Does the attached overlay work for you?rk3588-nanopc-t6-emmc.dtbo

Oh, sorry, I didn't notice the non-existent 6 and read it as Helios64. Of course, my description of the boot method is not limited to Rockchip devices; it works on all for which a mainline U-Boot is available. I have used it on iMX6, LX2160A and S922X devices, but my remaining devices are all based on Rockchip. The solutions are too varied to present a turnkey solution here. However, I am sure that only a corresponding configuration for implementation is required to achieve the desired behavior, but for that, the U-Boot documentation must be consulted to decide which solution should be chosen.