<naoki>
mmind00: is "arm64: dts: rockchip: restructure reglators for Radxa ROCK 5A" still too big?
<qschulz>
naoki: rule of thumb is: if you need to list stuff you do in a commit, you need to split the commit
<mmind00>
naoki: as qschulz said ... especially when you have a bullet-list in your commit :-) ... and looking at that commit, splitting things according to these bullet points makes perfect sense
<naoki>
hmmmm....
<naoki>
it needs consistent
<naoki>
I don't want to make non-working state in a commit
<naoki>
^^it needs to be
<naoki>
I'll try to split more, but probably some of problems are my English skill ;)
<qschulz>
there are times when you need to add useless code you're going to remove in the next commit to keep everything in a working state
<naoki>
oh...
<qschulz>
naoki: fixing, reworking/refactoring and adding new features to existing code is much more difficult with regards to splitting commits than adding a new driver/board support
<qschulz>
because every commit needs to tackle only one thing at a time, and be justified
<naoki>
ah, I got good idea. "since rock 5c is slightly modified version of rock 5a, rock-5c.dts can be used for rock-5a. let's discard rock-5a.dts and make common .dtsi from rock-5c.dts"
<naoki>
"diff -u rk3588s-rock-5[ac].dts" is really very small
<naoki>
I really feel my effort is waste of time...
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ldevulder has joined #linux-rockchip
<naoki>
is it acceptable "discard unmaintained rock-5a.dts and make common .dtsi from maintained rock-5c.dts"? I'm serious
<naoki>
....oh? I thought power led is not connected to gpio on rock 5a, but it seems...
<naoki>
... LED connection are same... current rock-5a.dts is really really...
raster has quit [Quit: Gettin' stinky!]
<naoki>
I'm serious. use rock-5c.dts as a base for both rock-5a and rock-5c, this is best way
warpme has joined #linux-rockchip
<dsimic>
naoki: well, you aren't discarding it, you're converting it to the common dtsi ancestor
raster has joined #linux-rockchip
<naoki>
yes
<dsimic>
also, including a .dts file is frowned upon
<naoki>
update rock-5c.dts to make common .dtsi from it
<dsimic>
or rock-5a.dts?
raster has quit [Client Quit]
<naoki>
split rock-5c into rock-5.dtsi and rock-5c.dts
<naoki>
update(discard almost entire unmaintained) rock-5a.dts to use rock-5.dtsi
<naoki>
it's simple, clear, and easy
<naoki>
it's better than making ~20 patches to up-to-date rock-5a.dts
<dsimic>
makes sense to me, so far :)
<mriesch>
naoki: so rk3588s-rock-5.dtsi for A and C, and rk3588-rock-5.dtsi for B and B+?
<naoki>
for former, yes. for later, not sure ;)
<dsimic>
mriesch's proposal makes sense to me
<mriesch>
i am pretty sure that there should be a common dtsi for b and b+, but not sure what the name is
<mriesch>
naoki: any insights how 5b and 5t are related?
<naoki>
5t is 5b++
<dsimic>
gah, good question :)
<naoki>
but I'm not sure how compatible they are at dts POV
<mriesch>
5t = (5b+)+ = 5b++ ok that's neat ;-)
<mmind00>
Kwiboo: do you remember where the 0xc00 offset for the rk3588-otp in u-boot comes from? Everywhere else that no_secure_offset (vendor-u-boot, mainline-kernel) seems to be 0x300 for the rk3588?
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Kwiboo>
mmind00: hum, good question, possible some offset calculation that differs, u8 vs u32 or similar
<Kwiboo>
0x300 x 4 = 0xc00 so probably just that, offset in u-boot is in bytes and kernel/vendor in sizeof(u32)
<mmind00>
Kwiboo: thanks a lot ... that sounds like a sensible explanation :-)
<mmind00>
I was glancing at the code, but probably not deep enough to notice those differences
<naoki>
I'll review and test tomorrow... it's late here, good night
* qschulz
waves at naoki
alikates has quit [Ping timeout: 264 seconds]
alikates has joined #linux-rockchip
naoki has quit [Quit: naoki]
sL1pKn07 has quit [Ping timeout: 245 seconds]
sL1pKn07 has joined #linux-rockchip
dsimic has quit [Ping timeout: 248 seconds]
dsimic has joined #linux-rockchip
<qschulz>
Kwiboo: sre: I believe some of you/your colleagues USB boot Rockchip devices? labgrid is trying to fix a few things with how the binaries are USB loaded and I don't want to say to much non-sense
<qschulz>
so would appreciate some feedback if you can
<qschulz>
basically, IIUC, USB-loaded barebox can actually reach normal CLI and boot the kernel
<qschulz>
I don't think that's the case for USB-loaded U-Boot?
<qschulz>
I think we only have TPL+SPL generated with boot_merger blob from Rockchip?
<Kwiboo>
qschulz: I tried to take a look if it could be possible to ramboot with just the 471/472 usb commands, and I think it theoretically should be possible, if I understand correctly, first command will just send ddr blob/tpl and wait on dram init to complete, second cmd will send loader to dram and run it
<Kwiboo>
so it should probably be possible to just send a bigger second package with spl+fit, and use spl rambooot to load fit from dram
<qschulz>
Kwiboo: SPL would need to know where the fit is stored on the DRAM though
<qschulz>
and also, how would it know if it should ramboot the fit or do DFU/fastboot/rockusb?
<qschulz>
I guess we could check if there is **some** fit in DRAM and ramboot it if it's there otherwise start USB gadget?
<qschulz>
(thinking out loud now)
<Kwiboo>
I think bootrom set boot source id to "usb", so it may be possible to use that to try BOOT_DEVICE_RAM
<qschulz>
but that would be a completely different setup than on Barebox for which labgrid people claim they can use the exact same binary and upload it via USB or flash it on eMMC, "it just works"
<qschulz>
so I'm trying to figure out if only using `rkdeveloptool db` for one binary would allow us to reach proepr's CLI or not
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<a3f>
hi, I am the labgrid person claiming. I was talking about RK3568.
<Kwiboo>
qschulz: my main issue with rkdeveloptool db is that the file needs to be in boot_merger format, something that could/should be avoided
<qschulz>
Kwiboo: if we avoid it, then we have to write our own format no?
<qschulz>
or how exactly do you suggest we interact with the BootROM?
<qschulz>
just passing N files I guess? N files for 0x471 and M files for 0x472?
<Kwiboo>
qschulz: no, to my knowledge it is only an intermediate format used by the rkvdevtool, and possible also the rkloader blobs
<Kwiboo>
a3f: cool, looks like that tool is doing bare minimum to upload code, however its input is still in a idbloader format and only support the idblock v2 header
<qschulz>
Kwiboo: yeah, Barebox only supports RK356x and RK3588 at the moment
<qschulz>
a3f said they were working/thinking of working on RK3399/PX30 support so that would eventually come
<a3f>
First I need to wrap my head around this boot_merger stuff. On RK356x it just works, but apparently for older Rockchip SoCs this needs more work (first time hearing of boot_merger today)
<Kwiboo>
and I guess barebox only have one stage after ddr init, in u-boot we have two stages, spl + proper
<qschulz>
yeah we could have a size issue depending on how big the Barebox binary is
<qschulz>
because U-Boot is quite chonky already
<a3f>
Kwiboo, barebox has two stages, but they are loaded concatenated into DRAM, so no size limitation. barebox prebootloader decompresses barebox proper to end of RAM and executes it
<qschulz>
a3f: have you encountered any size limitation by the BootROM on RK3568?
<a3f>
qschulz, nope
<qschulz>
a3f: on U-Boot we currently have 3 stages on Rockchip (some SoCs and some boards still 2 though)
<qschulz>
there are talks of having a 4th one (and maybe even a 5th one IIUC :) )
<qschulz>
a3f: ok that's good news then
<Kwiboo>
a3f: ahh, cool, so basically what I wanted to look into for u-boot for ramboot use, have spl+fit concatenated into DRAM, and then add some configuration so that SPL can load next stage from DRAM instead of storage media
<a3f>
Kwiboo, that sounds good. That's how barebox is already starting up.
<Kwiboo>
main issue would be that u-boot can be large, and we may overlap load addresses if we place fit directly after SPL
<a3f>
just move U-Boot proper to end of RAM?
<a3f>
You don't have to execute it in-place
<Kwiboo>
can we control where 0x472 load data, or it is still at 0x0 ?
<a3f>
you'd have to check the barebox code to be sure, but my understanding it barebox PBL (prebootloader) run at 0x0, then relocates to 0xa00000 something (after TF-A area), then running from there it decompresses barebox proper to end of DRAM
<a3f>
and jumps there
<Kwiboo>
yeah, could relocate data, but was hoping to avoid that, if there is no size restriction we could be lazy and just make a hole for where TF-A would be loaded, at 0x40000 - 0x100000 or similar
<qschulz>
the TPL already puts a hole there IIRC
<qschulz>
at least that's what the ATAGS code we added for RK35xx should do
<a3f>
ye, the relocation is a bit ugly. barebox does it even before enabling MMU, which is not great, but it doesn't seem to be that slow
<qschulz>
Kwiboo: IIRC for Rockchip TF-A is reserving the first 2MB in DRAM
<Kwiboo>
qschulz: mostly thinking in the blob that would be loaded by maskrom, I think we could use binman to create a u-boot-rockchip-ramboot.bin or similar that just wrap the mkimage <tpl> and (<spl>+hole+<fit>) instead of normal .bin-file: (mkimage <tpl> and <spl>) + hole + FIT
<qschulz>
then you need to save some space for OP-TEE I guess?
<qschulz>
Kwiboo: that was exactly my thinking as well
<a3f>
coincidentally, I just reworked that part of the barebox pbl code last week. barebox will now check if BL32 has an OP-TEE header and use that to know what memory to reserve
<a3f>
if there is no OP-TEE header it defaults the load addresses of the rkbin blob
<Kwiboo>
qschulz: with ramboot.bin file, rk-usb-loader.c could be used to boot into cli with u-boot, we still need to add missing parts in SPL, and take a look at some of the load addresses, to avoid other overlaps
<a3f>
or maybe just use a bootloader that is not out to get ya ;-)
<qschulz>
Kwiboo: I would personally see big benefit in supporting boot_merger format
<qschulz>
much easier to get people to use the new binary
<qschulz>
if they don't have to change their tools
<qschulz>
(we could generate multiple ones though, that wouldn't be an issue)
<qschulz>
a3f: nanananananananananana i'm not hearing anything
<Kwiboo>
qschulz: hehe, yeah, guess adding a boot merger format to mkimage would be nice, would at least reduce the need for a boot_merger blob
raster has joined #linux-rockchip
warpme has joined #linux-rockchip
raster has quit [Quit: Gettin' stinky!]
serdarth has quit [Ping timeout: 245 seconds]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #linux-rockchip
warpme has quit [Ping timeout: 255 seconds]
<Kwiboo>
qschulz: was able to hack togheter a proof of concept: https://gist.github.com/Kwiboo/68dfca002add6bff53613ec2262820b4 will push a commit later, used boot_merger and rkdevtool, with a ~2mb big loader bin, it took long time to load and start spl
warpme has joined #linux-rockchip
System_Error has quit [Remote host closed the connection]
warpme has quit [Ping timeout: 252 seconds]
System_Error has joined #linux-rockchip
stikonas_ has joined #linux-rockchip
ldevulder has quit [Quit: Leaving]
warpme has joined #linux-rockchip
vagrantc has joined #linux-rockchip
warpme has quit [Ping timeout: 252 seconds]
warpme has joined #linux-rockchip
warpme has quit [Ping timeout: 252 seconds]
<sre>
qschulz: FWIW you already found the bits Collabora has regarding USB gadget support in RK3588 U-Boot.
<sre>
Upstreaming that is blocked by the requirement to resync the DWC3 driver with latest Linux kernel code
<sre>
We currently do not have any plans to proceed with that
Stat_headcrabbed has quit [Remote host closed the connection]