<karlp>
what's the difference between peekpoke and devmem2?
<karlp>
ahh, more knobs and bits and timing stuff
<apritzel>
karlp: and not being broken on 64-bit ;-)
<apritzel>
but, for good measure, peekpoke has other bugs ...
<warpme_>
apritzel: argh. silly me as i read .offset in wrong way!
<karlp>
devmem2 being broken on 64bit sounds like somethign that would surely be addressed right? how is that sort of thing _still_ broken in this day and age?
<karlp>
man, power is rad. running linux on this h3 board, ~50mA. shutdown -h => 70mA.
<apritzel>
karlp: I guess because devmem2 isn't a proper package, more a dumped source file somewhere?
<apritzel>
karlp: most H3 boards don't have a PMIC, so poweroff isn't well implemented
<apritzel>
similar issue on the H5, but we made some effort in TF-A to bring the power consumption down anyway
<apritzel>
not sure if crust adds something to that
<karlp>
devmem2 is a package for me?I always presumed it was just the busybox one, and got updated as it was updated there.
<karlp>
never needed to look to be honest :)
<karlp>
yah, the power consumption doesn't really bother me, this is an always on device, mains powered, just fun thing to notice in testing.
<karlp>
huh, devmem2 on ubuntu says it's from lartware, which is a very very very old outdated page, with a no-longer functional php server...
<karlp>
so yeah, that's clearly not getting maintained by anyone :|
<apritzel>
karlp: I think I tried to report/fix it somewhere back then, but this didn't go anywhere
<karlp>
so now we just need ubuntu et al to get busybox back instead of this dangling devmem2.
<karlp>
surprised this sort of thing has lingered so long, but I guess it's pretty niche group of people who need it.
chewitt has quit [Quit: Zzz..]
chewitt has joined #linux-sunxi
<gamiee>
karlp: 70mA power usage isn't the biggest issue. For some reason, all of my H3's after shutdown start getting hot
<karlp>
well, I should say, this is 70mA at 12V, so yeah, 840mW..
<gamiee>
Ohh, it's 12V, then it totally makes sense
<apritzel>
karlp: oh, really? On my H5 I measure between 50 and 70 mA @ 5V (with my stupid "USB doctor" meter) in "poweroff"
<apritzel>
wasn't there some h3 fake power off binary somewhere?
<apritzel>
which basically turned off as much as possible (cores, devices, PLLs, ...)?
<gamiee>
Wouldn't be solution crust? Crust can disable most of peripherals too, isn't it ?
<karlp>
I wouldn't use my number as any sort of gospel, it's just this board's "on" vs "off"
<apritzel>
gamiee: yes, but H3 support is WIP for crust, AFAIK
<apritzel>
and I don't know if Linux would actually ask crust for poweroff
<gamiee>
apritzel: yes, it is still WIP, although, as far as I remember, some H3 device configs are inside crust already.
<apritzel>
on 64-bit systems we get this through Trusted-Firmware, which Linux asks via PSCI SYSTEM_OFF
<apritzel>
and TF-A then talks to crust
<gamiee>
can't crust detect somehow that cores are "inactive"?
<apritzel>
on the H3 there is no TF-A (yet?), but we could go through U-Boot's PSCI implementation, and call crust from there
<apritzel>
gamiee: I don't think this wouldn't work
<apritzel>
gamiee: the best thing you could look for is "all cores in WFI", but that doesn't mean "power off", it's just that Linux is idle
<gamiee>
apritzel: Isn't TF-A only for 64-bit devices?
<gamiee>
U-Boot's PSCI implementation could work, I actually could look into it .
<apritzel>
gamiee: originally it was, but for some years it now supports ARMv7 as well
<apritzel>
There is a port for the Rockchip RK3288
<apritzel>
gamiee: AFAIK smaeul was playing around with an H3 TF-A port
<apritzel>
gamiee: please update it to PSCI 1.0 on the way ;-)
<apritzel>
(the U-Boot implementation, I mean)
<gamiee>
Interesting, I will take look on smaeul github if I will find some work about this
<apritzel>
gamiee: for the TF-A port? I think the SRAM size was a showstopper there, so not sure this is going anywhere
<gamiee>
apritzel: well, then U-Boot is the only way then.
<apritzel>
yeah, should be much easier anyway
<gamiee>
Well, I don't have much skills with PSCI yet, so I'm not sure if I will be able to update it (at least at this time :D )
<apritzel>
gamiee: it's fairly simple, actually, you just need one additional function to advertise which function you implement
ats has quit [Quit: this new motherboard is great, but I bet it'd be even better if I turned off all the horrid workarounds for the old one]
<apritzel>
and the basic PSCI interface and functions are straight-forward
<apritzel>
you can skip over all those fancy cluster power management stuff
<gamiee>
well, then I might give it a try, the heat problem on shutdown is kinda huge problem (for me), since without fan, H3 can get up to 80C even with heatsink (inside a case)
<apritzel>
what is actually happening at sunxi arm32 poweroff? there doesn't seem to be some poweroff device for mach-sunxi?
<apritzel>
(in Linux, I mean)
ats has joined #linux-sunxi
<karlp>
everyone keeps talking abotu these hot h3s, but mine are just running finger touch cool no heatsink.
<gamiee>
karlp: this also depends on the circuits. Since H3 doesn't need PMIC, all required voltages are required to be supplied externally. For example, Orange Pi Zero Plus2 overheats even when it's idle. 70C - 85C is totally "normal" temperature for it.
<gamiee>
There was some discussions that Orange Pi made some changes to power ICs to cut-off price, but introduced overheating
<apritzel>
warpme_: what tells you it's this call that returns the EINVAL? There are tons of other returns in that function?
<warpme_>
apritzel: i put line-after-line printk and devm_request_threaded_irq returns exactly -22
<apritzel>
warpme_: then you should repeat this exercise in request_threaded_irq()
<warpme_>
h616 manual says: "Step10: Set GIC interface based on IRQ 51, write the bit[19] of the 0x03021104 register to 0x1.". I declared in DT Int51 for ths - but not sure what manual author was in mind saying "Set GIC interface based on IRQ 51"...
<apritzel>
I guess that's Chinglish for "use SPI 51" (as you did)
<apritzel>
just worth checking if it's IRQ 51 or SPI 51 (offset of 32 being the difference)
<apritzel>
warpme_: looks like it's IRQ 51, so you specify <GIC_SPI 19 ...> in the DT
<warpme_>
apritzel: ok i changed DT to SPI19. Now /sys/firmware/devicetree/base/soc/thermal-sensor@5070400/interrupts has 0x33 (51 in dec.). Still -22. Looking in /proc/interrupts i don't see GICv2 alloc.with 51. Is that when Int is not enabled - it will be not listed in /proc/interrupts?
<apritzel>
warpme_: yes, only enabled IRQs show up there
<apritzel>
but the DT dump should not read 0x33, but 0x13
<apritzel>
are you sure you are using the right DT
smaeul has quit [Quit: Down for maintenance...]
<warpme_>
hmm. when i'm doing property view in hex (/sys/firmware/devicetree/base/soc/thermal-sensor@5070400/interrupts) i'm getting | 00 00 00 00 │ 00 00 00 33 │ 00 00 00 04 │0x33 is 51. is this wrong?
<smaeul>
yes, of course crust adds something to H5 boards, real suspend/resume and real poweroff :) (including wakeup from either via button, IR remote, or RTC)
<smaeul>
crust does not officially support H3 yet, due to BROM bugs
<smaeul>
once I have those worked around, it will have the same feature set as H5
<warpme_>
now need to check is too low temp because sid calib data is nok or .... (calib routine is from BSP so should be ok...)
<apritzel>
was just wondering that's it's quite chilly in your room ;-)
<gamiee>
smaeul: what kind of BROM bugs???
<warpme_>
oh you know - west EU is colder - but not that much :-)
<warpme_>
i mean east
<smaeul>
gamiee: the CPU0 hotplug path is broken, so I have to use the "super standby" path
<smaeul>
and that means BROM will mess with some clocks during resume, which I have to account for
<smaeul>
apritzel: H3 would use PSCI => SCPI to communicate with crust, same as 64-bit boards