<Kwiboo->
naoki: was about to comment on your u-boot gpio led patch: the swap is already handled by dm_gpio_set/get_value, so led-gpio driver should not do any swap
<Kwiboo->
however the gpio status cmd will show the raw gpio value and does not consider active low/high for requested pins
<Kwiboo>
mmind00: yes, that should match what was recently sent to ffmpeg-devel, working on a local v3 with minor changes and the addition of vp8, vp9 and av1, hoping to have it on list this weekend
<Kwiboo>
there is a known issue with the reworked ffmpeg code and hantro on armv7 when iommu is used/enabled, probably some cache coherency issue with the bitstream buffer sent from userspace to kernel/device
<Kwiboo>
mmind00: please also note that v4l2request-2024-v2 is enforcing frame size support that kernel driver report, and hantro report a step size 16px so it is possible that only 16px aligned videos can be used
* mmind00
has no real knowledge about v4l in general, so that last comment was beyond me ;-)
<mmind00>
I guess you mean videos in a size a multiple of 16px
<Kwiboo>
hehe, yeah, basically odd sized videos (in practice anything not aligned to 16px) may be rejected by the hwaccel, this is a change compared to the code we currently use in libreelec
<Kwiboo>
a kernel patch should fix/correct this, basically the hw buffer size alignement requirement is reported to userspace, it should be enough to report min/max supported frame size
<naoki>
Kwiboo-: yes, my patch is not required, but something is wrong. `led list` shows wrong state for GPIO_ACTIVE_LOW LED
<Kwiboo>
I think for some codec this should be 16px aligned and work/match drivers reported step_width/height, for other codec this may not be the case
<qschulz>
mmind00: if I'm not mistaken and there's nothing new to the uAPI for those kernel patches, installing gstreamer1.0-plugins-bad on a Debian Bookworm could be enough to test video decoding on stateless VPUs
<qschulz>
no 4k it seems but good enough to test **some** stuff :)
Daanct12 has quit [Quit: WeeChat 4.4.1]
erg_ has joined #linux-rockchip
erg_ has quit [Remote host closed the connection]
psydroid has quit [Read error: Connection reset by peer]
Daanct12 has joined #linux-rockchip
erg_ has joined #linux-rockchip
franoosh has quit [Ping timeout: 248 seconds]
erg_ has quit [Ping timeout: 246 seconds]
franoosh has joined #linux-rockchip
<warpme>
Kwiboo : thx. asking about potential regression as i'm sure: few months ago it was working ok (tested on rock3a with 7265 pcie wifi) now not works.....
<qschulz>
warpme: provided you didn't update U-Boot/BL31 between those two states, start a git bisect to figure out which commit(s) is the culprit to help narrow this down?
<warpme>
qschulz : well i updated uboot of course as well....
<warpme>
currently i'm on Kwiboo 2024.07 rk3xxx branch
franoosh has quit [Ping timeout: 246 seconds]
<qschulz>
warpme: were you on Rockchip's U-Boot before?
<warpme>
oh this i need to check as at some point of time i switched from multiple radxa uboot (for varuois boards) to common one based on excellend rk3xxx work of Kwiboo
<qschulz>
you could try with one of those radxa uboot with the same kernel and see if the same behavior can be seen
<qschulz>
to at least rule this out
<qschulz>
because Rockchip's u-boot is doing... interesting things at times :)
psydroid has joined #linux-rockchip
<warpme>
i will investigate this (fortunately i have archive of sd card images from last 1.5y kept exactly for such cases :-p)
<warpme>
btw: geez this is unbelieviable: 3rd device from radxa started to be failing after some months (rock5a: dram errors when board is warm; rock5b: hdmi edid scl always zero when board is cold; rock3a: hdmi no signal when board is cold)
<warpme>
Kwiboo : i think it might be worth to change uboot booting order from: emmc then sd to sd then emmc. Currently: when i have bard booting from emmc with old uboot and want to test new uboot i can't simply insert sd card with new uboot as bord will use old uboot from emmc....
<warpme>
another argument is that when user somehow messes emmc uboot then rescue boot from sd card is not possible....
<qschulz>
warpme: I personally believe you should always load proper from the same medium as TPL/SPL
<qschulz>
to counter your argument, what you're suggesting actually has security consequences
<qschulz>
I can simply pawn any of your device by inserting an SD card, seems.... not great
<qschulz>
warpme: isn't there a button to press to bypass eMMC/SPI on your devices?
<qschulz>
we have this on our devices
<warpme>
qschulz : well - better security in model where: you always start from emmc then follows with sdcard - if sdcard is inserted compared to alternative: where you start with sd and continue with sd - is in my opinion just illusion. From maintenance point of view i see significant diff in favour if second option...
<qschulz>
warpme: I can tell you that this was the cause for a few issues where I work
<warpme>
qschulz : pls let me understand why model with emmc then sd is better for avoiding of "pawn any of your device by inserting an SD card" that sd then emmc
<warpme>
if we will have secure boot chain - then a ggree
<warpme>
if we will have secure boot chain - then a agree
<qschulz>
warpme: no I'm saying, preferring emmc->sd when you have a valid emmc->emmc is not good
<qschulz>
if you have secure boot, that isn't an issue anyway as proper should be checked by SPL
<qschulz>
re: issues at work. always favoring sd card over emmc is what Rockchip's U-Boot does. We had people flashing eMMC and forgetting to remove the SD card when booting and they would be confused as to why their device wasn't updated
<qschulz>
and it happened more than once
<qschulz>
it's also just my opinion, we have a specific boot order for our devices that differs from all other Rockchip boards and I don't personally have interest in other Rockchip boards :)
<warpme>
exactly. so all this means that security arg. is just illusion (for me), while maintenance is highly real one (for me).
<qschulz>
so if you can convince Jonas/Kever it's a good idea.. :)
<qschulz>
I see your maintenance of your own device and I raise you the support I have to do internally and I don't want to imagine the support I would have to do for our customers if I didn't change it to what it is today :)
<qschulz>
again, if you have a button to press to boot from SD card to recover... maybe use that?
<qschulz>
(we have that on our products, I don't know if there's that on your devices though)
<warpme>
"if you have a button to press to boot from SD card to recover" - well iirc only 3 from 19 boards i have have such button....
<qschulz>
and no pad/pin on a header either?
<qschulz>
a bit of an odd choice for the HW design. How do you recover a bricked device?
<qschulz>
you have to desolder the eMMC/SPI? or use one of those flashing clips?
<warpme>
for pad/pin - i even not checkig this as probably 1% of my users will be able to go this route...
<qschulz>
warpme: note that you can change this order from the DT of your devices
<qschulz>
and have this in your own fork if upstream decides otherwise ;)
<Kwiboo>
warpme: I am not in favor of changing any FIT load order, trying to load FIT from same media that TPL/SPL is running from makes most sense, and boot_tragets already prefer sd above emmc so OS should prefer being loaded from sd-card
<Kwiboo>
if you are developing or testing different u-boot I would recommend wiping u-boot from emmc and only run from sd-card
<Kwiboo>
for rk35xx line there is also checksum test from start so the main reason anything would break is likely only due to bugs, if user overwrite part of FIT the checksum validation would fail and FIT instead gets loaded from sd-card
<warpme>
Kwiboo : issue i have is: when i confront in my head "makes most sense" with "wiping u-boot from emmc and only run from sd-card" - i see way more sense to avid second than follow first.....
<warpme>
simply - in limited view - i can't find arguments in "makes most sense"....
<qschulz>
warpme: principle of least astonishment
<qschulz>
I boot from eMMC, I get the whole bootloader from eMMC
<qschulz>
i boot from SD card, I get the whole bootloader from SD card
<warpme>
qschulz : this is exactly what i want to have :-)
<qschulz>
and **I** pushed that further by forcing bootstd to use the same medium as U-Boot proper
digetx has joined #linux-rockchip
<qschulz>
(on theobroma boards only)
<qschulz>
warpme: I don't understand... this is what you have with upstream U-Boot
<qschulz>
same-as-spl is a special string that is replaced by the medium that was used by the BootROM to boot the TPL
<qschulz>
if that isn't working, then we may have a bug in how we identify the medium
<qschulz>
which wouldn't be the first time, I fixed (and broke) it a few times already
<qschulz>
warpme: since it seems there's a misunderstanding, can you please tell us what you're doing, what you're expecting to happen and what is happening?
<warpme>
qschulz : ok then let me check on rk. On allwinner mainline 2024.07 is not behaving like that. It requires what Kwiboo said: "if you are developing or testing different u-boot I would recommend wiping u-boot from emmc and only run from sd-card"
<qschulz>
warpme: ah well, we're on #linux-rockchip here :)
<qschulz>
so didn't think you would be talking about another SoC vendor (I may have missed you mentioning it earlier though)
<warpme>
reference was to mainline uboot. do we have mainline rk and mainline aw?
<qschulz>
warpme: no, but what happens for one SoC vendor doesn't necessarily happens for another one
<qschulz>
and even from one SoC to another from the same vendor
<warpme>
let me chack: is mainline on rk has the same bahavious like mainline on aw (in context of: boot from eMMC, we get the whole bootloader from eMMC; boot from SD card, we get the whole bootloader from SD card
<qschulz>
I can tell you mainline rk is supposed to have the behavior you want
<qschulz>
if it doesn't, we need to fix it
<qschulz>
for aw, no clue
<qschulz>
it's all architecture code
<warpme>
sure. thx. i'll return with my findings
<qschulz>
so if aw maintainer didn't add a similar logic, it's not supported
<qschulz>
FWIW, the code is rather convoluted so don't be surprised if it's difficult to navigate or understand what's going on, it always takes me a few minutes to remember what it's supposed to do, and I spent a lot of time in it trying to figure things ou
krei-se has joined #linux-rockchip
<naoki>
hmm
<naoki>
radxa e52c has two rtl8125b
<naoki>
`pci enum` on u-boot returns PCIe-0 Link Fail
<naoki>
(it works on linux)
<wens>
Kwiboo: AFAIK the step size is a codec thing, basically how large macro blocks are
<wens>
the decoded frame is always a multiple of that. The player then trims off the parts that are unwanted
<wens>
the hardware is likely going to decode to a buffer with a layout of multiples of the step size
urja has quit [Read error: Connection reset by peer]
urja has joined #linux-rockchip
SystemError has joined #linux-rockchip
<diederik>
qschulz: why use Debian Bookworm/Stable at all for testing new things?
<diederik>
Anything but Unstable/Sid or Testing/Trixie seems pointless to me (for such things)?
<qschulz>
diederik: because we provide Bookworm images for our products, so you flash the image, run apt-get and see if it works. If it doesn't, then we can figure things out
<diederik>
ok, yeah, in that context it does make (at least some) sense. Thanks :)
<qschulz>
i also personally do not want to debug userspace too much as that's not where i'm comfortable, so at least there is **some** chance it's somehwat "stable" in the "Stable" release :)
<diederik>
It's the combination of the latest-of-the-latest with a (certainly now) dated rest of the stack that surprised me
<diederik>
You may want to give Testing a try though. It has much newer software and it doesn't break much.
<diederik>
And AFAICT you're smart enough not to do 'stupid shit' which is what appears to be the cause of 90+% of problems people experience in Testing
<diederik>
F.e. if an 'apt upgrade' tells you that it will destroy your system, I'm sure you'll answer that question with 'n'(o) ...
<qschulz>
yes | apt upgrade
* qschulz
giggles
<diederik>
indeed. Stay away from '-y' and 'full-upgrade' (by default) and you should be fine
<diederik>
FTR: Stable is absolutely fine if you'd run it as your main OS
franoosh has joined #linux-rockchip
franoosh has quit [Remote host closed the connection]
franoosh has joined #linux-rockchip
<warpme>
qschulz : FYI: test i just done: rock3a; emmc has 2024.07 uboot; flashed sd card with 2023.10 uboot. Inserted sd card. Board boots from sd card (extlinux.conf; rootfs are from sd card) with 2024.07 uboot. Erased emmc. Board boots with 2023.10 (extlinux.conf; rootfs are from sd card)
<warpme>
so behaviour i EXACTLY the same like in allwinner mainline....
<qschulz>
warpme: one more misunderstanding
<qschulz>
there are three possible stages where a boot medium needs to be picked
<qschulz>
BootROM picks a boot medium for loading TPL+SPL
<qschulz>
SPL picks a boot medium for U-Boot proper
<qschulz>
U-Boot proper (via bootstd) picks a boot medium for extlinux/rootfs/whatever
<qschulz>
only a HW configuration can change the boot medium in 1) (that's a button, pad, pin, etc...)
<qschulz>
2) we default to use the same as in 1), if it isn't found it goes through other media in a specific order, defined in DT
<qschulz>
3) by default, sd card, emmc, nvme, scsi, usb, pxe, dhcp and then spi
<qschulz>
3) is applicatble to all Rockchip boards except theobroma's
<qschulz>
to be called from rockcip_early_misc_init_r for example
naoki has quit [Quit: naoki]
<qschulz>
i was tempted to add a "same-as-proper" special string to BOOT_TARGETS for bootstd to avoid having this logic in a board file
<qschulz>
haven't done this yet though
franoosh has quit [Read error: Connection reset by peer]
<qschulz>
I thought we were talking about 2) != 1) (considering the answer, same for Kwiboo), and not 3) != 2)
franoosh has joined #linux-rockchip
<Kwiboo>
one more thing that has been improved in last year is that SPL for rk aarch64 now do checksum validation of RK and the sd-card fallback in SPL actually works (pinctrl for boot media was not always applied)
<qschulz>
yup but that's step 2) from the above list :)
franoosh has quit [Read error: Connection reset by peer]
franoosh has joined #linux-rockchip
<warpme>
qschulz : perfect. this is very helpful. thx!
<Kwiboo>
qschulz. yep :-), I just wanted to highlight that the fallback/recovery these days should work much better compared to 1-2 year ago (on rk aarch64), booting is now more protected against end-users accidently overwriting part of FIT / U-Boot proper
<qschulz>
Kwiboo: yup! all great things
<warpme>
Kwiboo : FYI: replacing uboot from rk3xxx to radxa 2023.10 not changes pcie wifi issue - so it looks to me like kernel regression.....
<Kwiboo>
the only part still not checksum validated is BootROM to TPL/SPL for anything older than rk35, to my knowledge bootrom only support rsa sign check (secure boot) on the older socs
franoosh has quit [Read error: Connection reset by peer]
erg_ has joined #linux-rockchip
<qschulz>
Kwiboo: do you mean that rk35 bootrom already does checksum for that part?
erg_ has quit [Remote host closed the connection]
erg_ has joined #linux-rockchip
<Kwiboo>
qschulz: I have not fully validated it, but the header contains an sha256 checksum for each payload, and if I remember correctly I tested wiping only part of the TPL/SPL and it would still fallback to next sector position
<qschulz>
Kwiboo: AFAIK, NXP used to have a bootrom that could load the SPL from the emmc boot partitions in the proper order
<qschulz>
ideal for A/B updates or full fallback
<qschulz>
but AFAIU, it's gone on imx8 and later
<qschulz>
i would be really interested to know what made them decide to ditch it
franoosh has joined #linux-rockchip
<qschulz>
Kwiboo: additionally to that, emmc boot partitions are much more resilient by default than the other partition(s)
<qschulz>
pSLC and write reliability bits are set IIRC
<qschulz>
(looked into that but 5 years ago....)
<Kwiboo>
hehe, yeah, would have been nice if bootrom could load tpl/spl from boot partition, just played around with at least have the FIT in boot partition in that RFC, but probably only something that is interesting for people that know what they are dooing ;-)
<qschulz>
Kwiboo: Yeah but I think it could still be somehow interesting, especially for distros
<qschulz>
because right now having U-Boot + whatever the distros requires on the same medium is not straightforward
<qschulz>
e.g. fedora doesn't seem to support this OoB
<qschulz>
(I very briefly tried on RK3399 Puma)
franoosh has quit [Ping timeout: 248 seconds]
<qschulz>
they would very much like a separate medium for the bootloader, e.g. an SPI-NOR
<qschulz>
moving to the boot partition is kind of a separate medium in a way
franoosh has joined #linux-rockchip
<qschulz>
but we'd still need the TPL and SPL on eMMC in (eMMC) user partition :/
franoosh has quit [Read error: Connection reset by peer]
<hrw>
mmind00, dsimic, diederik: v6 of FriendlyELEC NanoPC-T6 sent
<Kwiboo>
qschulz: yep, having TPL/SPL on user partition would still be required :/, my main thinking was also that it may help install distros and their default partitioning, at least when when TPL/SPL is outside default partitioning
<diederik>
hrw: it's looking much better :)
<diederik>
I do have 1 question: Shouldn't the u2phy2_host be removed completely from the dtsi in patch 3? In that same patch you add it to the dts of the non-LTS version and it's added to the LTS version in patch 4 (AFAICT).
<mmind00>
diederik: or we just override the supply in the board dts files
<mmind00>
i.e. keep u2phy2_host with its status=okay in the dtsi and just set the supply in the board dts
<mmind00>
I guess mostly a style decision, but removing the phy from dtsi would mean also talking about the main u2phy + even its attached usb controller ... why are those in the dtsi then ;-)
<mmind00>
but as the controller + its phy is _used_ on both boards, I do think it can stay in the dtsi
<diederik>
yeah, it was mostly have "okay" in the dtsi + 2x in the dts files
<mmind00>
diederik: hrw: just to note I applied the series with that modification (dropped the status=okay from the board dts files, so that okay stays in the dtsi only) ... if no one complains I'll push that after dtbs check is happy
<diederik>
\o/
<mmind00>
diederik: is that happiness or raising your arms to complain? ;-)
<diederik>
happiness :)
<diederik>
I never heard of using it in the context of complaining
<diederik>
I actually learned that 'symbol' in the context of a trance/edm forum (depicting a dancing person), thus not on/from IRC ;)
<mmind00>
but could also be holding tomatoes to throw
<diederik>
LOL
<qschulz>
or pitchforks
<qschulz>
well, spears maybe
<hrw>
mmind00: thanks
<hrw>
mmind00, Kwiboo: I would move most of u*phy* okay entries to dtsi as those boards differ even less between each other but no 2301 one to test
Daanct12 has quit [Quit: WeeChat 4.4.1]
hrw has quit [Read error: Connection reset by peer]
hrww has joined #linux-rockchip
raster has quit [Quit: Gettin' stinky!]
dsimic has quit [Ping timeout: 248 seconds]
dsimic has joined #linux-rockchip
Stat_headcrabed has joined #linux-rockchip
macromorgan has quit [Quit: No Ping reply in 180 seconds.]
macromorgan has joined #linux-rockchip
arnd has quit [Ping timeout: 276 seconds]
arnd has joined #linux-rockchip
mripard has quit [Quit: mripard]
Stat_headcrabed has quit [Quit: Stat_headcrabed]
jakllsch has quit [Ping timeout: 260 seconds]
jakllsch has joined #linux-rockchip
paulk has quit [Ping timeout: 244 seconds]
Stat_headcrabed has joined #linux-rockchip
paulk has joined #linux-rockchip
ldevulder has quit [Quit: Leaving]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
raster has joined #linux-rockchip
warpme has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
vagrantc has joined #linux-rockchip
warpme has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]