psydroid has quit [Read error: Connection reset by peer]
psydroid has joined #linux-rockchip
stikonas_ has quit [Quit: Konversation terminated!]
stikonas_ has joined #linux-rockchip
stikonas_ has quit [Remote host closed the connection]
warpme has joined #linux-rockchip
warpme has quit [Ping timeout: 272 seconds]
warpme has joined #linux-rockchip
warpme has quit [Ping timeout: 245 seconds]
warpme has joined #linux-rockchip
warpme has quit [Ping timeout: 252 seconds]
<naoki>
I sent "fix" v2 patchset for ROCK 5C. I need to write cover letter for "common .dtsi" patchset...
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 264 seconds]
kevery1 is now known as kevery
warpme has joined #linux-rockchip
warpme has quit [Ping timeout: 244 seconds]
warpme has joined #linux-rockchip
warpme has quit [Ping timeout: 252 seconds]
warpme has joined #linux-rockchip
warpme has quit [Ping timeout: 252 seconds]
Daanct12 has quit [Ping timeout: 252 seconds]
warpme has joined #linux-rockchip
warpme has quit [Ping timeout: 272 seconds]
warpme has joined #linux-rockchip
Daanct12 has joined #linux-rockchip
warpme has quit [Ping timeout: 276 seconds]
hexdump0815 has quit [Ping timeout: 248 seconds]
<naoki>
where is patch 0/3 and 2/3 lol
hexdump0815 has joined #linux-rockchip
warpme has joined #linux-rockchip
Daanct12 has quit [Quit: WeeChat 4.4.3]
warpme has quit [Ping timeout: 252 seconds]
<naoki>
oh okay
warpme has joined #linux-rockchip
warpme has quit [Ping timeout: 255 seconds]
warpme has joined #linux-rockchip
Daanct12 has joined #linux-rockchip
warpme has quit [Ping timeout: 252 seconds]
warpme has joined #linux-rockchip
warpme has quit [Ping timeout: 252 seconds]
warpme has joined #linux-rockchip
warpme has quit [Ping timeout: 260 seconds]
warpme has joined #linux-rockchip
warpme has quit [Ping timeout: 264 seconds]
warpme has joined #linux-rockchip
warpme has quit [Ping timeout: 245 seconds]
warpme has joined #linux-rockchip
warpme has quit [Ping timeout: 252 seconds]
warpme has joined #linux-rockchip
warpme has quit [Ping timeout: 252 seconds]
warpme has joined #linux-rockchip
ldevulder has joined #linux-rockchip
System_Error has quit [Ping timeout: 260 seconds]
System_Error has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
raster has joined #linux-rockchip
Stat_headcrabbed has joined #linux-rockchip
warpme has joined #linux-rockchip
franoosh has joined #linux-rockchip
System_Error has quit [Remote host closed the connection]
franoosh has quit [Changing host]
franoosh has joined #linux-rockchip
<qschulz>
sre: oh so DFU in SPL for RK3588 actually isn't working upstream yet? Is that what you meant?
<qschulz>
Kwiboo: what exactly did you do to make the second try much faster than the initial test?
System_Error has joined #linux-rockchip
<Kwiboo>
qschulz: first try was to use rkdevtool on windows -> super slow around 30 seconds to upload, second try was to use rockusb/rkdeveloptool on linux -> fast, around 1 second
<qschulz>
Kwiboo: ah I thought rkdevtool = rkdeveloptool :)
<Kwiboo>
please feel free to clean something like that up and send usable patches, I just wanted to see if it could be possible :-)
<Kwiboo>
noticed that SPL_RAM_DEVICE and SPL_LOAD_FIT_ADDRESS the other week and tought it somehow could be used to load fit from ram for quick testing, if using 0x472 upload could work with large blobs
<Kwiboo>
should also avoid the need to have usb gadget support in spl
warpme has quit [Read error: Connection reset by peer]
warpme_ has joined #linux-rockchip
<qschulz>
mmmmmmmmmmm I vaguely remember that the BootROM tries multiple offsets in eMMC/SD card before trying another medium. 1) is that true? 2) does anyone know which offsets?
<qschulz>
ah nvm
<qschulz>
I thought this could be a nice way to do A/B updates with the bootloader on Rockchip
<qschulz>
but it would necessarily start with the A (or B) that is in the earliest block checked by the BootROM
<qschulz>
so we would still have an issue there
<qschulz>
I guess the only option would be a very small loader that will never be changed that just reads something to know which offset to read from next
<qschulz>
But I think this is essentially what Simon wanted to do with VBE
<qschulz>
s/wanted/wants/
<Kwiboo>
qschulz: I think barebox take advantage the 5 offsets bootrom test for some A/B update/fallback, there is some comment about that in the code
<qschulz>
aaaaaah, they duplicate the currently active one in the inactive slot (in later blocks)
<qschulz>
once that's done, they copy the new one on the currently active slot (in the earlier blocks)
<qschulz>
if the update is botched, the checksum will fail and it'll try later blocks
<qschulz>
actually it doesn't need to be in any specific block order, we just need to know which slot was used for last boot
<qschulz>
oof, that would be an issue for updating U-Boot proper since we load from a specific address
<qschulz>
so we would need either a mechanism to detect which block was used to load TPL+SPL from and add that to the expected load address (or pass the address of a second U-Boot proper)
warpme_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
naoki has quit [Quit: naoki]
raster has joined #linux-rockchip
<a3f>
qschulz, this info is in IRAM, so you can get ahold of it in EL3 before BL31 (TF-A) installation
<a3f>
barebox uses it to know what slots are inactive and can be written
<Kwiboo>
and if rockusb download-boot command could be extended to take two paths and a rc4-enable/disable flag, you could even avoid the need to create a "loader" image
<qschulz>
Kwiboo: well, if we go this far already, one can simply extend rockusb download-boot to take tpl as first input file, spl as second and proper as third
<qschulz>
and then we don't even need to generate the image with binman
warpme has joined #linux-rockchip
<Kwiboo>
could work, but then you need to know at what address SPL will look for FIT, so probably easier to have the second spl+fit combo created by binman
franoosh has quit [Ping timeout: 252 seconds]
warpme has quit [Client Quit]
<Kwiboo>
the loader image also contain information about how long to sleep between/after each of the two 0x471/0x472 commands, could be possible to just have a decent default and a mapping table for rc4 flag and sleep delay for each usb vid/pid combo
<Kwiboo>
but we can probably avoid generating an idbloader image as I did in my example commit, only the inner u-boot-spl-with-fit.bin is really needed
<Kwiboo>
qschulz: regarding a/b slot, to my knowledge the checksum feature for unsigned idbloader is new in rk35xx, and older socs possibly only validate for signed idbloader
<Kwiboo>
only the idbheader has a checksum for v1 format, if I am not mistaken, and not the data
warpme has joined #linux-rockchip
warpme has quit [Client Quit]
ungeskriptet has quit [Killed (iridium.libera.chat (Nickname regained by services))]