02:03 <macromorgan> yes, all of them do

02:04 <macromorgan> the only ones I've worked on thus far are the H700 based devices (Anbernic models RG35XX-Plus, RG35XX-2024, RG35XX-H, RG35XX-SP, and RG28XX) and the V3S based device (Anbernic RG Nano)

02:05 <macromorgan> which is to say all of their Allwinner lineup

02:09 <tokyovigilante> very annoying googling for info about the display engine now and only finding my patches... #FWDPs

02:10 <macromorgan> yeah, I hate it when that happens

02:10 <tokyovigilante> thanks apritzel for the review of the cpufreq patch too

02:11 <tokyovigilante> Good to see a clang build works though

02:11 <tokyovigilante> [ 0.000000] Linux version 6.10.0-rc2+ (ryan@crackotage) (clang version 17.0.0 (https://github.com/apple/llvm-project.git c7c87ee42989d4bea0df5eb1b7c16fcf358d6c35), GNU ld version 2.41-1.fc41) #56 SMP PREEMPT Wed Jun 19 14:08:50 NZST 2024

15:49 <smaeul> 11:59 <apritzel> well, the AXP PMICs support some kind of suspend mode, but I don't know if that keeps the DRAM rails alive

15:49 <smaeul> entering AXP PMIC suspend mode just records the regulator enable state, and exiting restores the recorded state. you still have to disable regulators in software

15:50 <smaeul> 11:50 <apritzel> the secondaries could be completely off, but you would need something to run the wakeup code, right?

15:50 <smaeul> the CPU complex can be put in reset if there's a hardware state machine to bring it back up when receiving an IRQ, which there is: https://linux-sunxi.org/CPUIDLE

15:51 <smaeul> but without an ARISC you can't do anything _else_ after WFI like disabling VDD_CPUX

15:57 <smaeul> 12:04 <apritzel> I think it can even run on a 32KHz oscillator, so you can turn the 24 MHz osc off

15:57 <smaeul> yep, you can isolate the ARISC so you can power off VCC_DRAM/VCC_PLL/VDD_SYS as well (everything but VCC_PL/VCC_RTC/VDD_CPUS) and still be running code with access to the outside world through the R_ peripherals

16:02 <smaeul> btw there are things you can do to save power without losing access to DRAM, like bypassing and powering off all of the other PLLs

16:16 <apritzel> smaeul: thanks for the input!

16:17 <apritzel> smaeul: regarding PMIC suspend mode: from what I gather from the AXP717 manual, waking up from suspend only work via either an I2C register write (by software), or via the IRQ line

16:18 <apritzel> I guess the latter also comes from the SoC?

16:18 <apritzel> but apparently you cannot wake up the PMIC via the Power Key?

16:20 <apritzel> and I agree in general: we need some code to turn off devices, go to WFI, wakeup and return

16:21 <apritzel> what "turn off devices" really means, it's an implementation detail, so to speak, so we can start easy (like turning off as many PLLs as possible)

16:22 <apritzel> and then enhance this later, with stuff like turning PMIC rails off, using DRAM self refresh, and so on

16:23 <apritzel> smaeul: I was wondering if crust would be helpful here? Can we compile it for aarch64, and put (some of) it into SRAM A1?

18:22 <halal_beef> long time no see, finally got my orangepi zero3, had to rebuy it cause im pretty sure the original order got lost in china, but thats all done and dusted now, im trying to boot some baremetal code as a kernel on it posing as a kernel but it seems like U-Boot isnt a fan of it, it shows "FDT_ERR_BADMAGIC" though i dont even really see why it would, i dont see any appended dtbs on the kernel, any help would be appreciated

18:41 <Jookia> halal_beef: are you using 'go' as the booting command

18:41 <halal_beef> im just letting the device autoboot through u-boot

18:56 <halal_beef> had to fatload it and use go lol, anyways i think its time to try get this running now, thanks

19:01 <Jookia> nice

19:04 <halal_beef> btw is it normal for even a linux kernel to just hang on nothingness when i fatload and go?

19:05 <Jookia> yes, the kernel needs to be loaded a specific way

19:05 <Jookia> using bootz or bootm :)

19:05 <halal_beef> ahh lmao

19:42 <halal_beef> well i found out for some reason the board was reverting to the onboard u-boot which was the reason why nothingness was happening, sadly the non onboard stuff isnt much better, using fatload mmc 0:3 0x40080000 payload.bin and doing go 0x40080000 ends up in a phat synchronous exception, https://pastebin.com/1jVY7QRD

19:57 <halal_beef> nvm, managed to fix it, no more exception

20:10 <halal_beef> holy crap, i have the baremetal running

20:10 <halal_beef> thanks guys :DD

22:21 <smaeul> apritzel: crust is intended to support multiple ISAs, yes. You'd need to replace the whole main loop to run it on the main ARM/RISC-V CPUs; currently it's designed to not touch anything until after the other CPUs are off, to avoid MMIO races.

22:35 <smaeul> apritzel: my interpretation is that either the SoC or the PMIC can drive the IRQ line low, and either one counts. It should be easy to test.

22:35 <smaeul> (for the SoC driving the IRQ line low, search "irq output to nmi pad" in the H616 manual)

22:55 <apritzel> smaeul: thanks, but my hope was that the power key would trigger the PMIC wakeup. Then we could turn all cores off, but keep VCC_DRAM alive, and on resume the SoC would reboot, but then shortcut the boot process

22:56 <apritzel> I am not sure if the PMIC being in suspend helps too much if we need a core anyway: we could just program the PMIC manually to take most rails offline

22:57 <apritzel> smaeul: do you use PMIC suspend in crust at the moment? And does it bring you something?