<Darkarni1m>
Hey all, just looking into unpacking a kernel.img from an already 'unpacked' RK3188 image. Is there anything 'special' done to image, past the addition of KRNL to 'signed' images when built? Or are they standard zImage?
<sjoerd>
mmind00_: fwiw what is wrong in y wireless dts patch is that i got the clockname (as used by pwrseq) wrong.. Unfortunately correcting it + running with your patch to wait for orphan clocks as needed seems to have made things less reliable on wamr reboots
<sjoerd>
which is.. surprising
afaerber has quit [Quit: Ex-Chat]
<mmind00_>
sjoerd: what is "less reliable"? ... I now see the wrong clock-name (xin32k instead of ext_clock), but the hym8563 shouldn't have so much to do with reboots?
<mmind00_>
there was an issue with the clock-control being reversed in the driver, but I fixed that some kernel releases ago if I remember correctly
<mmind00_>
sjoerd: interesting question: does the pwrseq turn off the clock on reboots/power-downs? Maybe the starting system needs it to run
<sjoerd>
no it only turns the clock on
<sjoerd>
and twiddles the reset gpio
<sjoerd>
mmind00_: less reliably is on more reboots i'm getting the brcmfmac driver bialing out with brcmf_sdio_firmware_callback: dongle is not responding
<sjoerd>
this is on a 4.3 kernel though (customer project), 4.4 with the wrong clockname worked reliably
<sjoerd>
so still digging what the hell might be going on ;)
<sjoerd>
Right, daughter is calling, ttyl :)
<sjoerd>
(ofcoures this could all just be timing related for extar fun)
<mmind00_>
but I'd assume in 4.3 it should already be present
cnxsoft has quit [Remote host closed the connection]
JohnDoe_71Rus has joined #linux-rockchip
afaerber has joined #linux-rockchip
amstan has quit [Ping timeout: 240 seconds]
<rperier>
a "Signed-off-by" Linus itself... that's not so common :)
<rperier>
hi all, btw
<mmind00_>
rperier: about what?
<rperier>
the commit that you have shown to sjoerd
<mmind00_>
rperier: thats only because Andrew Morton doesn't use git or so (and sends his patches as some sort of attachement-bomb to Linus, who in turns then has to apply all of them himself)
<rperier>
I see
<sjoerd>
mmind00_: let me double-check
<sjoerd>
mmind00_: yup already present
<sjoerd>
mmind00_: I'd epxect it to not work at all if that was still an issue tbh
<sjoerd>
What i expect is that the device isn't entirely properly reset or somesuch
<mmind00_>
sjoerd: the simple pwrseq does not do any delays on its own when handling the rest, so it seems to entirely depend on the mmc-core
mmind00_ is now known as mmind00
Zmey has joined #linux-rockchip
<sjoerd>
mmind00: I checked, mmc core does quite long delays
<sjoerd>
iirc 10ms or so between the stages
<sjoerd>
which is far more then the datasheet suggest the minimum is
wadim_ has quit [Remote host closed the connection]
premoboss has quit [Quit: Sto andando via]
<sjoerd>
hmm "VBAT Should be up before or at the same time as VDDIO", VDDIO should NOT be presesnt first or be hld high before VBAT is high"
<sjoerd>
time to check that i guess :)
Zmey has quit [Quit: Page closed]
<sjoerd>
hrm, those are provided via voltage configured turned on by vcc_io, and fed by vcc_sys so should go on at the same time
amstan has joined #linux-rockchip
amstan has joined #linux-rockchip
amstan has quit [Changing host]
maz_ has quit [Ping timeout: 264 seconds]
maz_ has joined #linux-rockchip
ganbold has quit [Quit: This computer has gone to sleep]
ganbold has joined #linux-rockchip
ganbold has quit [Remote host closed the connection]
ganbold has joined #linux-rockchip
GriefNorth has joined #linux-rockchip
matthias_bgg has quit [Read error: Connection reset by peer]
gb_master has quit [Remote host closed the connection]
gb_master has joined #linux-rockchip
akaizen has joined #linux-rockchip
Darkarni1m has quit [Quit: leaving]
<edolnx>
I'm going to go out on a limb and guess that getting an ERR in the first four lines of output from a geekbox upon powerup means the HW is toast?
c0d3z3r0 has quit [Ping timeout: 240 seconds]
akaizen has quit [Remote host closed the connection]
<sjoerd>
mmind00: yeah looks like it's really atiming issue, hacking things up by blacklisting the brcmfmac module and loading it ~5 seconds after boot seems to work fine (or at least 17 succeeded reboots now, while previously i couldn't get more then ~10).. fun fun
premoboss has joined #linux-rockchip
gb_master_ has joined #linux-rockchip
gb_master has quit [Read error: Connection reset by peer]
gb_master_ has quit [Remote host closed the connection]
mrjay has joined #linux-rockchip
<mrjay>
sjoerd: try adding "card-detect-delay = <100000>;" to sdio node
<sjoerd>
mrjay: the card is always detected though :)
<mrjay>
sjoerd: if it's timing issue it might help
<sjoerd>
but yesthat could do it
<sjoerd>
mrjay: oh actually card-detect-delay is the delay after an insert, but this is a non-removable sdio card
<sjoerd>
so i don't thinkthat would actuallydo anything
<sjoerd>
(note timing could also be where it gets probed compared to other drivers, but i'm pretty sure that's not the problemhere)
<sjoerd>
More experimenting tomorrow ;)
<mrjay>
sjoerd: nevermind then
<sjoerd>
mrjay: thanks for the suggestion though :)
<mrjay>
sjoerd: np
<mrjay>
sjoerd: in my dts for wifi i also have "broken-cd;" ... also broadcom chipset
<sjoerd>
mrjay: you probalby want ot use non-removable
<sjoerd>
broken-cd will make it poll for the card, which isn't really neededif it's always there ;)