15:25 <narmstrong> Flole: indeed it’s a bug in u-boot and while the bad commit was identified, we failed to far to find a fix

17:57 <Flole> narmstrong: You mean the commit was already identified before yesterday? I spent 3 hours yesterday bisecting to figure out it's a9bf024b2933bba0e23038892970a18b72dfaeb4, and my "fix" is to just disable EFI in the u-boot build, then it works after that commit aswell. I don't think there's much use for EFI on the amlogic CPUs anyways, so not a big loss

18:09 <narmstrong> Flole: yep it’s this one, efi is used in products on amlogic socs so it should be definitely fixed

18:25 <Flole> narmstrong: I guess the only way to figure out what's wrong with it is creating additional output in all functions that were modified to figure out which is called just before the exception occurs? And then look at what parameters are passed (if any) and hope to gain more information from that?

19:24 <narmstrong> Flole: yep

20:59 <vagrantc> hey, heard that someone bisected the issue with odroid-c2 down to a9bf024b2933bba0e23038892970a18b72dfaeb4 efi_loader: disk: a helper function to create efi_disk objects from udevice ... huge thanks!

21:00 <vagrantc> does anyone know if it affects other board as well?

21:01 <vagrantc> in particular ... khadas-vim, khadas-vim2, odroid-n2, libretech-cc, nanopi-k2 ?

21:02 <vagrantc> those and the odroid-c2 are platforms currently enabled in the debian u-boot packaging ...

21:02 <vagrantc> if they're affected, might enable the same workaround

21:46 <Flole> vagrantc: That was me who bisected it and apparently it affects other boards aswell, I found https://oolong.secureendpoint.org/SEMIdev/build/commit/bed71ca1eea39ece7ba4d94f1962f9006badc5a0 so apparently it also affects the "jethubj100", whatever that might be

21:49 <Flole> And another report for some other JetHub board is at https://armbian.atlassian.net/browse/AR-1296, basically you can just search for the hash on google and you will find some reports. I assume it affects at least all boards with the s905

21:51 <Flole> At another board it caused garbage on the serial console: https://lore.kernel.org/all/CAOMZO5AOvUy0Vt8jXmfe5wrRKcB67taPnvRCALv0PN9bEvnLgw@mail.gmail.com/T/#mca89ab4cb6c390ab679eb7da93516c91ff22a18e

21:51 <Flole> Looks to me like there is some illegal memory access in certain cases

22:03 <Flole> I am curious about one thing with the odroid c2 and the "2 GHz-Bug". I am aware that the CPU should be capable of running at 2 GHz but apparently due to the voltage not being sufficient it doesn't work. What I am wondering is this: The source code for the bl301.bin which controls the voltage is public at https://github.com/hardkernel/u-boot_firmware/tree/odroidc2-bl301/, so theoretically

22:03 <Flole> I should be able to edit it. However, it's already close to 100% PWM so it can't bump the voltage up higher, even though the CPU is rated for more than those 1130mV. The schematics are all public so I could replace a resistor for the voltage regulator so the voltage rises higher, then I could take the current voltage table and adjust the values for 1.7 GHz and above and it should be

22:03 <Flole> stable theoretically, correct? I don't really need to change anything else, right (except for always unlocking the full table and not doing it based on that 7th bit, and probably adding better cooling aswell)?

22:48 <vagrantc> Flole: i'm mostly focused on getting things working at all again, even if suboptimally ... but thanks for your work!