szemzoa has quit [Remote host closed the connection]
<apritzel>
paulk: yeah, jernej did it the usual way: disassembly and register dumps
<paulk>
I see, so maybe a full I/O trace could still be somewhat useful
szemzoa has joined #linux-sunxi
<apritzel>
paulk: I think jernej is hunting down one issue in the TF-A code still, maybe tracing would help here:
<apritzel>
PSCI_CPU_OFF works, but it doesn't come back on (so "echo 0 > cpu2/online; echo 1 > /cpu2/online" doesn't work)
<apritzel>
we suspect there is a certain order of register writes required, or we miss some registers
<apritzel>
paulk: oh, also: does your board have eMMC? SD cards work with the WIP mainline patches, but oddly enough eMMC does not
<gamiee>
apritzel: is this hw issue?
<apritzel>
gamiee: the eMMC problem? I don't think so, since obviously it works with the BSP code
junari_ has joined #linux-sunxi
junari has quit [Read error: Connection reset by peer]
<gamiee>
aprtizel : yeah I meant eMMC. And oh, good, I didn't knew it works good on BSP.
JohnDoe_71Rus has joined #linux-sunxi
<paulk>
apritzel: yeah looks like the kind of issue hw tracing could help with
<paulk>
apritzel: no eMMC on my board
cnxsoft has quit [Ping timeout: 480 seconds]
<jernej>
paulk: yeah, I also almost bought FTDI and SD card breakout boards, but figured that I always have issues with jumper cables and that dedicated board would cost me almost the same.
theslowc1der has joined #linux-sunxi
<jernej>
paulk: if you manage to trace cpu off and on procedures in BSP, that would be awesome. But note that it probably goes through ARISC core which has separate JTAG.
<jernej>
paulk: do you have H616 OpenOCD script by any chance?
<jernej>
I'm currently stuck at halting issue - core 0 doesn't want to halt for some reason
<paulk>
jernej: good call, the jumper wires are often an issue (and usually the last thing you think about)
theslowc2der has joined #linux-sunxi
<warpme>
jernej : i recall few weeks ago you develop much more reliable ram sizing code. At that time i done +400 tests on h313, h616, h618 and a523. I put this code to my users and to mine surprice one user of h616 device reported regression with this code (report is "box not boots"). User has not uart so we are bing - but he rebuild uboot without those patches and boot becomes ok. By this i checked booting on ALL my 11 aw devices
<warpme>
and....one h616 ddr3 device also stopped booting. reverting ram sizing code makes it booting again. My first Q: may you provide me most recent ram sizing fixes? (maybe i'm using outdated code)?
<paulk>
jernej: yes there was a rework prior to introducing encoding
<paulk>
I think it would be good to get it in before destaging
theslowc2der has quit [Ping timeout: 480 seconds]
<paulk>
note that the encoding topic is moving forward too, we had a meeting at fosdem about it
<paulk>
there's ongoing work on vc8000e and rkvenc
<paulk>
and I am also working on vc8000e
<paulk>
so now we mostly need to discuss uAPI, etc
<jernej>
any specific reason that encoder is needed? decoder is very stable and imo staging warning in dmesg is doing it disservice (scares people away)
<jernej>
other driver were destaged without encoder
<paulk>
so aside of that I'll take the work I did at bootlin and push it to mainline (without encoding at first)
<paulk>
no it's not needed
<paulk>
it's just that the base driver has a bad architecture and design
<paulk>
and I thought it would be good to fix it before destaging
<paulk>
but it should not add/remove any feature
<paulk>
it's just modernization of a crappy driver design
<paulk>
(which I wrote initially, so I'm the one to blame for not getting it right the first time)
<paulk>
so IMO it makes sense to do that before unstaging
<paulk>
but also I've failed at doing this in the last year and I agree the driver cannot stay in staging forever
<jernej>
doing it right the first time is actually not expected, especially when working on new type of driver
<paulk>
yeah I guess
<paulk>
but most of the refactoring work was done (and tested) on my bootlin encoder work branch
<jernej>
yeah, that's my worry. If you have something, then by all means, post the patches. If this is just nice to have in future, I wouldn't hold driver hostage.
<paulk>
essentially it's about splitting one big patch that rewires everything to something sequential that can be reviewed
<paulk>
so it's not ready to be submitted
<paulk>
jernej: yeah maybe it's not worth keeping the driver hostage
<paulk>
I assumed posting the rework would be doable "shortly" when I updated the TODO but it obviously wasn't the case
<jernej>
is encoder talk recorded somewhere?
<paulk>
but also there's often people very reticent (for more or less relevant reasons) about big driver architecture changes so the fact it's in staging makes that a lot more agreeable
<jernej>
warpme: I suspect mctl_core_init() call freezes the system
<warpme>
i added debug line before and after mctl_core_init() call. I see output after call so there is no freeze in mctl_core_init()
wingrime-ww has joined #linux-sunxi
<jernej>
can you add some more outputs? it would be helpful to find out where the issue happens. If it is in mctl_write_pattern() or mctl_check_pattern(), you can lower their for loops to something like 8 or even less. But you have to change both to same number.
warpme has quit []
evgeny_boger has quit [Quit: evgeny_boger]
evgeny_boger has joined #linux-sunxi
hazardchem has quit [Read error: Connection reset by peer]
hazardchem has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
kuba2k2 has quit [Quit: Ping timeout (120 seconds)]