martinayotte

No worries ! Anyway, I think I found something interesting about overlays fixup scripts ... But this means it will take time to fix and get new build done for download ... For WiFi brcmfmac, please, create a new thread to avoid mixing issues ... EDIT : fixes are there : NEXT : https://github.com/armbian/build/commit/592c8bd76b006c64564d88145c867f231e5e3791 DEV : https://github.com/armbian/build/commit/88317839596ef844b3899c027d008f2b5911b96e EDIT2 : BTW, this bug seems to be present since months until now for A10./A13/A20 but not for H3/H5/H6, probably just because there are not a lots of overlays users on those platforms, and we didn't get any feedback about it, probably present since more than 8 months ...

As you can see here, it is a bit better ... But those look bad and probably the issue ... I've never seen such error ... I will dig more this issue ...

Please, let isolate the issue : don't do any update/upgrade, simply check the u-boot on freshly burned image to see if you have same issue. And please, tell us if /boot/boot.scr was there in your previous attempt ...

Good to know !

Weird !!! I don't see even any read for "Boot script loaded from mmc", neither for /boot/armbianEnv.txt or DT file here. and even less for overlays ... Since it is an upgrade that you have done, could you try a "virgin" image on new SDCard instead ? EDIT : On your updated card, can you do a "ls -l /boot", I bet the boot.src isn't there at all ... EDIT2 : @Igor Is that possible that u-boot update is deleting the boot.src but doesn't write new one ?

Right ! EDIT : for hacking : https://forum.odroid.com/viewtopic.php?t=4758

I don't have any ...

I don't have any Odroid, so what is the difference with their debug serial port ? EDIT : I've just looked at the C1+ schematic, and serial seems to be as simple as usual ...

I don't think it is worth the effort, what would be the gain ? ...

As I said in the other thread, it is not the kernel that manage those DT parameters, it is u-boot responsible to load them, so, we need to see in early u-boot log (before kernel started) if the fixup.scr apply succeeded or not . You need USB-TTL Serial dongle to watch those early logs ...

Not "dmesg", this is only kernel logs ... You need to grab u-boot log using USB-TTL Serial dongle, way before kernel start booting. Something like :

If you don't mind slow shipping, less than $1 from China thru eBay : https://www.ebay.ca/itm/2pc-USB-TTL-UART-Module-CH340G-3-3-5V-Serial-Converter-Switch-Replace-PL2303-FSC/323623304649

Was there some kind of error message during u-boot fixup.scr ?

If you purchase one, they are so cheap, it will help a lot ...

First, stop u-boot during startup with spacebar, and then check "printenv" to see what is the value of "fdtfile". If it is the wrong DT file, you can change it by overwritting "fdtfile" in /boot/armbianEnv.txt ...