<apritzel>
so at this WARNON, at the end of drivers/clk/sunxi-ng/ccu_common.c:ccu_helper_wait_for_lock(), there is the timeout value, set to 70ms. Can you increase that to say 150ms (150000)? To see the code is just too impatient?
<warpme>
apritzel: on my test boxes i'm getting oops only when i have cpu dvfs enabled. System with gpu dvfs but no cpu dfvs seems to have clean dmesg and is stable. Just enabling cpu dvfs usually gives me hangs. Hangs seems happen only when cpu dvfs walks on multiple cpu opp. Forcing system to stay constant on given cpu opp give me stable operation.
warpme has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
<Lightsword>
apritzel, been experimenting a bit trying to come up with a clean way to do ac200/ac300 phy autodetection within linux, think it would make sense to pass references to both ac200 and ac300 phy nodes and have the emac driver select the right one to use based on the sid eeprom value?
Kirby64 has joined #linux-sunxi
<loki666>
warpme: weird that for you the issue is with cpu dvfs, as the backtrace clearly come from panfrost
<warpme>
loki666 : indeed! this is really surpricing me as well....
colinsane has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<Kirby64>
MasterR3C0RD: so, did a dive into the boot0 headers and created some structures to analyzing them in ImHex. One thing that was not clear to me: which UART port is the correct port? So far I haven't had success in executing the boot0 I've dumped... which maybe is a problem with the boot0 tbh
<Kirby64>
It appears the boot0 is getting overwritten partially, which I guess is not a surprise
<loki666>
apritzel: got my SD card breakout board for UART, you mentioned that you were able to get boot logs on a tablet with a hacked boot0, do you think we could do the same for my a527... I'd like to get the inital voltages of regs
<apritzel>
loki666: actually on my tablet I didn't need to change anything, the stock BSP was outputting on PortF already (which surprised me a bit, tbh)
<loki666>
arf
<apritzel>
loki666: which initial voltages you mean? The one that the BSP boot0 set up? Or the reset values of the PMIC?
<loki666>
the values for DRAM and CPU
<loki666>
it's a 717
<apritzel>
well, there is not much choice then there anyway. What's the DRAM? LPDDR4?
<apritzel>
Lightsword: maybe, but it still sounds involved, tbh. At the end it's for the list and the maintainers to decide how wacky this is, which also depends on how the code looks like
<apritzel>
Lightsword: and if you have split this up already with two PHYs, then I'd say U-Boot just patching in the right "status" value solves this pretty nicely
<Lightsword>
apritzel, that's where things seem to get tricky, I mean it's not just the status we need to patch right? we need to patch the phy selection as well right?
<loki666>
apritzel: not sure... sunxi-fw says 0x7
<Kirby64>
0x7 is DDR4 I believe
<Kirby64>
so, my dumped boot0 from SRAM (at 0x20000) appears to change if I dump it repeatedly... would FEL somehow use SRAM?
<Kirby64>
if I do two back-to-back dumps they don't diff cleanly
<apritzel>
yes, the BROM FEL routine puts its IRQ stack near the beginning of SRAM
<Lightsword>
like I tried having the sid driver use of_changeset to patch the phy status but couldn't get it working due to the phy-handle needing to only point to one phy when building the device tree
<Kirby64>
well, that's unfortunate. So if IRQ stack overrides beginnings of SRAM I can never get a clean boot0 dump
colinsane has quit []
<apritzel>
loki666: so that puts DCDC1 (CPU) at 1.0V, and DCDC3 (DRAM) at 1.2V
<Kirby64>
... I wonder if somehow the modified boot0 I have from a separate image can be grafted onto this one to generate a correct checksum
<loki666>
ok I'll build a u-boot config and dts
<Kirby64>
if boot0 code is largely the same. Which is a big if, I guess
<apritzel>
Kirby64: if you run "sunxi-fw info -v" on any boot0, it gives you the right checksum, so you can patch that in
colinsane has joined #linux-sunxi
<Kirby64>
Yeah, I did that, but patching the checksum does not load unfortunately
<apritzel>
did sunxi-fw confirms afterwards that the checksum is correct now?
<Kirby64>
Yes. And loading it via sunxi-fel SPL did not boot my system
<Kirby64>
not sure if the garbage in the IRQ is messing with it, though
<apritzel>
did you use the "spl" command to load it?
<Kirby64>
yes
<Kirby64>
is that the wrong way to do it?
<apritzel>
no, it's the only way, since that takes care of the IRQ stack (saving it before and restoring it afterwards)
<Kirby64>
Hm. Well that for some reason this is not working currently
<Kirby64>
unclear why
<apritzel>
Kirby64: so remind me: you were hoping for getting the DRAM parameters by snooping into DRAM with boot0 loaded there? Since you don't have any other way of getting boot0, so no update image?
<Kirby64>
Correct. I can't seem to find a public update image anywhere. I was hoping to modify the boot0 to enable UART in the headers so it would spit out my DRAM params
<Kirby64>
I've also attempted to go down the rabbit-hole of MITM'ing their app, but custom SSL libraries seem to make that difficult.
<apritzel>
so what about the other method I think I suggested? Modifying the SPL to skip DRAM init and dumping eMMC(?) sectors instead?
<Kirby64>
That's a possibility. Compile SPL directly to just dump eMMC into UART I guess? That is pretty far outside my wheel-house on where to get started though.
<Kirby64>
I suppose I'd only need to dump the first few sectors too. Enough to grab boot0
<Kirby64>
Then with a clean boot0 I could patch that, then bootstrap DRAM params from that, then get to uboot to dump the rest of eMMC
<Kirby64>
(otherwise, dumping 8GB of eMMC over UART seems... painful)
colinsane1 has joined #linux-sunxi
colinsane has quit [Ping timeout: 480 seconds]
<apritzel>
yes, you basically would just need the sector 16 of the eMMC
<apritzel>
that's all you need for the DRAM parameters
<Kirby64>
I'm pretty sure we think the DRAM params are not just burned into boot0
<Kirby64>
and it's some calibration routine that I need to perform
<Kirby64>
as, I've tried the boot0 dumped DRAM params and they do not work
<apritzel>
Kirby64: the whole boot0 is probably just like 64K, so that's far more than one sector, but not unreasonably big to be dumped via UART
<apritzel>
the code is basically already there: the SPL decides where to load U-Boot from (which would need to be tweaked), then loads sectors from there (into DRAM)
<Kirby64>
Yeah, which is fine. 64k to dump via UART is easy enough. And then getting a clean boot0 I could modify to enable UART, presumably
<Kirby64>
(easy enough, assuming I can figure that out)
<apritzel>
so you need to make the SPL skip the DRAM init, change the decision to force it loading from eMMC, and then make it load from a different sector (sector 16 instead of 80)
<apritzel>
into some SRAM buffer, not DRAM, and then dump it
<apritzel>
board/sunxi/board.c:sunxi_board_init() is the place for the first hack (skip DRAM init), arch/arm/mach-sunxi/board.c:sunxi_get_boot_device() the one for the second (boot source)
<apritzel>
if you do just this (comparably easy), you should see "Trying to boot from MMC2"
<apritzel>
and common/spl/spl_mmc.c is the place for the MMC hacks
<Kirby64>
Hm, alright. I'll start give it a shot then. Thanks for the pointers
<apritzel>
dumping/accessing eMMC via FEL as a problem comes up quite often, so if someone is looking for a nice and useful task ...
<apritzel>
(either by utilising the U-Boot code, or by having a simple MMC stack incl. sunxi driver from scratch)
warpme has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
hazardchem has quit [Remote host closed the connection]
<loki666>
apritzel: bumping timeout to 150ms doesn't change
hazardchem has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
Kirby64 has quit [Ping timeout: 480 seconds]
<apritzel>
loki666: thanks, would have been surprised anyway, but was worth confirming