I haven’t encountered any booting issues with my current DietPi image; however, I had some challenges have with older Radxa images, particularly as Janno’s mentioned reinstallation of the Radxa firmware… as he posed the github link for the once that work.
I apologize for lack of clarity in my communication.
Allow me to provide the specifications of my current setup using DietPi on the Rock 4 SE:
dietpi@cube2:~$ cat /proc/device-tree/model
Radxa ROCK Pi 4B
It’s just a hunch, but it seems like Janno might be using a Rock Pi 4A. They seem to have success booting from RK3399 images but run into trouble with RK3399-T images.
I think i missed the comment that the new image is ready to use. I already sent all units out, but i need 2 more , so will buy them tomorrow and test it out.
I downloaded the image from official link under download page and I can confirm that it reports now “Radxa ROCK 4SE” under device-tree. It still does report as 4A in uboot, but i don’t think thats an issue.
Now it also seems to run with correct clocks of 1Ghz/1.5Ghz. Before it was running same clocks as 4A (1.4Ghz/1.8Ghz, so we were kinda overlclocking it.
Since the device tree defines the WiFi device, generally pretty similar to 4B, the only explanation I have is that it uses a different chip which has no driver in the kernel, or where it needs to be enabled explicitly. As the log in the linked issue does not contain any firmware loading error, I guess missing firmware is not the issue, but indeed no driver.
Are you refering to latest build?
I have already stated that wifi does not work in my prev post. I can retest it in next 24h if you think it’s changed.:
If it’s not too much to ask , could the limit of “one embedded image per post” be removed so I don’t have to photoshop them all together.
Also one minor but kinda useful thing - on stock fw it has blue heartbeat led. It’s currently not lighting up or not doing anything to show that OS is booted.
Are you sure? I literally downloaded the image from downloads area and was waiting like crazy to get it to blink and then resorted to checking router dhcp table. Sure enough it had already gotten the ip ( i did not have serial hooked on this time). Not blinking on me.
As I stated here, can you test with ROCK 4B device tree instead?
I mean it did all work in the past, so while some U-Boot update obviously broke it, maybe the previously used 4B device tree still works (better). Quite possible that Armbian applies some patches for it, which are missing for the 4 SE device tree.
Answering here now instead of on GitHub, so you both are involved :
root@DietPi:~# dmesg | grep brcmfmac
[ 7.411031] brcmfmac: F1 signature read @0x18000000=0x15264345
[ 7.430174] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[ 7.442834] brcmfmac mmc2:0001:1: Direct firmware load for brcm/brcmfmac43455-sdio.radxa,rockpi4b.bin failed with error -2
[ 7.468786] usbcore: registered new interface driver brcmfmac
[ 8.509931] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50
[ 9.539272] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50
At least we see now that this direct firmware load error is indeed more a warning that the generic firmware is used, since on ROCK 4B it works even that the symlinks are missing there as well.
So at this point I have no idea what is missing: The correct driver is loaded automatically, the correct firmware is loaded, but the adapter just does not show up . Confusing what changed, as both used to work on ROCK 4 SE previously, just using the ROCK 4B image. That a recent bootloader update broke it has been reported to Armbian already: Rock 4 SE not booting - Rockchip - Armbian Community Forums
Strange that something broke WiFi moreless in the same time range. Who knows whether whichever change at the bootloader indirectly affected WiFi device init as well and brought it into a stage where it cannot be fully initialised anymore when the kernel takes over.
.
. Confusing what changed, as both used to work on ROCK 4 SE previously, just using the ROCK 4B image. That a recent bootloader update broke it has been reported to Armbian already: