mripard has quit [Remote host closed the connection]
mripard has joined #u-boot
mckoan is now known as mckoan|away
mmu_man has quit [Ping timeout: 245 seconds]
goliath has joined #u-boot
mripard has quit [Quit: mripard]
mmu_man has joined #u-boot
frieder has quit [Remote host closed the connection]
ezulian has quit [Ping timeout: 252 seconds]
Clamor has joined #u-boot
Clamor has quit [Quit: Clamor]
Clamor has joined #u-boot
Clamor has quit [Client Quit]
Clamor has joined #u-boot
<Tartarus>
sjg1: What is buildman doing when it shows "(starting)" ?
vagrantc has joined #u-boot
sng has joined #u-boot
<Tartarus>
And, ah, there we go, yes, buildman can do TI K3 platforms if we update the file list in builderthread.py for keep outputs for more things, or if we had an option to just actually keep all outputs (and make it require -P)
persmule has quit [Ping timeout: 246 seconds]
matthias_bgg has quit [Quit: Leaving]
sng has quit [Remote host closed the connection]
sng has joined #u-boot
soxrok2212 has quit [Ping timeout: 244 seconds]
soxrok2212 has joined #u-boot
valdemaras has joined #u-boot
ezulian has joined #u-boot
alan_o has quit [Ping timeout: 246 seconds]
alan_o has joined #u-boot
vagrantc has quit [Quit: leaving]
Clamor has quit [Ping timeout: 256 seconds]
Clamor has joined #u-boot
<Tartarus>
JPEW: re the GPT series, you're running the sandbox tests at least locally, if not firing off CI?
Clamor has quit [Ping timeout: 252 seconds]
Clamor has joined #u-boot
<JPEW>
Tartarus: Ya, I ran all the GPT sandbox tests
<sjg1>
Tartarus: Yes it has always annoyed me too. See _prepare_output_space() it does not add a newline to the message, so perhaps it never gets sent to stdout?
<Tartarus>
sjg1: Well what is it doing for those extra 5s?
<sjg1>
marex: Probably tgat fdtdec function assumes that the address size is the same as fdt_addr_t
<Tartarus>
tho I guess I need to re-run later, I didn't notice gitlab was going heree
<sjg1>
Tartarus: I actually don't see that problem
<Tartarus>
sjg1: More importantly I guess, can we re-working --keep-outputs to just keep everything and not do whatever is going on atm?
<sjg1>
Tartarus: Could it be doing the maintainers check?
<Tartarus>
sjg1: Yeah, that's it.
<sjg1>
Tartarus: OK I will send a patch
<sjg1>
Tartarus: Re keep outputs, what do you mean by everything? The entire build output including object files, etc.?
<Tartarus>
sjg1: Yeah, that's easier than an ever-growing list
<sjg1>
Tartarus: It's about 0.1GB per build, so 130GB in total for all boards
<Tartarus>
Yes, if someone says they want to keep all outputs, they probably wanted all of the outputs
<Tartarus>
I know I've had to go hack up the list when I've wanted to build the world and keep things
<Tartarus>
Or we accept that buildman isn't generally the right tool for "build something bootable"
<sjg1>
Tartarus: I normally use -w -o <dir> for that. Would it be useful to have a list somewhere (in the source tree, outside of buildman) of what output files there are? I have been thinking for a while that binman needs that, e.g. for make cleab
<sjg1>
Tartarus: Perhaps for now I can add '--keep-build' to copy everything out of the build?
<Tartarus>
Uh, -w, ok, let me see...
<Tartarus>
ugh, no, -w only works for a single boar
<Tartarus>
And binman littering the source directory is a different problem
<Tartarus>
I would have expected -P -w to be allowed, fwiw
<sjg1>
Tartarus: yes -w is just for one board...so --keep-build ?
<Tartarus>
sjg1: I don't know, I guess it depends on how important covering cases of buildman being used outside of CI are
flom84 has joined #u-boot
<sjg1>
Tartarus: I think it is important, since the closer that is to real life the more CI is testing real life
<sjg1>
Tartarus: But how are you going to deal with all the different TEE vars, etc. that each board will need? We don't have that defined anywhere
Wouter0100670440 has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
<sjg1>
Tartarus: afk for a bit
<Tartarus>
Oh goodness, no, I don't mean that we should allow for buildman to work for "k3"
<Tartarus>
But --boards j721e_evm_r5,j721e_evm_a72 could work if we globbed in *itb and *_unsigned, as further special cases like "MLO"
<Tartarus>
We catch tiboot3.bin as we glob *.bin, but not tiboot3.bin_unsigned (what I need and iirc beagleplay needs)
<Tartarus>
Doing 2x make -j8's ends up being faster than make -j16, make -j16 by 10s or so, even with the time the maintainer check takes up
Clamor has quit [Ping timeout: 252 seconds]
Clamor has joined #u-boot
<sjg1>
I think all output binaries should have a .bin extension. I suppose binman could enforce that
<marex>
sjg1:
<marex>
- base = fdtdec_get_addr(gd->fdt_blob, dev_of_offset(dev),
<marex>
+ base = fdtdec_get_int(gd->fdt_blob, dev_of_offset(dev),
<marex>
- "ping-expect");
<marex>
+ "ping-expect", -1);
<marex>
one down, one to go
<marex>
Tartarus: I wonder whether we should add everything that is in U-Boot and untested into CI with allow_failure: true , so it can be fixed over time
<Tartarus>
sjg1: I think if you want to enforce that you need to fix the TI ones just about now as that's not in a release just yet...
<Tartarus>
marex: I don't want to do that as CI failing tests suddenly has caught problems
<Tartarus>
marex: Right, OK. But my concern is that anything short of loud screaming failures leads people to assume things are fine. So unless we can instead give pytest a list of (temporary) expected-failures, I worry regressions will come
<Tartarus>
sjg1: I've signed up for notifications and set a due date of v2023.10
<marex>
Tartarus: right now, it is fine coz it is not even a warning ;)
<Tartarus>
Because otherwise it's in the wild that _unsigned is allowed
<marex>
Tartarus: btw do you know why I'm fixing this sandbox64 in CI?
<Tartarus>
marex: It's "fun"? :)
<marex>
Tartarus: not really ?
<marex>
Tartarus: but someone mentioned we should CI check sandbox64 at some point, and I think it was you , but I am not sure
<Tartarus>
Probably me, yes
<Tartarus>
So thanks
<marex>
Tartarus: ah, good, I blame you then !
<Tartarus>
Maybe some of your fixes here will fix ASAN too
<Tartarus>
I won't honestly tempt you to fix sandbox64 + ASAN
sng has quit [Read error: Connection reset by peer]
slobodan has quit [Read error: Connection reset by peer]
<marex>
resistance is futile
<Tartarus>
just sandbox64 + clang, once sandbox64 is fine, as that _should_ be fine too
sng has joined #u-boot
<marex>
Tartarus: did ASAN explode on that fwu cesspool ?
flom84 has quit [Remote host closed the connection]
<Tartarus>
Doesn't get as far as fwu
slobodan has joined #u-boot
<Tartarus>
I honestly forget if there's a good reason it's in Azure only and not GitLab
<marex>
jeeze, I have this sandbox64 stuff in tree since March
<marex>
Tartarus: I think it will go full on BOOM on fwu
<marex>
Tartarus: that lib stuff there is crap supreme
flom84 has joined #u-boot
flom84 has quit [Ping timeout: 248 seconds]
prabhakarlad has joined #u-boot
<marex>
Tartarus: passed, woohoo
<Tartarus>
nice
slobodan has quit [Quit: Leaving]
<NishanthMenon>
Tartarus: sjg1 Tartarus: on the CFG_EXTRA_ENV_SETTINGS what would you like me to do?
<xypron>
Currently we hard code available TPL/SPL boot devices in board_boot_order() and spl_boot_device(). Wouldn't it be preferable to move this to customizing? Especially on boards with m.2 or other PCIe connectors it should be the users choice to support the devices he has plugged in without modifying the code.
<sjg1>
marex: Nice!
<marex>
sjg1: thank you for your help with it
<sjg1>
marex: :-)
<sjg1>
NishanthMenon: Can you move it to standard boot? It seems to have a lot of boot scripts which are not distro_boot either?
<NishanthMenon>
sjg1: ok. Will try.
<sjg1>
NishanthMenon: Where are you setting CFG_EXTRA_ENV_SETTINGS ?
<sjg1>
NishanthMenon: If/when you fail, please let me know what you are missing and I might be able to help
<NishanthMenon>
It comes from the ti_armv7_common.h stuff we added in years back for distroboot.
rvalue has quit [Read error: Connection reset by peer]
<NishanthMenon>
sjg1 Let me give it a shot. I might need to work on it late tonight, but will try. Any good reference as to how it should look like?
rvalue has joined #u-boot
<sjg1>
Ideally it should boot automatically with nothing but the basic env vars like kernel_addr_r etc.
Clamor has quit [Read error: Connection reset by peer]
<Tartarus>
NishanthMenon: It would be good to convert more TI stuff to bootstd, yes, and I think I had pointed Jon at it in general 6 months ago or so, as it's distro boot but with tests too, to some extent.
<marex>
xypron: hrhr
<Tartarus>
xypron: Not immediately sure that's an easy / great change, no.
<xypron>
Tartarus: How do we get that TPL/SPL mess cleaned up? Is there any maintainer for PowerPC left?
<marex>
RED ALERT
<Tartarus>
I know I've seen a thing or two that puts a "chooser" of some sort on SPI, and then you can more easily do SD or SATA or whatever for the next stage, without having to reflash, on devices that didn't make it easy to choose where to start booting from
<marex>
Tartarus: why not stick the boot order into /config node in DT ?
<marex>
xypron: ^
<Tartarus>
xypron: We ignore it like we've ignored it for the last decade or so, it's not a high priority to go whack powerpc
<xypron>
marex: that would just move from one sort of code to another. The question is if on QEMU a user without coding should be able to choose a boot method like SPL_SEMIHOSTING or whatever he wants to try.
<Tartarus>
xypron: That should work as is today
<Tartarus>
If it's not on $foo but is on $bar, it won't find it on $foo and move on to $bar
<marex>
xypron: ah
<Tartarus>
If you want SPL on $foo and U-Boot on $bar, that needs more thought
<marex>
xypron: can qemu pass the preferred boot order through, somehow ?
<xypron>
Tartarus: On qemu-riscv64_spl_defconfig the itb file can currently only be loaded from RAM and I cannot change that in configuration.
<Tartarus>
What's the itb file?
<xypron>
marex: QEMU creates a device-tree with the available devices but you cannot add arbitrary nodes.
<Tartarus>
Again, SPL on $foo but U-Boot on $bar isn't supported and needs thought
<xypron>
Tartarus: on QEMU currently my itb file is EDK II and OpenSBI.
<Tartarus>
Sounds like semihosting is just a special case
<marex>
xypron: cant qemu generate that /config node
<marex>
?
<marex>
I mean, patch qemu ?
<xypron>
Tartarus: SPL on qemu-riscv64_spl_defconfig can load from SATA, USB, SCSI, MMC, ... if you just change that one function hardcoding that only RAM is available.
<marex>
ah
sukrutb has quit [Remote host closed the connection]
<xypron>
marex: Shall I patch QEMU for each test I run?
<marex>
xypron: does qemu pass the currently configured boot media to the software running in qemu then ?
<marex>
xypron: if so, SPL can just parse that information and pick the correct next stage boot media, no ?
<xypron>
marex: QEMU passes the available device in ACPI and DT. But it does not know what U-Boot is.
<xypron>
You can pass any binary as -bios.
<marex>
xypron: so SPL can parse the DT and determine the boot order from that ?
<xypron>
marex: how should QEMU know from which device I want to load EDK II?
<marex>
xypron: I dont know ? :)
<marex>
xypron: you somehow pass a parameter to qemu to indicate that ?
<NishanthMenon>
ok - i need to see what happened to the fdtfile.. extlinux was picking it up previously with distro_bootcmd
<Tartarus>
And I assume that /extlinux/extlinux.conf says to use /dtbs/k3-am62.dtb
<NishanthMenon>
Tartarus: no, it does'nt provide the dtb name. expectation is u-boot provides it.. maybe i need to run the findfdt thingy
<Tartarus>
What you really want, eventually, is to just have the in-use dtb be passed along :)
<NishanthMenon>
yeah - that is exactly what it did.. and it does come up just fine ;)
tixlegeek has joined #u-boot
<NishanthMenon>
though in reality the u-boot and kernel updates happen independent of each other.. i'd rather want kernel packages to update the dtb
<sjg1>
NishanthMenon: Can you set fdtfile to the current value of default_device_tree, then get rid of default_device_tree and findfdt
<sjg1>
?
<Tartarus>
sjg1: That gets back, a bit, to how to handle more than one device in a defconfig/config fragment
<NishanthMenon>
i wish - eventually the dang board combinations come into play.. (beagleplay will eventually have a new rev once we run into sourcing issues)
<Tartarus>
board/ti/am62x/ supports many platforms
<NishanthMenon>
but that is a fight for another day - let me keep it simple for now..
<sjg1>
Hmm so you are using a CONFIG in the config fragment to set the fdt name?
<Tartarus>
sjg1: separate env file for beagleplay build, per CONFIG_ENV_SOURCE_FILE
<sjg1>
OK, so that can set fdtfile?
<Tartarus>
But as Nishanth said, that's only gonna work until it has to change because of sourcing issues (new LCD, whatever)
<NishanthMenon>
DDR, RTC, SoC type, Ethernet PHY are current suspects that might trigger a review
<sjg1>
So different DTs rev-1.dts, rev-2.dts, etc.?
<NishanthMenon>
yup
<NishanthMenon>
brb.. need moar coffee
<NishanthMenon>
and we have bootup.. Thanks Tartarus sjg1.. let me cleanup the series and send it out for review and lets iterate again if needed https://www.irccloud.com/pastebin/2xMzO3nE/
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
vagrantc has quit [Quit: leaving]
soxrok2212 has quit [Quit: Who ate my gummy worms?]