System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
kilobyte_ch has quit [Ping timeout: 252 seconds]
warpme_ has joined #linux-rockchip
warpme_ has quit [Ping timeout: 252 seconds]
kilobyte_ch has joined #linux-rockchip
warpme_ has joined #linux-rockchip
warpme_ has quit [Ping timeout: 264 seconds]
warpme_ has joined #linux-rockchip
warpme_ has quit [Ping timeout: 265 seconds]
qschulz has quit [Remote host closed the connection]
vagrantc has quit [Quit: leaving]
qschulz has joined #linux-rockchip
alpernebbi has quit [Ping timeout: 252 seconds]
kilobyte_ch has quit [Ping timeout: 252 seconds]
kilobyte_ch has joined #linux-rockchip
warpme_ has joined #linux-rockchip
alpernebbi has joined #linux-rockchip
warpme_ has quit [Ping timeout: 248 seconds]
stikonas has quit [Remote host closed the connection]
warpme_ has joined #linux-rockchip
warpme_ has quit [Ping timeout: 244 seconds]
System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
warpme_ has joined #linux-rockchip
warpme_ has quit [Ping timeout: 252 seconds]
warpme_ has joined #linux-rockchip
hanetzer has quit [Ping timeout: 265 seconds]
hanetzer has joined #linux-rockchip
warpme_ has quit [Ping timeout: 260 seconds]
warpme_ has joined #linux-rockchip
s1b1 has joined #linux-rockchip
warpme_ has quit [Ping timeout: 255 seconds]
manawyrm has quit [Ping timeout: 265 seconds]
hexdump0815 has quit [Ping timeout: 252 seconds]
hexdump0815 has joined #linux-rockchip
manawyrm has joined #linux-rockchip
warpme_ has joined #linux-rockchip
warpme_ has quit [Ping timeout: 246 seconds]
System_Error has quit [Ping timeout: 260 seconds]
System_Error has joined #linux-rockchip
warpme_ has joined #linux-rockchip
warpme_ has quit [Ping timeout: 248 seconds]
<naoki>
dsimic: thanks for the quick review :)
<dsimic>
anytime :)
warpme_ has joined #linux-rockchip
warpme_ has quit [Ping timeout: 252 seconds]
warpme_ has joined #linux-rockchip
warpme_ has quit [Ping timeout: 248 seconds]
franoosh has joined #linux-rockchip
franoosh has quit [Changing host]
franoosh has joined #linux-rockchip
hanetzer has quit [Ping timeout: 252 seconds]
warpme_ has joined #linux-rockchip
warpme_ has quit [Ping timeout: 255 seconds]
Stat_headcrabbed has joined #linux-rockchip
Stat_headcrabbed has quit [Remote host closed the connection]
Stat_headcrabbed has joined #linux-rockchip
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
warpme_ has joined #linux-rockchip
warpme_ has quit [Ping timeout: 260 seconds]
franoosh has quit [Ping timeout: 252 seconds]
eballetbo has joined #linux-rockchip
franoosh has joined #linux-rockchip
warpme has joined #linux-rockchip
ldevulder has joined #linux-rockchip
warpme_ has joined #linux-rockchip
warpme_ has quit [Ping timeout: 245 seconds]
<naoki>
startup-delay-us for some pcie regulators for ROCK 5B are really required?
warpme_ has joined #linux-rockchip
raster has joined #linux-rockchip
warpme_ has quit [Ping timeout: 264 seconds]
System_Error has quit [*.net *.split]
raster has quit [Quit: Gettin' stinky!]
warpme_ has joined #linux-rockchip
dsimic has quit [Ping timeout: 265 seconds]
dsimic has joined #linux-rockchip
warpme_ has quit [Ping timeout: 260 seconds]
raster has joined #linux-rockchip
<robmur01>
if it's a regulator for powering a slot or on-board PCI device itself, then startup delay can be a handy hack for giving the endpoint enough time to become ready for enumeration
warpme_ has joined #linux-rockchip
warpme_ has quit [Ping timeout: 248 seconds]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
MyNetAz has joined #linux-rockchip
warpme_ has joined #linux-rockchip
warpme_ has quit [Ping timeout: 245 seconds]
vagrantc has joined #linux-rockchip
warpme_ has joined #linux-rockchip
warpme_ has quit [Ping timeout: 265 seconds]
warpme_ has joined #linux-rockchip
<mmind00>
dsimic: do you remember where we talked about the dt-overlay dtb size regarding the symbols?
<mmind00>
it was about the dtb size overflowing some assigned memory area in legacy bootloaders, right?
ldevulder has quit [Quit: Leaving]
<dsimic>
mmind00: huh, we talked about that, and I already tried to remember where exactly, but haven't remembered yet :/
<dsimic>
I'll try to find that again
<dsimic>
BTW, I've seen the related patch from Fukaumi
<mmind00>
dsimic: yep ... which brought this up in my mind again
<mmind00>
and as diederik wrote, just trying to hand this off to distributions is sort of difficult
<mmind00>
especially as setting the DTC_FLAGS thing on the make comandline does not fully work ;-)
<dsimic>
moreover, relying on the distributions to do that introduces additional segmentation, because some distros may do that, while others may not, awaiting the upstream to do that, which all together may create a possible confusion among the end users who should actually benefit from the dtbo files :)
<mmind00>
so I guess we're definitly going with a per-board enablement ... and I guess one "simple" requirement we could have is for the submitter to boot that bigger dtb with the original firmware the device came with ? Because as far as I remember, that old legacy firmware was the big concern?
<dsimic>
yes, old/legacy firmware builds are the primary concern, but I'm not sure we can actually isolate some partocular legacy boot loader version(s), because many boards come with nothing preinstalled, even with no permanent storage at all to which something could come preinstalled
<dsimic>
s/partocular/particular/
<mmind00>
yes that why I meant the earliest still available firmware release for each board
<dsimic>
maybe we could rely on testing some old operating system images that were offered by the board manufacturers
<mmind00>
i.e. it shouldn't be too much work when you're enabling symbols for a board, to grab the earliest firmware image still available and boot the new dtb with that
<dsimic>
if that's still available :)
<dsimic>
better said, if that was available at all as a separate build or package
<dsimic>
but most manufacturers offer some official OS images, whose old versions should be still available and should be fine for such testing
<mmind00>
yep
<dsimic>
for example, legacy factory-installed OS images for the Pinebook Pro and PinePhone Pro are available, which can be used for such testing
<dsimic>
Radxa also offers OS builds
<mmind00>
that is exactly what I had in mind :-)
<dsimic>
good :)
<mmind00>
we don't want big obstacles, just at least some testing that early firmware won't fall apart
<dsimic>
I agree that we should require testing with such OS builds before enabling the symbols on a per-board basis
<dsimic>
yes, just a rather quick verification that the U-Boot builds from the old images still work with enlarged .dtb files for a particular board/device
<dsimic>
which is still a bit tedious to test, but better be safe than sorry :)
<mmind00>
yes, but it distributes well :-D
<dsimic>
the last thing we want is a bunch of angry users whose boards no longer boot after a kernel upgrade :)
<mmind00>
though I'd doubt that would happen much with SBCs :-D
<dsimic>
yes, because the users who run latest kernel versions probably also upgrade their U-Boot builds, but who knows :)
<diederik>
yeah ... about that. The impression that I got is that the symbols won't be turned on for a board which could have an ancient u-boot version which is never updated?
<diederik>
Sure it's great if we could validate that it still works with it, but don't enable it if someone wants to run an ancient and unsupported U-Boot version while also running the very latest kernel?
<mmind00>
diederik: above we didn't get to the what-if part ;-)
<dsimic>
such ancient U-Boot builds may also have issues with ever-enlarging kernel and initrd images, so... other issues are also possible
<diederik>
but ofc that's what I did as to me that's a logical consequence of the earlier discussion
Hypfer65 has joined #linux-rockchip
Hypfer6 has quit [Read error: Connection reset by peer]
Hypfer65 is now known as Hypfer6
<mmind00>
right now I'd just require that boot-test on the earliest available firmware
<mmind00>
and _if_ that fails then discuss how to proceed ;-)
warpme_ has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
<mmind00>
on a per-board basis
<dsimic>
mmind00: sounds like a plan to me
<dsimic>
so if we encounter such failures, let's discuss them further at that point
<diederik>
to me personally, that makes no sense. But I don't have/get to decide
<mmind00>
diederik: Care to elaborate?
<dsimic>
diederik: could you, please, describe your thoughts on all that?
<diederik>
IMO: if you ask the question, you should accept you may not get the answer you're hoping for
<dsimic>
of course
<mmind00>
there can always be angles nobody thought of, so all opinions are valuable :-)
<diederik>
so I would make the plan/choice what to do if you're not getting the 'yes' answer
<dsimic>
maybe we could ask the manufacturer or contributor to provide newer U-Boot build to the affected boards?
<mmind00>
but that would also require people to update their firmware
<dsimic>
s/to the/for the/
<diederik>
so to me it seems symbols may not get enabled because there's someone who runs old/ancient/unsupported U-Boot and the very latest kernel
<diederik>
I'd say: update your U-Boot first before you get to hold everyone 'hostage'
<mmind00>
though that would go against the "we don't break users" thing
<dsimic>
I don't think that asking people to update their firmware is a bad thing to do, unless there are some specific reasons
<diederik>
yeah, that was my first thought for the reason too ... but boot loader firmware is not exactly userspace
<dsimic>
people should actually be happy that newer firmware versions are available :)
<mmind00>
I'm all for replace your firmware, but from past experience, firmware has less margin for error ;-)
<mmind00>
like on old firefly boards (3288 and 3399) you actually need to bridge two test-points on the (underside of the) board
<dsimic>
yup, recovering from a bad U-Boot build can be painful, for which shorting the pins on the SPI NOR chip inside the Pinebook Pro is another example
Hypfer6 has quit [Read error: Connection reset by peer]
Hypfer6 has joined #linux-rockchip
<mmind00>
so my idea with that requiring the old-firmware-test was meant to get out of the hypothetical realm .... because right now we're still in the "this _may_ break on some firmware versions" ... we don't even have any real-life-data ;-)
<mmind00>
tentative idea, on an SBC we could just require a firmware update (and make a note in the Makefile about that for the symbol-flag) ... and not enable symbols for actual consumer devices
<mmind00>
or alternatively, when the device has an actual maskrom-button go the firmware-update way
<dsimic>
as a note, MaskROM buttons are virtually always handled in firmware, so a really bad U-Boot build may make them useless
<mmind00>
dsimic: maskrom vs. recovery I think
<dsimic>
maybe all this is a good point to start thinking a bit more about distributing U-Boot builds for various boards and devices through fwupd... I haven't researched what are the prerequisites for something like that to happen for the boards and devices coming from some manufacturer?
<robmur01>
yeah, real maskrom buttons are a dev board luxury, most things just have the "recovery" ADC button for rockusb mode
<dsimic>
I mean, what are prerequisites for fwupd to accept and distribute such U-Boot builds?
<Kwiboo>
however it is the control fdt that is built with u-boot that should fit in that 128KB buffer and currently the ROCK 5B fdt is 107.77 KiB
<mmind00>
Kwiboo: that value is definitly unfortunate ... because as you said the rock5b at 108KB already
<mmind00>
Kwiboo: but yeah, the fdt build with firmware is not affected by the build-_flag_ we set in the Linux makefile
<Kwiboo>
I do not think the kernel dtb should have much affect for u-boot and tf-a, unless more and more nodes are being added
<mmind00>
though there are a number of rk3588 controllers not even added yet
<Kwiboo>
yeah, as long as the symbols is not enabled for u-boot's control fdt it should probably be fine, the 128kb buffer in ft-a could possible need an adjustment to be more future proof
<mmind00>
Kwiboo: of course there is the line of though of declaring the dt part of firmware and using one DT for all ... but I don't think any existing board is doing that
<mmind00>
the rpi4 seems to use 1MB for the fdt buffer
<Kwiboo>
for rk3588 SPL_ATF_NO_PLATFORM_PARAM is implied in u-boot, so no fdt is passed to tf-a by default, if I remember correctly vendor tf-a blob had some issues, at least the blob I tested back then
<naoki>
as far as I can remember, vendor tf-a has a issue, so u-boot doesn't pass dtb to tf-a
<naoki>
SPL_ATF_NO_PLATFORM_PARAM
warpme_ has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
<dsimic>
yup, we've discussed that recently, rkbin blobs have an issue with that
<dsimic>
so we've got SPL_ATF_NO_PLATFORM_PARAM all around, e.g. for the RK3399 as well