<marex>
Clamor: I didnt do anything, busy with other stuff
<sjg1>
devarsh: Re the video series, you could ping the video maintainer. I am not sure if he is on irc but he normally responds to email
<Clamor>
sjg1: iirc he is not in irc
<Clamor>
I may not be correct though
gsz has quit [Quit: leaving]
<marex>
agust ? nope
prabhakarlad has quit [Quit: Client closed]
Clamor has quit [Ping timeout: 256 seconds]
Clamor has joined #u-boot
norton has joined #u-boot
<calebccff>
howdy folks, I've been working on SystemReady/IR compliance for some boards and I've been running into an issue with the Base System Architecture (BSA) test suite
<calebccff>
Basically, the BSA tests validate some parts of the hardware including the GICv3 interrupt controller. The GICv3 tests immediately trigger an abort, and the abort handler then triggers another abort, and it just goes on until I kill the power
Clamor has quit [Ping timeout: 246 seconds]
<calebccff>
What confuses me is that from what I can tell, this test suite is expected to work on U-Boot, even though it doesn't handle interrupts?
Clamor has joined #u-boot
<calebccff>
I guess they're usually masked and the test suite just checks that there is an IRQ pending? There are some quirks in the GIC on Qualcomm platforms so perhaps it's running into something there
Clamor has quit [Read error: Connection reset by peer]
Clamor has joined #u-boot
<Tartarus>
Been a while since I ran the IR test suite (and had it fail on something else platform specific) but, yeah, start digging in the qcom stuff :|
<Tartarus>
I -think- something like rk3399 is likely going to still pass and be something to compare with
<apalos>
rk3399 will pass, basically any board that adds capsule updates will pass.
<apalos>
calebccff: ping me later, I think we had something similar when certyfying the stmp32mp1 arm7 boards
<apalos>
and we ended up disabling that test, but I'll have to dig into my email history
Clamor has quit [Ping timeout: 252 seconds]
thopiekar has quit [Ping timeout: 256 seconds]
thopiekar has joined #u-boot
<calebccff>
apalos: sure, thanks. For now I'm just disabling it but it would be nice to have.
<calebccff>
fwiw, of the 11341 tests that I'm currently able to run, I have 16 dropped and 17 failures, so we're getting there...
<devarsh>
Thanks sjg1 will ping Anatolij Gustschin, if my understanding is correct he is the video custodian
Clamor has joined #u-boot
<Tartarus>
tbh, anything aarch64 should pass, barring SoC specific issues :)
sszy has joined #u-boot
<calebccff>
the failures are mostly just configuration issues afaict yeah
<apalos>
Tartarus: boards have to define a capsule update mechanism, which boils down to people adding the proper dfu string to update the firmware
<apalos>
but that's really easy to plug in, ask calebccff he did it for the qcom platfors
<apalos>
it's basically 10-20 lines of an array
<Tartarus>
When did that happen? Or is that just not part of the automated testsuite?
<calebccff>
not upstream yet
<calebccff>
blocked on all this DTS stuff and the other ~80 Qualcomm platform support patches I'm carrying
<Tartarus>
calebccff: I don't think we need to block all of the qcom stuff on the DT work Sumit is doing, btw
<calebccff>
no, I'm trying to get myself better motivated to send some other patches, just a lot of inter-dependencies and my git-fu not really being up to snuff...
<Tartarus>
k
Stat_headcrabed has joined #u-boot
<apalos>
calebccff: the efi capsules are straightforward tbh
rvalue has quit [Ping timeout: 245 seconds]
rvalue has joined #u-boot
<marex>
is there really no rk3588 TRM available anywhere ?
<marex>
gotta say, this is one small + for NXP, they just put the datasheet on their website
<LeSpocky>
trying to get CONFIG_TOOLS_LIBCRYPTO=n working again, it is still broken
Stat_headcrabed has quit [Quit: Stat_headcrabed]
thopiekar has quit [Ping timeout: 276 seconds]
<marex>
LeSpocky: still, or again ?
<LeSpocky>
since u-boot 2022.04, it worked with 2022.01 IIRC
thopiekar has joined #u-boot
<LeSpocky>
maybe even longer
<LeSpocky>
there were several patches sent over the last few years, none got applied *sigh*
<marex>
Tartarus: ^
qqq has quit [Ping timeout: 276 seconds]
<LeSpocky>
I just collect links to the previous discussions and throw it into an answer on the mailinglist, where someone had the same problem … few weeks ago, adding marex and Tartarus to Cc: if you don't mind?
<LeSpocky>
and then I'm going to test the patches on this, I was not aware of previously
<diederik>
marex: try asking on #linux-rockchip for rk3588 TRM?
qqq has joined #u-boot
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
goliath has quit [Quit: SIGSEGV]
Mis012- has quit [Ping timeout: 240 seconds]
Stat_headcrabed has joined #u-boot
ldevulder has quit [Quit: Leaving]
Mis012 has joined #u-boot
Clamor has quit [Read error: Connection reset by peer]
monstr has quit [Remote host closed the connection]
<Tartarus>
LeSpocky: If you end up making a new patch, please just make sure to not cc Pali, he won't appreciate it and it will lead to another round of flame emails :(
<rfs613>
anyone know of a way to combine bmaptool (for writing sparse images efficiently) via u-boot's DFU command, to update an MMC card on the target board?
<rfs613>
the stock dfu-util only supporst writing entire files, it seems. Although the dfu protocol seems to be block-oriented, so in theory it might be possible?
<cambrian_invader>
you can use android sparse images; those are typically used with fastboot but you could probably add them to dfu
<cambrian_invader>
there's already a standalone command to write sparse images without fastboot
<rfs613>
cambrian_invader: hadn't considered fastboot, let me go read up on the android sparse images...
<rfs613>
it seems that fastboot downloads (to RAM) and then writes to flash/mmc (unpackign sparse image as it goes). Might not work for me because SD image could be bigger than RAM.
<cambrian_invader>
there'
<cambrian_invader>
s an internal buffer
<cambrian_invader>
FASTBOOT_BUF_*
Stat_headcrabed has quit [Quit: Stat_headcrabed]
prabhakarlad has quit [Quit: Client closed]
mmu_man has joined #u-boot
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
<marex>
rfs613: or just use 'ums' and 'dd' the image into the device as if it was a USB stick
mmu_man has quit [Ping timeout: 260 seconds]
<cambrian_invader>
yeah that is by far the most-convenient option
<marex>
also DFU block transfer is just slow
sukrutb has joined #u-boot
goliath has joined #u-boot
mmu_man has joined #u-boot
goliath has quit [Quit: SIGSEGV]
goliath has joined #u-boot
<rfs613>
marex: ums being mass storage? that might work... maybe even bmaptool could access it directly
<marex>
well yeah, it behaves like an usb stick
<rfs613>
g_dnl_register: failed!, error: -12
* rfs613
tries increasing malloc space
<marex>
rfs613: which uboot version is this ?
<rfs613>
marex: ancient ;-) 2021.01
<marex>
yeah, update
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
<rfs613>
marex: hehe, well at least the core support for rzn1 is in mainline now... I just have to add MMC and USB, how hard could it be?!? :P
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
<marex>
rfs613: woohoo, thank you
<rfs613>
this may be a project for the new year, seeing as my vacation starts 36 hours from now ;-)
goliath has quit [Quit: SIGSEGV]
prabhakarlad has joined #u-boot
<sjg1>
rfs613: yay vacation!
rockosov has quit [Ping timeout: 260 seconds]
rockosov has joined #u-boot
<marex>
yay
<f_>
yay!
goliath has joined #u-boot
Clamor has quit [Ping timeout: 268 seconds]
Clamor has joined #u-boot
diederik has left #u-boot [Going to see what happens IRL, see ya!]