00:25 <smaeul> jernej: idle states turn the CPU off in the same way that hotplug or system suspend would, if that is what you are asking. though system suspend turns some additional bits off so it can kill the power supply at the PMIC

14:58 <jernej> smaeul: why are idle states good for then? can't psci already manage CPU cores?

15:04 <smaeul> jernej: I'm not sure what you're asking. The cpuidle driver uses the PSCI CPU_SUSPEND function to enter the idle state.

15:05 <jernej> yeah, but kernel can use psci directly to power off/on cores too, right?

15:06 <smaeul> yes, hotplug uses the PSCI CPU_ON/CPU_OFF functions

15:06 <smaeul> though I would not call that any more "direct" than using CPU_SUSPEND

15:07 <smaeul> the difference between CPU_OFF and CPU_SUSPEND is that with CPU_SUSPEND, an interrupt automatically turns the CPU back on

15:09 <jernej> So could this be the mechanism AW uses for H616 Android?

15:09 <smaeul> mechanism for what?

15:10 <jernej> I mean, there is no ARISC on H616, so probably there is some other method for suspend/resume on H616

15:11 <jernej> and if cores can be turned off by interrupt, that's easy way to have suspend/resume working with power button

15:11 <jernej> *turned on

15:12 <smaeul> yes and now

15:12 <smaeul> *no

15:13 <smaeul> there is a hardware block that implements the CPU power sequencing, and can turn on a CPU in response to an interrupt: https://linux-sunxi.org/CPUIDLE

15:13 <smaeul> (though this "CPUIDLE" hardware is distinct from Linux's cpuidle subsystem -- it can be used to implement either PSCI CPU_OFF or CPU_SUSPEND function)

15:15 <jernej> can you select which interrupts wakes up cores?

15:16 <smaeul> only by preconfiguring the GIC before turning off the CPU

15:35 <smaeul> jernej: looking back at your original question, maybe I can give a more helpful answer. Yes, idle states can be used for suspend/resume. This is exactly what s2idle is: calling PSCI CPU_SUSPEND from every CPU in the system

15:38 <smaeul> as opposed to what Linux calls "s2ram" or "deep" sleep, which is calling CPU_OFF for all except one CPU, then calling SYSTEM_SUSPEND from that remaining CPU

15:44 <smaeul> it's up to the PSCI implementation whether the result of s2idle vs s2ram is any different

15:45 <jernej> TF-A implements idlestates only for A64, right?

15:46 <jernej> or can be that reused for other SoCs as well?

15:47 <smaeul> currently, yes, mainline TF-A only advertises them for A64. They should work for H6 as well without any code changes; someone would just need to measure the latencies and power consumption.

15:49 <smaeul> (when using crust, that is)

15:50 <smaeul> TF-A could implement idle states natively for H6 and H616 as well, using the hardware block instead of SCPI

15:51 <smaeul> if you did this, then s2idle and s2ram would be exactly the same on H616

15:53 <smaeul> AW's implementation probably does additional steps for s2ram, like suspending the DRAM controller and slowing down the bus clocks. You could do all this from TF-A as well

15:54 <smaeul> (though any code that runs with DRAM suspended must be placed in SRAM, so it would be some thunk called by TF-A, sort of like the or1k thunk that exists today )

15:54 <jernej> but TF-A resides in H616 DRAM, right?

15:55 <jernej> yeah

17:49 <CornflakeDeath> i'm trying to get uart working on my a13 tablet, using a multimeter and looking at the sdcard socket description in the original fex i've established that the rx/tx pads connect to PF01 and PF04

17:50 <CornflakeDeath> which sounds good but according to the A13/PIO wiki page it's completely wrong?

17:51 <CornflakeDeath> that page says PF4 is UART0 RX and PF1 is JTAG_TDI

17:54 <CornflakeDeath> i modified my fex to use PF1/PF4 and it didn't work, but the fault might have been somewhere in my boot process because this was the first time i tried to boot from usb instead of sd

17:56 <CornflakeDeath> maybe somebody here will be able to help with identifying the issue. are my board's uart pads useless, do i not know how to use a multimeter, can i boot legacy 3.4 kernels from usb in fel mode?

17:59 <CornflakeDeath> the original script.bin disables all uart ports and the default config is again completely different, so i wasn't even able to test my usb pl2303 device

18:04 <smaeul> are you using pads on the PCB, or a microSD card breakout board?

18:04 <smaeul> the SoC certainly supports UART on port F, though you won't be able to use that UART and an SD card at the same time

18:05 <CornflakeDeath> the pcb pads. i don't even know where to buy an sd breakout board and decided i didn't even need one since soldering wouldn't be a problem

18:07 <CornflakeDeath> maybe i should try connecting to PF4 and PF2 anyway?

18:08 <smaeul> if the PCB pads are labeled RX/TX, then I would assume they are correct

18:09 <smaeul> have you tried FEL booting uart0-helloworld-sdboot.bin ?

18:10 <smaeul> that will allow you to test your connection without worrying about software issues

18:10 <CornflakeDeath> do i need script.bin or a dtb for it?

18:14 <CornflakeDeath> maybe i'm just unable to use a multimeter? i switched it to the mode labeled by a triangle pointing to the right, with a vertical line and struck through with a horizontal line, then connected one probe to rx and the other to every pin under the sdcard socket one after another until the meter's display said 0 or close to 0

18:16 <CornflakeDeath> by this method i determined that there are two ground pins which appears to be correct since the mmc config in my fex file only mentions 7 out of 9

18:21 <CornflakeDeath> since the last pin was ground i assumed PF00 had to be the first one (from the left) but this was just a guess. if PF00 is the second to last and one of those pins is PG00 (mentioned in the mmc config) then TX may really be on PF02 and RX on PF04

18:46 <smaeul> no, uart0-helloworld-sdboot.bin is totally standalone. for A13 it hardcodes using the UART on port F

18:49 <CornflakeDeath> it works. thank you so much for the suggestion

18:51 <smaeul> of course that only tests one direction. you could implement some uart0_getc() in uart0-helloworld-sdboot.c, or just assume the other direction works until proven otherwise

18:52 <smaeul> at least you know the connection is good for receiving log messages from the bootloader

18:53 <CornflakeDeath> for now i'm trying to get messages from the kernel though

18:57 <CornflakeDeath> can i try to boot a kernel without a rootfs for this purpose? do i need to enable early printk before i compile it?