stikonas has quit [Remote host closed the connection]
vagrantc has quit [Quit: leaving]
vstehle has quit [Ping timeout: 244 seconds]
field^Zzz1 has joined #linux-rockchip
anarsoul|2 has quit [Ping timeout: 244 seconds]
field^Mop has quit [Ping timeout: 252 seconds]
kaspter has quit [Ping timeout: 240 seconds]
maz has quit [Ping timeout: 246 seconds]
kaspter has joined #linux-rockchip
vstehle has joined #linux-rockchip
indy has quit [Remote host closed the connection]
s_frit_ has joined #linux-rockchip
s_frit has quit [Ping timeout: 244 seconds]
indy has joined #linux-rockchip
myfreeweb has quit [Ping timeout: 264 seconds]
myfreeweb has joined #linux-rockchip
ldevulder has joined #linux-rockchip
leming has quit [Ping timeout: 245 seconds]
leming has joined #linux-rockchip
matthias_bgg has joined #linux-rockchip
maz has joined #linux-rockchip
vicencb has joined #linux-rockchip
afaerber has joined #linux-rockchip
s_frit_ has quit [Remote host closed the connection]
s_frit has joined #linux-rockchip
LargePrime has joined #linux-rockchip
LargePrime has quit [Quit: Leaving]
LargePrime has joined #linux-rockchip
LargePrime has quit [Remote host closed the connection]
LargePrime has joined #linux-rockchip
LargePrime has quit [Remote host closed the connection]
LargePrime has joined #linux-rockchip
insane^ has joined #linux-rockchip
<insane^>
okay, supernoobish question... since rock64 and rk-3328-cc use the same cpu, do they work with the same kernels?
* insane^
hides
<Esmil>
insane^: yes if the kernel contains all drivers for both boards you can run the same kernel on both boards, but just point it to different devicetree blobs (.dtb files)
<insane^>
okay, lets see if i will have luck ;)
<insane^>
thanks!
<mmind00>
essentially nowadays that _should_ be true for all (modern) socs even across vendors :-D
<insane^>
should!
<insane^>
famous last words
JohnDoe_71Rus has joined #linux-rockchip
<mmind00>
insane^: :-P ... at least my runs on my rockchip-based boardfarm actually do
<Esmil>
do you want to skim through it for extra sanity check or should I just send it out and wait for proper feedback?
<mmind00>
Esmil: just send them out ... i.e. I haven't done that much with spi, so probably won't find much
<Esmil>
alright I'll do that, thanks
<mmind00>
Esmil: will do a test-run on different Rockchip boards anyway (or before you send them out if you prefer)
<mmind00>
Esmil: but that will be somewhere this evening
<Esmil>
mmind00: that would be cool. i'll probably wait then. i've only tested it on my chromebook
<Esmil>
..but I did test it both with and without dma enabled
<mmind00>
Esmil: cool ... ok will try to get that done this evening then
<Esmil>
mmind00: thanks a lot!
<mmind00>
(european evening that is)
<field^Zzz1>
mmind00: old rk3188 board has phy lockups caught by kernel but an ip set link down/up cycle is required toget it going again. how to mitigate this best?
<mmind00>
field^Zzz1: no clue, sorry ... I'm currently running with a usb-ethernet in my farm ... arc-emac is strange but there were patches trying to make it better years back - but again no idea what has become if them
<field^Zzz1>
mmind00: interesting. hm, well, yes, the hw is sending a signal (which is caught in driver): rockchip_emac 10204000.ethernet eth0: restarting stalled EMAC
<field^Zzz1>
mmind00: I'd investigate this. got any ptrs to those patches or something to look for?
<field^Zzz1>
otoh: what usb-eth are you using?
<field^Zzz1>
oh, I just remembered, the usb hub (internal) on this board does not run very stable on 4.18 vanilla. but you haven't got any trouble using usb-eth?
<field^Zzz1>
and I wanted to avoid having eth and ssd on same usb hub for perf reasons
<field^Zzz1>
mmind00: reset high-speed USB device number 5 using dwc <-- w/ and w/o (active external usb hub)
BenG83 has joined #linux-rockchip
anarsoul|2 has joined #linux-rockchip
afaerber has quit [Quit: Leaving]
aalm has quit [Quit: relocating]
BenG83 has quit [Read error: Connection reset by peer]
<hanetzer>
so, about the rk3288 usb controllers; did that issue where stuff doesn't work when its not plugged in at boot get fixed?
afaerber has joined #linux-rockchip
ldevulder has quit [Quit: Leaving]
ldevulder has joined #linux-rockchip
vicencb has quit [Quit: Leaving.]
vicencb has joined #linux-rockchip
aalm has quit [Quit: xyz 2.2]
aalm has joined #linux-rockchip
vicencb has quit [Quit: Leaving.]
<mmind00>
Esmil: rk3288 with cros-ec and spi-flash, rk3328 with a spi-flash, rk3399 with cros-ec all worked well
<mmind00>
Esmil: that is the extend of stuff I have where something is attached to a spi-controller .. looks like my older boards all don't seem to use spi that much
<Esmil>
mmind00: Cool thanks. I'll send the patches out tomorrow then
<Esmil>
btw is the rk3288 the veyron board which actually sets rx-sample-delay-ns?
<field^Zzz1>
mmind00: thx, any ptr better than none :)
<mmind00>
field^Zzz1: in a response it looks like DaveM wasn't that satisfied with the approach though
<Esmil>
*a veyron board. it is set in rk3288-veyron.dtsi
<mmind00>
Esmil: in the history it looks like it comes from the first veyron commit
<Esmil>
yeah, what i meant to ask was if the rk3288 board you tested on a veyron board?
<mmind00>
Esmil: yep ... I tested on rk3288-veyron-pinky
<field^Zzz1>
mmind00: oh, I dimly remember having read this patch. the former tx code was bluntly unusable. and this patch looks just like "hm, where could I put this call w/o too much hassle"
<Esmil>
mmind00: Nice, then it seems I didn't break that functionality then :)
<field^Zzz1>
mmind00: thats probably why it didnt make it in.
<field^Zzz1>
or did it?
<field^Zzz1>
tx code isn't crashing at that point any more.
<field^Zzz1>
*confused
<mmind00>
Esmil: now that you pointed me to this function, I also got up and did a bit more "hand-on" testing ... at least Pinky's keyboard was also still working without spewing any spi error
<mmind00>
s
<Esmil>
mmind00: thanks, but it seems it's only set for the spi flash
<mmind00>
Esmil: too late for me it seems ;-) ... in any case, now I can at least say that the keyboard on the cros-ec still works ;-)
<mmind00>
Esmil: a bit of mtd0-prodding ... size 4mb as expected and reading back the data works and also seems to create a correct image data
<mmind00>
as I can see the bootimage header there
<Esmil>
cool. on my chromebook i get errors if I try to dd if=/dev/mtd0ro of=/tmp/image bs=<something too big like 8M>
<Esmil>
..but that is the same with and without my patches
<mmind00>
Esmil: I just did dd if=/dev/mtd0 of=/root/foobar without anything else
<Esmil>
yeah, but try with bs=8M
<Esmil>
then it might fail
<mmind00>
8M > 4M? ;-)
<Esmil>
Oh, 4M then
<mmind00>
At least my Pinky only has 4M
<Esmil>
actually it just needs to be > 0xffff bytes
<mmind00>
field^Zzz1: my contact with networking drivers is really sparse ;-) ... and until somebody does an arc-emac driver for u-boot I'm somewhat stuck with my usb-ethernet, as I'm relying on netbooting my boardfarm-boards
<mmind00>
field^Zzz1: I know, but not doing ram init without the blob
<Esmil>
mmind00: hmm interesting
<field^Zzz1>
mmind00: :) right
<mmind00>
field^Zzz1: and the driver model between did diverge quite a bit
<field^Zzz1>
mmind00: uboot does ram init w/o blob?
<mmind00>
field^Zzz1: yep
<field^Zzz1>
mmind00: *impressed.
<field^Zzz1>
darn. why not so bb?
<mmind00>
field^Zzz1: probably because the person that did the barebox thing initially, stopped being interested in it
<field^Zzz1>
*sigh task add port uboot rk3188 ram init to barebox.
<mmind00>
field^Zzz1: mainline u-boot for Rockchip is supported by multiple companies (including Rockchip)
<field^Zzz1>
mmind00: sounds reasonable
<field^Zzz1>
so, its on my heap now. stuck on rk3188 ;)
<mmind00>
field^Zzz1: :-D
<mmind00>
field^Zzz1: also you'll have to tackle the bootrom craziness of the rk3188 then :-P
<field^Zzz1>
mmind00: oh, yeah. you tell me..
<mmind00>
field^Zzz1: all in the uboot sources, but took quite a while to understand
<field^Zzz1>
mmind00: hehe, thats why I wandered off to bb :)
<field^Zzz1>
mmind00: seems no excuse any more
<mmind00>
Esmil: aka my Pinky really is an internal development model, where I don't think any protection was ever enabled
<mmind00>
field^Zzz1: hehe ... so you're stuck between the proverbial rock and hard place ... either port emac to uboot or bootrom-madness including ddr-init to barebox
<mmind00>
or just use barebox with blob
<field^Zzz1>
mmind00: well, that blob on bb is kind of appalling me, tbh. so, theres my incentive.
<field^Zzz1>
mmind00: rk3288 does not "feature" this bootrom+blob thing any more?
<field^Zzz1>
mmind00: nand write support is also still lacking. lots of work to do..
<mmind00>
field^Zzz1: bringup is nearly the same for all socs ... aka bootrom loads code from somewhere and expects it to init ddr and stuff
<mmind00>
field^Zzz1: rk3188(and rk3066) just do a roundtrip bootrom -> load 1kb -> execute for possible verification -> back_to_bootrom -> load rest of spl -> execute again -> ddr-init -> back_to_bootrom -> load main loader -> enter main loader
<field^Zzz1>
mmind00: yes, no surprise there. but the rk3188 got this andkrnl/boot/img/xy selection process. this gets me every so often..
<mmind00>
field^Zzz1: na ... that is really just stuff from their binary loader stuff
<mmind00>
so that has nothing to do with the bootrom, but all comes from the actual loader code
<field^Zzz1>
mmind00: oh, really? always thought of it being part of bootrom! omg. one more incentive..
<field^Zzz1>
mmind00: oh, ok. thats so much better outlook! :)