warpme_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
memset has quit [Remote host closed the connection]
memset has joined #u-boot
memset_ has joined #u-boot
K900 has quit [Remote host closed the connection]
memset has quit [Ping timeout: 263 seconds]
K900 has joined #u-boot
jclsn has quit [Ping timeout: 250 seconds]
sszy has joined #u-boot
jclsn has joined #u-boot
memset_ has quit [Remote host closed the connection]
persmule has quit [Quit: Leaving]
memset has joined #u-boot
warpme_ has joined #u-boot
persmule has joined #u-boot
memset has quit [Remote host closed the connection]
mtoy has quit [Ping timeout: 262 seconds]
memset has joined #u-boot
mtoy has joined #u-boot
memset has quit [Remote host closed the connection]
memset has joined #u-boot
memset has quit [Read error: Connection reset by peer]
memset has joined #u-boot
warpme_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
warpme_ has joined #u-boot
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
memset has quit [*.net *.split]
persmule has quit [*.net *.split]
warpme_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
warpme_ has joined #u-boot
jclsn has quit [Ping timeout: 251 seconds]
jclsn has joined #u-boot
gsz has quit [Ping timeout: 248 seconds]
patersonc has joined #u-boot
slobodan has joined #u-boot
warpme_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
warpme_ has joined #u-boot
Stat_headcrabbed has joined #u-boot
mmu_man has joined #u-boot
Stat_headcrabed1 has joined #u-boot
warpme_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
warpme_ has joined #u-boot
Stat_headcrabbed has quit [Ping timeout: 251 seconds]
Stat_headcrabed1 is now known as Stat_headcrabbed
warpme_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
warpme_ has joined #u-boot
warpme_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
warpme_ has joined #u-boot
draemon has joined #u-boot
<kcxt>
qcom engineers are submitting a lot of defconfigs lately for new platforms, where they keep wanting to add a defconfig per-board even when the only change is which DT is appended to the U-Boot binary
<kcxt>
I've been pushing back a bit because I don't want to needlessly inflate the world build CI, but it does seem like there is a more general problem here
<kcxt>
If there was a way to easily just have configs be opted-out of the world build (maybe a magic comment at the top?) then I think it would be nice to make the process more intuitive rather than saying "well you should run make DEVICE_TREE=..." (although really I don't think that's a huge deal)
<kcxt>
but I wonder if we could find a better UX for this somehow, like separating out platform configuration with board-specific configuration
<BtbN>
If only there was a system invented to not have to hardcode each individual piece of hardware.
<kcxt>
but uhhh not reinventing board/ XD
<kcxt>
yoo pro-ACPI propaganda?! in my U-Boot channel?! /j
<BtbN>
Like, our new Ampere servers manage to boot a bog standard kernel without a DT
<kcxt>
alas we are stuck with it for the foreseeable future
<BtbN>
I guess u-boot could provide it, to a degree. So at least the actual OS does not need one anymore.
<BtbN>
Doesn't solve the problem of DT inflation in u-boot though
<BtbN>
The naive idea would be to just bake all the DTs into one image, and have some form of criteria to identify which system we're booting on
<kcxt>
anyhow, I wonder if it would make sense to add some friendly board name mappings, we could have an ini file in board/$VENDOR that would just map a friendly name to a DT name and let you run "make board=fairphone-fp5" or something like that?
warpme_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<kcxt>
BtbN: heh yeah I've looked into that idea a few times, but without a properly agnostic detection mechanism you risk tripping a bus or something :/
<kcxt>
there's also the issue of DTBs being way too got dang LARGE, although they compress down pretty good
jclsn has quit [Ping timeout: 274 seconds]
<BtbN>
Would need to be limited to some family of boards/chips, yeah
<kcxt>
I'm hopeful that when we resolve a lot of the tech-debt with how U-Boot handles relocation and MMU configuration we would be in a much better (and faster) position to justify the cost of fancy dynamic detection
jclsn has joined #u-boot
<BtbN>
And needs a reliable way to detect what board you're on. I guess there is no reliable way to read a model number?
<apalos>
you can from the dt :D
<BtbN>
Well
<apalos>
yea yea i know
<kcxt>
really depends on if the vendor in question actually programmed stuff properrly, on qcom there's an in-memory database with soc/ddr/etc info and that's about all we can rely on... Except on phones where u-boot is chainloaded and we can parse the DT that was provided to us by the bootloader
<apalos>
kcxt: but your problem sounds like a build only issue
<kcxt>
yeah not getting sidetracked too much XD
<apalos>
iow if they want to bundle many DTs in a single file reselecton boot, then you *need* a binary with the corresponding DT
<BtbN>
Though I guess it really just moves the burden to someone else
<BtbN>
at some point, there'll need to be firmware with some form of DT-Like thing, that can then provide that to the later stages
<BtbN>
And I think I'd rather have that be u-boot than a proprietary vendor UEFI blob
<apalos>
kcxt: in op-tee we have a board flavor on the makefile.
<kcxt>
also feel like im overcomplicating things by proposing some config thingy but honestly it would be nice to be able to get a list of all the supported *boards* and have that just map to a defconfig + DT
<apalos>
which sounds similar to what you suggest with the ini file
<kcxt>
especially now that we vendor upstream DT and a bunch of boards work without needing any explicit patches to u-boot
<BtbN>
kcxt: that's how I think it worked when I built for my BananaPi
<BtbN>
There was just one defconfig for BPi in general, and a few overlay-configs with the few options that changed for a specific one
<kcxt>
apalos: yeah seems similar, the op-tee way is pretty cursed iirc but i like the rough idea
<apalos>
I dont see another way out tbh
<kcxt>
u-boot already has some of the infra for this too right? like buildman does a bunch of kconfig parsing magic
<apalos>
you either need a big DT and some kind of descovery, or you need a per board fw
<apalos>
with its own DT etc etfc
<apalos>
I dont remember honestly, Tom will probably remember that
<kcxt>
although I feel like I'd really be fine with a fixed definitive list rather than trying to figure this all out dynamically, i just wanna be able to say "build me an image for this target" and it does it -- heck adding metadata to defconfigs would also be a fine solution
<kcxt>
but would also mean way more defconfigs which might be more annoying to deal with when the only differences between them are the DT
<apalos>
it shouldn't be annoying,
<apalos>
you will include a base config in every board and then just change the DT,
<apalos>
e,g configs/qemu_arm64_lwip_defconfig
<kcxt>
yeah, it would be nice to have different defconfigs represent concrete differences in the image though rather than superfluous stuff
<kcxt>
we have something similar in tauchgang already
<kcxt>
it's neat and tidy and has all the metadata we need not just to build u-boot but also do the post-processing so it's ready to flash
<kcxt>
also being able to compose a defconfig with an optional fragment (like for phones) is a nice feature, being able to have that presented as an option or a default rather than having to look through the docs to even know it exists would be sweet
<BtbN>
i.e. Linus seems to have been annoyed by the same problem 16 years ago
<kcxt>
heck maybe just upstreaming some of the tauchgang config stuff would make sense?? We could also supplement U-Boots gitlab-ci.yml so you could trigger a pipeline with a UBOOT_BUILD_BOARDS="abc def" env var and it would just build images for those boards rather than the normal CI, might be a nice to have for downstreams
* kcxt
thinking a bit too far ahead already
<kcxt>
BtbN: lol that's so relevant
<BtbN>
I wonder if his idea to solve it works on u-boot
<kcxt>
well the aspect of dropping platform specific drivers in favour of generic ones is something I've prioritised for mach-snapdragon from the start
memset has joined #u-boot
<BtbN>
I was more thinking of the dropin KConfig file
<kcxt>
ah i see, i mean we do that with config fragments nowadays
draemon has quit [Ping timeout: 248 seconds]
<kcxt>
and also something quite similar in arch/arm/Kconfig, the ARCH_SNAPDRAGON config option selects a lot of stuff
draemon has joined #u-boot
memset has quit [Remote host closed the connection]
memset has joined #u-boot
ninelore has quit [Ping timeout: 243 seconds]
ninelore has joined #u-boot
gsz has joined #u-boot
persmule has joined #u-boot
<shadow>
kcxt: in certain situations the same firmware image could be used for a range of boards
<shadow>
kcxt: this is done for the starfive_visionfive2_defconfig which runs on a range of boards that are variants of the StarFive VisionFive 2 reference design
<shadow>
at U-Boot SPL runtime some eeprom value is parsed out and the fdt is selected from multi-fit
<shadow>
the semantics of this should probably use the compatible as the "friendly name" you are suggesting
<shadow>
further I would want a more plastic selection of the devicetree path so that it could be forced to refer to a local Linux Kernel source tree in the developer workflow
<shadow>
at the moment all throughout u-boot source tree are references to $(srctree)/dts or $(srctree)/$(ARCH)/dts hard-coded
<shadow>
rather $(srctree)/arch/$(ARCH)/dts hard-coded
haritz has joined #u-boot
haritz has quit [Changing host]
haritz has joined #u-boot
<shadow>
in that scenario if you want to quicken build times (not building all dts everywhere forever); for example you only care about one architecture or platform, then the KConfig is set at build time to only scan some specific srctree directory for dts which narrows the search
<shadow>
also there would be that specifier for the compatible ( since an SoC level compatible will match a range of board name compatible properties) and allowlist denylist additional compatible lists for reducing the code size
<Tartarus>
kcxt: So on the one hand, the other device tree option could just be in a config fragment, tegra does this now. On the other hand, things not in the world build can break on say dt re-syncs as they aren't built every time
warpme_ has joined #u-boot
<Tartarus>
Then wrt run-time selection, I assume that part of the magic of ACPI+UEFI is that at some point there is a machine-specific build, otherwise we too could do more runtime detection + selection of the correct DTB, as we do support that and have examples of it, when there is enough space for a few, but not N, dtb files
mmu_man has quit [Ping timeout: 258 seconds]
<Tartarus>
The partial FIT image load stuff may provide an option there, in some cases, to support a larger N
<shadow>
producing a board-specific U-Boot SPL that operates with the same U-Boot main app ? so, one build action can output many board-specific U-Boot SPL but just one U-Boot main app?
<shadow>
that would make distro packaging much easier
<Tartarus>
As a concept, yes
<Tartarus>
As a build option, it would require some real work I think. I talked about it a time or two, a few years ago, as part of a larger restructure of how we build things.
memset has quit [Remote host closed the connection]
memset has joined #u-boot
macromorgan has joined #u-boot
<kcxt>
Tartarus: if the only change is DT it's still tested in the world build since we build all upstream qcom DTBs for all platforms
<Tartarus>
kcxt: Ah, well then, the config fragment way is probably best then
<Tartarus>
Which I see you're already doing in some cases
<Tartarus>
... so I need coffee, and if you have feedback on how to improve that / what the drawbacks are, I'll check back in a bit (also need to go run an errand in a moment)
dsimic has quit [Ping timeout: 266 seconds]
warpme_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
dsimic has joined #u-boot
<kcxt>
Tartarus: yeah it would be the simplest immediate solution. I do think there is a case to be made for a more friendly build config frontend though, like for my example above if you want to build U-Boot for the Fairphone 5 then you're using qcom_defconfig + qcom-phone.config + selecting the appropriate DT and this is only communicated through docs. Being able to describe this configuration in a
<kcxt>
searchable and machine readable format would make it easier for users who just want to tinker with U-Boot for their specific board to get up and running, it would act as a concrete list of supported (i.e. tested) boards since many "just work" but it's not well documented which, and we could then generate nice docs with a list of targets with their model name, configs, dt, etc
jclsn has quit [Ping timeout: 242 seconds]
jclsn has joined #u-boot
<kcxt>
obviously things like documentation (at least for qcom) could and should be improved regardless, but I for one greatly appreciate when the build system let's me simply declare the output I want without having to grapple with the implementation details, i think it greatly reduces the barrier of entry for new contributors as well
<kcxt>
arguably buildman is doing some of this already, although it also does a lot of other things that are more developer focused. Perhaps it could just be extended to achieve this
Net147_ has quit [Quit: Quit]
Net147 has joined #u-boot
Net147 has joined #u-boot
Net147 has quit [Changing host]
trix2 has quit [Ping timeout: 244 seconds]
mmu_man has joined #u-boot
trix has joined #u-boot
mmu_man has quit [Ping timeout: 249 seconds]
mmu_man has joined #u-boot
warpme_ has joined #u-boot
memset has quit [Remote host closed the connection]
memset has joined #u-boot
mmu_man has quit [Ping timeout: 247 seconds]
warpme_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
warpme_ has joined #u-boot
warpme_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
warpme_ has joined #u-boot
___nick___ has quit [Ping timeout: 247 seconds]
warpme_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
mmu_man has joined #u-boot
warpme_ has joined #u-boot
goliath has joined #u-boot
warpme_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
warpme_ has joined #u-boot
memset has quit [Remote host closed the connection]
___nick___ has joined #u-boot
memset has joined #u-boot
warpme_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
m has quit [Quit: WeeChat 4.10.0]
m has joined #u-boot
jclsn has quit [Ping timeout: 254 seconds]
jclsn has joined #u-boot
warpme_ has joined #u-boot
warpme_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
warpme_ has joined #u-boot
riz has joined #u-boot
<riz>
I have a small crash-avoidance patch (usb keyboard plugged in at boot can cause a crash) but in 10 minutes of poking around on u-boot-project.org I can't figure out how/where to submit it for consideration. Suggestions? :)
dlech has quit [Remote host closed the connection]
warpme_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<Tartarus>
kcxt: OK, yeah. And Simon has talked before about wanting some way to say what fragments are valid for what configurations, for buildman, but to me that runs in to other issues (since some fragments are quite widely valid) and then potentially a merge-conflict heavy file. I do also worry about adding even more tasks to buildman itself as it's already doing a lot and not something most users should even be bothering with.
<Tartarus>
Thinking out loud, perhaps some new make target that looks at board/*/*/...something-new to see how to fully configure a build for $board ?
vagrantc has joined #u-boot
Dr_Who has quit [Quit: So long and thanks for all the bits.]
jclsn has quit [Ping timeout: 260 seconds]
jclsn has joined #u-boot
ldevulder has quit [Ping timeout: 248 seconds]
user890104 has quit [Read error: Connection reset by peer]
jclsn has quit [Ping timeout: 246 seconds]
jclsn has joined #u-boot
user890104 has joined #u-boot
srk has quit [Ping timeout: 253 seconds]
<marex>
riz: and it is basically the same as linux kernel guidelines
<marex>
riz: how did you achieve empty stdin variable there ?