ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 260 seconds]
kevery1 is now known as kevery
hanetzer has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 272 seconds]
kevery1 is now known as kevery
kevery has quit [Read error: Connection reset by peer]
kevery has joined #linux-rockchip
stikonas has quit [Ping timeout: 246 seconds]
Daanct12 has quit [Remote host closed the connection]
lorenzb has quit [Quit: Gateway shutdown]
lorenzb has joined #linux-rockchip
matthias_bgg has quit [Ping timeout: 272 seconds]
matthias_bgg has joined #linux-rockchip
kevery has quit [Remote host closed the connection]
kevery1 has joined #linux-rockchip
kevery1 is now known as kevery
lurchi_ has joined #linux-rockchip
lurchi__ has quit [Ping timeout: 246 seconds]
lurchi_ has quit [Ping timeout: 260 seconds]
lurchi_ has joined #linux-rockchip
lurchi_ is now known as lurchi__
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 252 seconds]
kevery1 is now known as kevery
System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
mweigand has joined #linux-rockchip
kevery has quit [Remote host closed the connection]
kevery has joined #linux-rockchip
superherointj has joined #linux-rockchip
mweigand has quit [Ping timeout: 252 seconds]
mweigand has joined #linux-rockchip
<pinchartl>
mmind00: would you have looked at mainline u-boot (and TF-A) for rk3568 by any chance ? :-)
Rathann has joined #linux-rockchip
superherointj has quit [Quit: Leaving]
<mmind00>
pinchartl: not really ... I remember there was a TF-A submission for rk356x somewhat recently ... but on my rk356x board the bootloader is still some hack with binary TF-A and hacked up u-boot
<pinchartl>
mainline u-boot or downstream u-boot ?
<pinchartl>
it's really painful to use the rock 3a at the moment because of all this. upstreaming u-boot support isn't even our goal, we got hit by lack of functioning ethernet in the downstream version and then hoped it wouldn't be too hard to use upstream as rk3568 support is there already
<naoki>
I think mainline rock 3/4 uses mmc0 for uSD, mmc1 for eMMC...
<naoki>
ah obbardc ?
<pinchartl>
how u-boot handles boot device selection was also something we struggled with
<pinchartl>
going from the values in the chosen node to one of the BOOT_DEVICE_* values, and then back to the real device
<pinchartl>
you end up having SPL printing "Trying to boot from MMC2" when the device tree has no mmc2
<pinchartl>
it's really confusing
<naoki>
I think, about numbering, u-boot uses mmc0 for eMMC, mmc1 for uSD
<naoki>
but boot order(env description) is mmc1 then mmc0 ;)
<pinchartl>
we didn't get as far as u-boot, we were stuck with SPL :-)
<naoki>
:D
<naoki>
I totally agree "really confusing"
<naoki>
there are several "boot order/device numbering"... in boot rom, in spl, in u-boot, in u-boot env, in kernel
mweigand has joined #linux-rockchip
mweigand has quit [Ping timeout: 264 seconds]
<mriesch>
pinchartl: just wondering, would barebox be an option for you?
kevery1 has joined #linux-rockchip
<mriesch>
because barebox works quite well on the rock3a
kevery has quit [Ping timeout: 256 seconds]
kevery1 is now known as kevery
<pinchartl>
mriesch: "possibly" :-)
<pinchartl>
I haven't used it, so I have no idea if it can handle our boot flow
<pinchartl>
I assume it supports dhcp and tftp and boot scripts
<pinchartl>
but there could be subtle (or not so subtle) differences with u-boot there
<naoki>
one more rk356x board :D
<mriesch>
pinchartl: well if you aren't afraid of something new... :-)
<mriesch>
if you give it a shot, feel free to ping me in case of troubles.
<mriesch>
personally i find the blspec boot quite nice, which does not require tftp and complicated boot scripts. you just point to a rootfs via nfs, for instance
<pinchartl>
mriesch: I like boot scripts because it lets me control the full boot process from the host side
<pinchartl>
all my boards are configured with bootcmd="dhcp && source"
<pinchartl>
and that's it
<mriesch>
ah ok. i am usually happy with which kernel + which devicetree + which boot cmd line should be used, this can be set in a blspec config file in the rootfs
<macromorgan>
naoki: After you build your image, modify the u-boot.its file with the correct ordering of A-TF modules, then run `mkimage -f u-boot.its u-boot.itb`
<macromorgan>
basically the order of A-TF images matters
<pinchartl>
oh ?
<pinchartl>
why does it matter ?
<pinchartl>
I thought u-boot would simply load the different sections of the ELF file, and that the order didn't matter
<macromorgan>
you can get the correct order from building your own image from the BSP sources. For reference, here is what I got from the most recent bl31: https://paste.debian.net/1266965/
<macromorgan>
I have no idea why it matters, but if you don't do that step (reordering the modules) it won't boot
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 246 seconds]
kevery1 is now known as kevery
<macromorgan>
I'm slowly in the process of getting my (by which I mean about half mine and about half pgwipeout's wonderful work) patches mainlined for the RGxx3 series from Anbernic which uses the rk3566 SoC.
<CounterPillow>
afaik the tf-a rockchip submitted lacks SCMI so is useless for booting Linux :(
<pinchartl>
macromorgan: thanks. I'm still *really* puzzled as to why that would matter. it should make no difference really
<macromorgan>
this is for using the binary one... you are correct I get tons of weird errors booting the open source version currently (because among other things scmi doesn't work like you say)
<naoki>
macromorgan: thanks!
<macromorgan>
has anyone else (working on mainline) experienced suspend issues? I can't get video output to work after resuming from suspend... this is output on either HDMI or DSI.
<macromorgan>
I'm not even sure how to troubleshoot, but it's the last hurdle for the Anbernic devices on mainline...
<CounterPillow>
AFAIK we're having issues like that on the PineTab2, but haven't started looking into it yet
Rathann has quit [Quit: Leaving]
<robmur01>
I'd usually suspect clocks/power domains not all coming back in the same state they were in before
<pinchartl>
try to diff the clock tree summary from debugfs before and after resume ?
<CounterPillow>
I can't even tell where in the vop2 driver resuming is handled