<marex>
qschulz: afaict they can just be applied, no ?
<marex>
Tartarus1: ^
<qschulz>
marex: since we're not too far away from a release, I think we should ping Tartarus1 on this one? I believe we have enough reviews and tests for those to be merged?
<marex>
qschulz: done ;-)
<qschulz>
:)
<qschulz>
You/we forgot to Cc Patrick Delaunay from ST on that patch :/
<Tartarus1>
I mean, I'm not 100% sure grabbing them right now for v2023.01 is good. I had assumed it was a regression introduced since the last release, and not a longer standing one
<qschulz>
marex: welcome back :)
<Tartarus1>
So maybe we have time to make sure everyone is happy and fix it for v2023.04
<Tartarus1>
Unless the folks that introduced the problem have also ack'd the revert + new fix?
<qschulz>
Tartarus1: then only take the revert of the revert I believe
<qschulz>
since that one is a regression we've had for a few releases already?
<qschulz>
lemme check
<Tartarus1>
qschulz: But then that breaks the use case that I assume ST folks have been using since it was introduced?
<marex>
we agreed with the author of the d5ba6188dfb that limiting the fdtcontroladdr to non-fitImage is fine
<marex>
what's the problem ST has ?
<qschulz>
Tartarus1: ed6251187afa ("Revert "cmd: pxe_utils: Check fdtcontroladdr in label_boot"") is a revert in v2023-01-rc4 which reverts d5ba6188dfbf ("cmd: pxe_utils: Check fdtcontroladdr in label_boot") in U-Boot since v2022.04-rc1
<qschulz>
d5ba6188dfbf introduces a regression, but is needed by ST
<qschulz>
ed6251187afa fixes the regression (obviously), but breaks ST use case
<marex>
Tartarus1: fixes and tests another crappy bug, hopefully once and for all
<marex>
qschulz: I think the gpio hog handling is great, we're finally getting rid of crappy hacks to probe drivers
<Tartarus1>
marex: OK, so the exit stuff is fixing an even older issue (v2021.04-755-g8c4e3b79bd0b) so can I be worried about unexpected fallout and take that series for -next instead?
<Tartarus1>
I really want to limit things to regressions introduced for this cycle, at this point
<marex>
Tartarus1: I mean, it does fix a real world bug and people are affected ...
<marex>
but it does change a fundamental behavior of the shell, which worries me
<Tartarus1>
marex: Yes, but might people have worked-around that bug and be broken by the correct fix?
<marex>
qschulz: because u-boot shell always turns negative return values into 0 as far as I can tell
<marex>
qschulz: it is a bit weird indeed
<Tartarus1>
I'm fine taking everything in that patchwork bundle
<qschulz>
Tartarus1: ok, will stop discussing this one then :)
<marex>
please discuss gpio hog ;-)
<qschulz>
marex: re: gpio hog, the issue is that we need tests
<qschulz>
and I wasn't able to create them for the sandbox
<qschulz>
I spent a few hours on it to no avail
<qschulz>
IRC log:
<qschulz>
it seems I'm unable to write a unit test for this dm patch
<marex>
qschulz: how does such a test look like, stick a gpio-hog into sandbox DT and then run 'dm tree' and check whether the 'probe' flag of driver is set ?
<qschulz>
marex: the issue is this needs to be tested in SPL
<qschulz>
with DM support
<qschulz>
IRC log cont.: https://paste.ack.tf/dc8598 is what I came up with, but impossible to actually run this test
<qschulz>
way too many changes to be able to even compile this with sandbox_spl_defconfig
<qschulz>
and with sandbox_defconfig, ./u-boot -T -c "ut dm fdt" does not run it either
<qschulz>
so i'm not against some guidance on how to write a unit test for that patch
<qschulz>
what we want to test is that in pre-reloc, a driver with DM_FLAG_PROBE_AFTER_BIND flag but not DM_FLAG_PRE_RELOC gets probed if it is bound to a device tree node where u-boot,dm-pre-reloc is set
<marex>
qschulz: is it even possible to do SPL tests in sandbox ?
<marex>
sjg1: ^
<Tartarus1>
I mean, there's tests for sandbox_spl specifically
<Tartarus1>
So I would assume so
* cambrian_invader
has been meaning to add some SPL loader tests
<sjg1>
Tartarus1: Can you please apply this fix for the release? Or would you like a PR?
<sjg1>
qschulz: Yes sandbox_spl has an SPL build and runs tests, e.g. in CI and with 'make qcheck'
<Tartarus1>
sjg1: Waiting for someone to also fix the mvebu board(s) that get broken with your revert
<sjg1>
Tartarus1: When is the release?
<Tartarus1>
9th
<sjg1>
OK phew, thanks!
<marex>
Tartarus1: we really should shift the release after xmas to end of January
<marex>
Tartarus1: this soon after new year, it just sucks
<Tartarus1>
marex: I dunno, that just throws off everything else
<marex>
Tartarus1: what else ?
guillaume_g has quit [Quit: Konversation terminated!]
<broonie>
Or make the previous release cycle slightly shorter and release just before Christmas.
<Tartarus1>
The rest of the releases?
<marex>
broonie: no 2 month release cycles, please ... I beg you, on my knees no less 3-/
<Tartarus1>
I try and not take in much in Dec
<Tartarus1>
but I can always work harder on that
<marex>
Tartarus1: its harder to get hold of people right after new year for last minute fixes ...
<marex>
so if the release was end of January, it would be easier
<Tartarus1>
marex: But it shouldn't be last minute
<broonie>
marex: It'd probably work out as 2.5 but yeah, something's got to give.
<Tartarus1>
That's my problem really
<marex>
Tartarus1: uh ... huh ... ;-)
<marex>
broonie: we did have 2 month cycles before, it wasn't great
<marex>
3 (like linux) seems very nice
<Tartarus1>
I mean, yeah, I shouldn't have taken ed6251187a in hind-sight
<Tartarus1>
But if you test in Nov, or Dec, it should still be fine for the Jan release
<Tartarus1>
And (oh right, I need to follow up and ask Harald to redirect the old wiki ReleaseCycle url to the new doc one) the schedule is set out a year in advance
<Tartarus1>
So yes, I get a little frustrated about "last minute" testing
<qschulz>
Tartarus1: yeah, if we could have only fixes during rcs, it'd be great :)
<qschulz>
Tartarus1: that revert is on me, I miscommunicated
<marex>
I'll be back in a few minutes
<Tartarus1>
qschulz: No worries really :) And yeah, I try and maybe I need to push open next sooner
<Tartarus1>
And just stop taking late PRs after say -rc2
<qschulz>
Tartarus1: wondering if we should have a larger merge window and fewer rcs?
<qschulz>
that way it might make it easier for people to wait for the next release instead of pushing features in rcs?
<Tartarus1>
I don't know, we already have a longer than Linux merge window
<Tartarus1>
I feel like it's more a matter of people having / getting time at work to put things together
<Tartarus1>
However, if you want to make a suggestion on the -custodians and -board-maintainers list, I'd appreciate it
<Tartarus1>
Maybe someone else bringing it up will encourage new / different feedback
<qschulz>
The complaints I have could be resolved if I had the time to spend on maintaining stuff in U-Boot
<qschulz>
But I cannot :)
<qschulz>
(we're hiring BTW, if someone wants to allow me to breathe a bit :D)
<marex>
Tartarus1: maybe we should find a way to fund full time U-Boot developers/maintainers
<qschulz>
marex: if you find how, many other FOSS projects would like to know too :)
<marex>
qschulz: doesnt LF do that somehow ?
vagrantc has joined #u-boot
<marex>
vagrantc: hi, btw. what's up with the dh imx6 board in debian, is there a problem with it ?
<vagrantc>
marex: hopefully not! the freeze cycle for debian is coming up, and just looking for some positive confirmation that boards are working
<vagrantc>
marex: as packaged in debian ... maybe i break something? :)
<marex>
vagrantc: if it works in upstream u-boot, it works in debian build of the same ... I hope, since it is very close to what I'm often testing myself
<vagrantc>
marex: that's usually true, but once in a while toolchain differences or whatnot can cause surprises
<sjg1>
Tartarus1: marex: I still think that the current release cycle is too long. After the merge window closes there is what seems an interminable 'dead spot' in the project. The next branch helps with that, but few seem to use it
<Tartarus1>
sjg1: Yes, I wish I got more PRs for the next branch, but I feel like a shorter cycle wouldn't encourage change in submission cycles of changes
<Tartarus1>
Heck, I really should try opening it at say rc2, and not take non-bugfix changes post rc2
<marex>
sjg1: 9 weeks, which is more than 2 months ... but really, do you want to stress people who are already stressed out enough even more ?
<sjg1>
The 9 weeks after the merge close really drags on
<marex>
sjg1: do you actually work full time on U-Boot ?
<sjg1>
marex: I actually see quite a few maintainers who seem to be poked by the merge window being about to close
<sjg1>
marex: No I don't and it isn't my day job at all, as you know :-)
<marex>
(I do know?)
<marex>
hum ....
<broonie>
Linux has -next which keeps development mostly flowing relatively well.
<marex>
broonie: I <3 next, much
<sjg1>
marex: But I think we should discuss this and how to bring things closer. Perhaps it is -next improvements, perhaps it more people investing in automated testing, ...?
<broonie>
Yeah, the CI work on the kernel has made the merge window a lot less stressful.
<marex>
sjg1: it would be good to have an actual gettogether again too
<marex>
broonie: +1
<sjg1>
+1
<sjg1>
(to both of you)
ladis has quit [Quit: Leaving]
<qschulz>
throwing this out-there but... what about KernelCI but for U-Boot?
<qschulz>
very long term obviously
<Tartarus1>
What do you mean?
<qschulz>
have actual IRL tests of U-Boot binaries
<Tartarus1>
Yes, we have that today
<Tartarus1>
It'd be great if more companies setup labs using it
<qschulz>
mmmm, need to read more on that then
<Tartarus1>
But the pytest stuff in CI also works on real HW
<Tartarus1>
And there's many examples of how to wire up more controllers
<qschulz>
do you have a doc link at hands right now by any chance?
<qschulz>
i can look it up now that i know this exists :)
<broonie>
People have worked on the SD muxes, I'm not aware of anything widely available that's robust :(
<marex>
qschulz: I have SD card implemented in FPGA, backed by SDRAM (32 MiB) and you can push data into the SDRAM via USB
<marex>
qschulz: so far it is much prototype though
<qschulz>
marex: we have HW for it, just need to use it :D
<Tartarus1>
FWIW, the sd muxes I ordered from one of the people that builds and sells in small quantities are great
<marex>
qschulz: it is not a mux, it is an actual SD card implementation in the FPGA, just no NAND, but SDRAM as storage
<Tartarus1>
I do wish the pengutronix ones were affordable tho
<qschulz>
we have some in-house design but not sure it's been well used for years (but maybe it just works :) )
<Tartarus1>
(the ones I have are basically the latest rev of the original tizen ones, and dropped a few of the features that can be handled via external relays / etc instead)
apritzel has quit [Ping timeout: 272 seconds]
<qschulz>
sorry folks, the cat has decided I'm not allowed to typ on kb anymore, see you tmrw
<marex>
heh
<marex>
broonie: btw seems next is stuck this week , sigh
<broonie>
marex: Only till tomorrow, he says he'll be back on the 5th.
<marex>
woohoo
<marex>
broonie: btw is next really merged manually or is there automation ?
<marex>
I would expect the later for the most part
<broonie>
It's automated, human intervention is only needed for merge or build failures once it's running.
<marex>
makes sense
<broonie>
qschulz: The trouble with advanced bootloader setups is that they usually involve JTAGing the binary or something and my setup is all ethernet and serial port.
<vagrantc>
i'm guessing -rc5 is likely going to be skipped?
Gravis has joined #u-boot
Gravis has quit [Ping timeout: 260 seconds]
Gravis has joined #u-boot
<Tartarus1>
Did I say I'd do -rc5 yesterday? Damn, shouldn't have assumed my calendar was off like always :(
Tartarus1 is now known as Tartarus
mmu_man has quit [Ping timeout: 246 seconds]
<vagrantc>
with the -rc4 announcement, it suggested another RC in two weeks, but the discrepancy can be blamed on y2023 issues.
<vagrantc>
:)
<vagrantc>
no big deal, really, just curious if there were still plans for an rc5 that was running a day late or something
<Flole>
Has anybody looked into why a9bf024b2933bba0e23038892970a18b72dfaeb4 caused a regression a few releases ago on the amlogic boards? I'm not sure why an illegal memory access is taking place there (or even a jump to illegal memory)
<marex>
xypron: ^
<marex>
xypron: EFI stuff
mmu_man has joined #u-boot
<vagrantc>
yeah, also dealing with that issue for amlogic boards
<Flole>
When I tried to decode my dump it didn't point to a particular code line, it seems like it jumped to illegal memory somehow
<marex>
Flole: do you have any other extra patches ?
<vagrantc>
echo '# CONFIG_EFI_LOADER is not set' >> configs/odroid-c2-noefi_defconfig
<vagrantc>
Flole: you're saying EFI boot doesn't work either?
<Flole>
I never tried EFI boot
<Flole>
I tried to boot from tftp first, that didn't work, so I tried to boot locally from a "normal" linux image to rule out a tftp issue
<Flole>
Unfortunately I don't have my board here right now, otherwise I could try again
<Flole>
Oh if it matters: I'm trying to boot from an SD card, no eMMC attached
<xypron>
Flole: For analysis the following would help: .config, complete log, exact source version that you use. Any scripts that are executed.
<vagrantc>
ok, i'm about to try EFI boot
<Flole>
vagrantc: Can you also provide the stuff xypron wants? ;) I won't get my board back until in 2 weeks or so
<vagrantc>
xypron: the u-boot-amlogic packages in debian contain the config and the exact source ... you want a complete boot log? build log? ... i can also demonstrate the extlinux configuration
<xypron>
vagrantc: Does this relate to Debian bug #1027176?
<vagrantc>
xypron: yes, that's exactly the bug
<xypron>
vagrantc: 2022.07~rc3+dfsg-1?
<vagrantc>
xypron: that's the first version uploaded to debian after the commit that was identified as the cause
<vagrantc>
xypron: there are some boot logs from more recent versions that are currently in debian
<xypron>
vagrantc: Does the problem exist with current GIT head?
<Tartarus>
Since that of course isn't strncat here :)
<vagrantc>
do the scripts generate u-boot.map, or is it created as part of the build process?
<Flole>
Pretty sure it's created during build
<Flole>
It should just sit next to u-boot.bin
<vagrantc>
hrm. i should probably ship that in the packaging then
<Flole>
Or create a debug package that contains it
<vagrantc>
should ship it in some way rather than tossing it out the window :)
ikarso has joined #u-boot
___nick___ has quit [Ping timeout: 256 seconds]
naoki has joined #u-boot
mlaga97 has joined #u-boot
rvalue has quit [Ping timeout: 255 seconds]
rvalue has joined #u-boot
<sjg1>
qschulz: I use sdwire in my lab and sometimes at computer and it works well. They are fairly cheap (I made a hundred and sold some to defray the cost)
<xypron>
Flole: vagrantc: The Armbian image boots fine via EFI using upstream U-Boot. The problem only exists with the booti command.
<Flole>
I'm pretty sure I tried bootm aswell and that didn't work either (the default armbian script also didn't work). I definitely tried "pxe get; pxe boot" and that didn't work either, not sure what "pxe boot" actually does behind the scenes
Gravis_ has joined #u-boot
Gravis has quit [Ping timeout: 246 seconds]
zibolo has quit [Ping timeout: 268 seconds]
<vagrantc>
xypron: that's consistent with my testing
* vagrantc
didn't even know arm64 could do bootm
<vagrantc>
i've only ever seen booti used...
<xypron>
vagrantc: the error seems to be in image_setup_libfdt()
zibolo has joined #u-boot
<cambrian_invader>
vagrantc: I use bootm all the time on arm64; it's great for FITs since you only have to manage one file
<vagrantc>
xypron: so adding "# CONFIG_EFI_LOADER is not set" to the odroid-c2_defconfig ... works around the issue and loading works fine using booti
<vagrantc>
so ... no sure how EFI_LOADER would change the behavior of image_setup_libfdt()
<Flole>
That's exactly what I was about to write ;) I think the EFI stuff installs hooks that are called sometimes?
<vagrantc>
efi_dt_fixup ?
<vagrantc>
lib/efi_loader/efi_dt_fixup.c: if (image_setup_libfdt(&img, dtb, 0, NULL)) {
<Tartarus>
Well, has someone decoded the crash yet?
<Tartarus>
it's very odd that commit in turn causes this, and I feel like it's exposing a latent bug instead, now that link order changed or whatever
<vagrantc>
Tartarus: sorry, haven't done the decoded crash dance yet ... trying to get clarity on what i do know already
ikarso has quit [Quit: Connection closed for inactivity]
<Tartarus>
ok
<vagrantc>
but it's certainly possible that somehow this triggers other bugs
<vagrantc>
i'm also curious why it only appears to affect amlogic boards
rvalue has quit [Ping timeout: 268 seconds]
<Flole>
I assume it has something to do with the "hooks" involved. I guess if you change all the added methods to print out a debug message when they are called you'll see one right before the crash
<vagrantc>
is CONFIG_CMD_EXCEPTION=y needed in order to get the relevent crash dump information?
<Flole>
No, that is a command to cause an exception for testing purposes IIRC
gsz has quit [Ping timeout: 260 seconds]
<Tartarus>
Right, that's just an example one
mncheck-m has joined #u-boot
mncheckm has quit [Ping timeout: 268 seconds]
camus has quit [Remote host closed the connection]
camus has joined #u-boot
camus1 has joined #u-boot
camus has quit [Ping timeout: 256 seconds]
camus1 is now known as camus
<xypron>
Tartarus: Loading Ramdisk to 7a896000, end 7bf3eb78 overwrites internal memory structures of the EFI subsystem which leads to the crash on the Odroid C2. Why do we copy initrd to high memory at all?
<xypron>
vagrantc: Tartarus: setenv initrd_high 0xffffffffffffffff; setenv fdt_high 0xffffffffffffffff solves the problem on the Odroid C2
<xypron>
Tartarus: If linux does not need initrd in high memory on ARM64, we should get rid of it. For riscv64 it is definitively superfluous.
<Tartarus>
But you are not allowed to disable fdt relocation
<Tartarus>
and disabling initrd relocation is iffy
<Tartarus>
but thanks for figuring out what's going on