<vagrantc>
my biggest troubles last i tried u-boot+grub-efi were there was no good way to load the appropriate .dtb from the matching kernel for arbitrary devices ... you either loaded u-boot's or a single dtb file ... which makes it hard to have a boot media work on multiple boards
<vagrantc>
sjg1: yeah, i look forward to playing around with bootstd :)
<sjg1>
vagrantc: Well Tianocore supports FIT now, sort of, so perhaps the world will finally DTRT? No...it's much more likely that UKI and grub will just grow some more code :-)
<vagrantc>
even though it bit me once so far :)
<vagrantc>
i think u-boot's extlinux handling was good enough for most of what i wanted most of the time that i did not spend too much time fighting with newer "better" things :)
<vagrantc>
seem to recall grub was much slower as well than u-boot ... but these things change for better and/or worse :)
<vagrantc>
and as for real world application... i pretty much only do this stuff to add support for distros ... i outsource real-world to other people with interesting creative ideas and stuff. :)
<shadow>
there is the 'fdtfile' U-Boot env variable which can override the search path, but is not a direct push of the dtb data itself; similar within EFI you can define the boot entry with an Fdt option at a path for the dtb file
<shadow>
I agree it's a bit of a logical mess.
<shadow>
U-Boot can't know what the user might choose in some secondary menu that boots (i.e.) Linux
<vagrantc>
the fdtdir option is what allows loading a kernel with a matching .dtb ... otherwise you have to specify for a specific board
<vagrantc>
but yeah, mess is a pretty consistent description over the years, even though it keeps adding things that might make it less messy in theory :)
<vagrantc>
anyways ... will be pokign at this stuff more as debian is edging towards freezing again and i hate to fall so far behind :)
<shadow>
you mention many boards, so is there always some data storage where an EFI variable store could exist?
<vagrantc>
nah, that would be too practical
<vagrantc>
i've accumulated boards over the years, partly what ever seemed shiny at the time, partly to build out a really sad build zoo for reproducible builds. :)
* shadow
:) vagrantc
<vagrantc>
the build zoo is struggling and moving towards, surprise, more server class hardware... so more boards just supporting EFI oput of the box and such
<vagrantc>
and now i really must depart...
* vagrantc
rolls off into the distance
vagrantc has quit [Quit: leaving]
Forty-Bot has joined #u-boot
<sjg1>
Vagrantc so you don't use FIT either?
ikarso has quit [Quit: Connection closed for inactivity]
LainExperiments4 has quit [Quit: Client closed]
Forty-Bot has quit [Read error: Connection reset by peer]
joeskb7 has quit [Remote host closed the connection]
joeskb7 has joined #u-boot
mrnuke has quit [Ping timeout: 245 seconds]
mrnuke has joined #u-boot
LainExperiments has joined #u-boot
zibolo has quit [Ping timeout: 265 seconds]
zibolo has joined #u-boot
Daanct12 has joined #u-boot
Daanct12 has quit [Read error: Connection reset by peer]
Daanct12 has joined #u-boot
Forty-Bot has joined #u-boot
mmu_man has quit [Ping timeout: 264 seconds]
Jones42_ has joined #u-boot
Jones42 has quit [Ping timeout: 248 seconds]
LainExperiments has quit [Quit: Client closed]
Daanct12 has quit [Ping timeout: 252 seconds]
Daanct12 has joined #u-boot
macromorgan has quit [Ping timeout: 272 seconds]
macromorgan has joined #u-boot
zsoltiv_ has quit [Ping timeout: 244 seconds]
monstr has joined #u-boot
pericycle has quit [Ping timeout: 260 seconds]
Daanct12 has quit [Quit: WeeChat 4.4.4]
Daanct12 has joined #u-boot
pericycle has joined #u-boot
rvalue has quit [Ping timeout: 252 seconds]
monstr has quit [Ping timeout: 252 seconds]
mmu_man has joined #u-boot
jfsimon1981 has quit [Remote host closed the connection]
warpme has joined #u-boot
mmu_man has quit [Ping timeout: 248 seconds]
ldevulder has joined #u-boot
monstr has joined #u-boot
warpme has quit [Read error: Connection reset by peer]
warpme has joined #u-boot
prabhakalad has joined #u-boot
sszy has joined #u-boot
<qschulz>
marex: mmm so you can combine configs? Does this work with vanilla OE and U-Boot?
<qschulz>
what does your fit image looks like for the configuration?
rvalue has joined #u-boot
rvalue has quit [Ping timeout: 244 seconds]
<qschulz>
mmmm, probably something related to "Overlayed FDT requires relocation" I get in the logs :)
rvalue has joined #u-boot
<marex>
qschulz: re does that work, it seems it does, I use nothing but ...
<marex>
qschulz: ah the relocation thing ... there was something about that
<marex>
but I thought that was fixed already
<qschulz>
do you have an its, a boot log and the output of mkimage -l fit you could share by any chance?
<marex>
qschulz: no, but lemme build it real quick
<qschulz>
I'm rebuilding an itb with multiple fdt in a config node, this is supposed to work IIRC
<qschulz>
marex: if it works, would be nice to have the content of the environment too, maybe something's missing or improperly set
<marex>
qschulz: that is the fix 4c531d9f58b1 ("fit: Load DTO into temporary buffer and ignore load address")
Daanct12 has quit [Read error: Connection reset by peer]
<marex>
qschulz: I am not combining multiple fdt in config node, I have one fdt per one config node entry
<qschulz>
marex: then it broke again, because I tested on v2024.07 and current master
<qschulz>
separate config node or one config node with multiple fdts...
<marex>
qschulz: 2024.07 is what ships with the dhsom now, so that has to work
<marex>
on both arm32 and arm64
rvalue has quit [Ping timeout: 265 seconds]
<marex>
qschulz: lemme send you the its file, build is running , apparently something got updated and that triggered a lot of rebuilding
<qschulz>
marex: how are you booting your fit?
<qschulz>
manual loading into DRAM and then bootm?
<marex>
pretty much, I source an embedded boot script though
<qschulz>
mmmmmm
<qschulz>
I'm testing with extlinux
<qschulz>
so I assume it may only be extlinux being broken
<marex>
that one does the DTO application by passing some #conf-...#conf-... list to the bootm
<qschulz>
marex: you do have a load entry for your fdt, which I don't have
<qschulz>
s/load entry/load property/
Daanct12 has joined #u-boot
<marex>
qschulz: huh, that's still there for backward compatibility from ancient times, I don't think it should be there
<marex>
s/should/has to/
<qschulz>
also fails with bootm from DRAM directly
<qschulz>
with load property, it works
<marex>
huh
<marex>
qschulz: that is not supposed to make a difference
<qschulz>
marex: Data Start reported by bootm is right within the fitImage
<marex>
qschulz: did 4c531d9f58b1 ("fit: Load DTO into temporary buffer and ignore load address")
<marex>
broke ?
<qschulz>
I assume trying to do zero copy/reloc
<marex>
qschulz: wait ... what IS your data start , is it aligned to 4 Bytes ?
<marex>
qschulz: did you create the fitImage with mkimage -E or without -E ?
<qschulz>
marex: what is your question exactly? that the commit broke the behavior or that something broke that commit?
<qschulz>
marex: mkimage -v -f fit.its fit
<marex>
qschulz: the later -- something broke the commit
<marex>
qschulz: try and add -E to that list of options
<marex>
qschulz: does that magically "fix" it ?
<marex>
-E will guarantee 8 Byte alignment of that DTO within the fitImage iirc
<marex>
it will also place the DTO past the fitImage tree
Daanct12 has quit [Ping timeout: 252 seconds]
<qschulz>
marex: that seems to have made the trick....
<marex>
qschulz: so yeah, alignment is the problem
<marex>
qschulz: but why is it zero-copy accessing the DTO in tree ?
<qschulz>
marex: is there nothing we can do in U-Boot to provide a better error message?
<qschulz>
marex: I don't know if that's the case, just that Data Start as reported by bootm is within the fitImage if I don't provide a load property in the fit
<marex>
qschulz: I think what we should do is find why this zero-copy happens AND then trigger the fdt_open_into() part of code which allocates properly aligned buffer and opens DTO into it instead
<marex>
why does the following code NOT relocate the FDT to the end of DRAM ?
<marex>
2366 fdt_noffset = fit_image_load(images,
<marex>
2367 addr, &fit_uname, &fit_uname_config,
<marex>
2368 arch, IH_TYPE_FLATDT,
<marex>
2369 BOOTSTAGE_ID_FIT_FDT_START,
<marex>
2370 FIT_LOAD_OPTIONAL, &load, &len);
<marex>
FIT_LOAD_OPTIONAL maybe ?
<marex>
right ... if no loadaddr, fdt is used in place
<marex>
hence in the fitImage place
<marex>
and that is why the check fails ... so, I think what is needed is to relocate the FDT instead of failing ?
<qschulz>
that would be what makes sense to me indeed
<qschulz>
but the DT is relocated after that (see successful boot)
<qschulz>
so I'm a bit lost
<marex>
qschulz: if there is no fdt loadaddr in DT, the DTO code cannot use the base DT (which is still sitting in the fitImage) and modify it with DTOs
<marex>
qschulz: if there is yes fdt loadaddr in DT, the base DT is relocated to that address, can grow, and can be extended with DTOs
<qschulz>
marex: if I align with -E, it still works though
<qschulz>
without the load property in the DTB/DTBO image nodes
<marex>
qschulz: because with -E the DT is outside of the fitImage tree, and I wonder if there might be some corruption happening (separate issue, but worth checking obv)
<marex>
qschulz: check what image_start/image_end are set to for fitImage generated with mkimage -E , I suspect they might span just the tree, not the whole tree+appendedblobs
<sjg1>
Tartarus: Also, several boards in the lab show up failure. What is the best way to promote them for people who might be interested in fixing them?
mmu_man has joined #u-boot
<qschulz>
marex: how would I know **where** to relocate?
<qschulz>
there are a few example usage of boot_relocate_fdt but this takes an address and a length afaict
<qschulz>
darn it, cannot read the docs can't i
<Tartarus>
sjg1: Yes, I didn't bother looking harder at the PXE series since (a) I thought you needed to respin it but (b) didn't think you'd take any of my feedback anyhow
<Jones42>
sjg1: reg. cst: where are the tests supposed to run? as long as binman uses apt, you're at the mercy of whatever distro's package maintainer to provide the proper version
<sjg1>
Tartarus: I virtually always take your feedback, so yes please do comment if you have anything
<sjg1>
Re toradex, do you mean the BUILD_TARGET thing?
<sjg1>
Tartarus: I am leaving the lmb stuff to you, if that's OK
<sjg1>
Tartarus: If you would like me to comment, I can, but I don't have much of an opinion at this stage
<Tartarus>
sjg1: I don't want to ague, again, about the core concept of your "record images for booting" methodology. I still think there's problems with the concept and you can't explain why what I want to see instead is wrong. I'm happy enough to give you leeway there to just show me in the end, but if you're going to fork the project instead so you can also apply your rework of other subsystems that the subsystem maintainers have rejected
<Tartarus>
I don't see the point in reviewing that work, too
<Tartarus>
And re toradex, yes, setting BUILD_TARGET and as needed, fixing up whatever else needs fixing up, as "make all" should work.
<Tartarus>
That's the reason behind BUILD_TARGET and a few other things
Daanct12 has quit [Quit: WeeChat 4.4.4]
LainExperiments has quit [Quit: Client closed]
<sjg1>
Tartarus: I thought you only had an objection to the last two patches for image-recording?
<sjg1>
Tartarus: And that was only because you didn't like the size growth?
<Tartarus>
That was my feedback after saying that I'll set aside everything I had put in earlier threads
<sjg1>
Tartarus: We have a consistent pattern where I am unable to explain my ideas sufficiently
<Tartarus>
I have further, newer, concerns now about your end goal because I don't know if you know all of the corner cases and why some things end up the way they are, and so how to handle them. I know you don't like EFI, but the protocol that was worked out there was how to avoid all of the historical problems.
<sjg1>
Tartarus: We could perhaps restart the regular U-Boot meeting and use that to discuss ideas
<sjg1>
Tartarus: The end goal for bootstd, or something else?
<Tartarus>
sjg1: You've tried to explain on video calls the various EFI problems for example, and that still hasn't ever resolved the "pointers" problem.
<Tartarus>
Nor bloblist things.
<Tartarus>
Which is why I asked you to take some time to do less coding and learn more communication strategies
<Tartarus>
Even if you explain it on a call you still need to be able to explain it in writing because that's what is persistent
<sjg1>
Tartarus: Yes I have great difficulty explaining my intuition on things when they are half-baked. When I explain the vision in the early stages, some people think it is pointless (e.g. bootstd). When I create a series, some people don't see where it is going, etc.
<sjg1>
Tartarus: I'm OK working with that, so long as I can make progress
<Tartarus>
sjg1: Yes, and if you want to make progress you need to learn how to communicate about it when you're done, and also when to leave things alone. Because after we last had this particular go-round, you still grabbed the "pointers" series for your tree
<Tartarus>
Which is a non-starter
<Tartarus>
And I have no idea how in "a year" we'll be able to take some finished idea from your tree, if it depends on dozen other non-starter patch series
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Tartarus>
And bootstd is a great example of where there's still a lot of work to bring it to completion, but you want to move on to the next big thing
<sjg1>
Tartarus: The pointer series should not be this hard to grok. It really just makes EFI use addresses internally, like the rest of U-Boot
<Tartarus>
sjg1: It should also not be this hard to grok that you are perhaps wrong
<Tartarus>
Yet here we are
<Tartarus>
But all the same
<Tartarus>
Just leave it aloe
<Tartarus>
*alone
<Tartarus>
Make sandbox_noefi_defconfig and start your improved boot work on that
<Tartarus>
If in a year you have something great and good and the big hangup is it depends on EFI_LOADER=n
<Tartarus>
That's a whole lot easier to deal with than a dozen things that've been rejected
<sjg1>
Tartarus: I'm not wrong on the address/pointer thing. Look at all the bugs I found. I am pretty sure I could convince you, given the chance
<Tartarus>
Yes, and what sandbox needs to do is rework how it thinks about memory so that we don't need to litter common code with sandbox specific macros, and also don't need to complicate efi_loader code that is written to follow the spec.
<sjg1>
Re EFI, yes I really should leave EFI alone. It would be better for a happy life. But I also should be able to make changes to the internals without such a fuss. Even with !EFI_LOADER, lmb is global now, so you can't get away from it
<Tartarus>
At this point in time, sandbox should be able to be better able to mimic a real platform, malloc 1GB of memory from the host and then handle all of the sanity checking it wants to do under arch/sandbox
<Tartarus>
And I don't know why you can't grok that EFI_LOADER has nothing to do with lmb being global.
<Tartarus>
Which is another worry I have about your loading images boot method stuff
<Tartarus>
I had assumed you understood things that after I finally understand what the heck went on with OF_BLOBLIST I am much less confident about.
<sjg1>
Because, apart from EFI, when images are recorded, it doesn't need to be global. It is just created for each bootflow that gets booted. When something fails to boot, we drop it and try to load and boot the next thing
<Tartarus>
Since you have such trouble explaining what you want
<Tartarus>
sjg1: Wrong. You just re-opened all the stupid CVEs
<sjg1>
Also, the EFI app is something I'd really like to push forward
<sjg1>
I don't understand your OF_BLOBLIST comment?
<sjg1>
For sandbox, it was an early design decision. I have explained why I think it is still the best choice, but I also understand it has costs...so let's look at the trade-offs and discuss it
<Tartarus>
sjg1: That hellthread you re-linked from last year. I re-read it. I see exactly why I thought what I thought, and it's because you didn't communicate at all what your problems were and argued the inverse of the issue. It's more examples of you not being able to communicate what your design is.
<sjg1>
The image thing is just another example of where I can't get my vision across
<Tartarus>
sjg1: It was a fine design decision at the time. It should be re-evaluated now, especially since it would make it easier to test other code too and so forth
<Tartarus>
afk morning routine stuff.
<sjg1>
Tartarus: Sure, I'm fine with that
<sjg1>
For rpi5, does anyone know if it is supposed to bring up a serial console? I see a U-Boot logo on the screen, but no console output (serial nor video)
prabhakalad has quit [Remote host closed the connection]
slobodan_ has quit [Ping timeout: 252 seconds]
totkeks has joined #u-boot
warpme has joined #u-boot
<sakman>
Tartarus: I think those 83xx changes are fine, he might add some info that he tested on 83xx board in one commit message and it is all good. I'll see how we can do it with defines in the near future and run some run-time tests, I think it is fine for now.
<Tartarus>
sakman: OK, thanks again!
<sakman>
np, hope to help a bit more in the near future - perhaps with p2020.
ldevulder has quit [Quit: Leaving]
mripard has quit [Quit: WeeChat 4.4.4]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
polprog has quit [Remote host closed the connection]
totkeks_ has joined #u-boot
totkeks__ has joined #u-boot
totkeks_ has quit [Read error: Connection reset by peer]
<sjg1>
Do you mean that you want to log to a buffer and read it out later?
<marex>
sjg1: yes
<sjg1>
marex: Well you could write something similar to log_console.c which saves the struct log_rec into a bloblist (along with the strings from file, func and msg)
<sjg1>
marex: It would be a nice addition
<marex>
sjg1: OK, so with the current U-Boot logging infrastructure, this is not possible ?
<sjg1>
marex: No, it only supports console (local print) and syslog (network)
<marex>
OK
<marex>
thanks
mrnuke has joined #u-boot
<sjg1>
Tartarus: Any thoughts on moving to Noble in CI? I've been holding off but thinking it might be time to update my computer
<Tartarus>
sjg1: I think the first problem is we can't rebuild tools/binman/entries.rst because of pylibfdt fun
<Tartarus>
And there's maybe still a bunch of python warnings in other tooling that needs to be fixed
<sjg1>
Oh dear. I haven't seen the first problem
<Tartarus>
Yeah, make sure you have a clean venv to try things out in
<Tartarus>
it's some setuptools related horror, iirc
<sjg1>
OK, good to know
<sjg1>
Tartarus: Back to your hellthread comment, yes we both agree I struggle to communicate certain things, or others struggle to understand what I am getting at or why something might be a good idea, or... So is your answer just that I need to do a better job of that?
vagrantc has joined #u-boot
<Tartarus>
sjg1: As much as I wish I could say I had some magic solution here, this is a community project with 153 contributors last release cycle. A novel technical solution that you can't really explain the details of so that others can review is not helpful as only you understand what should / shouldn't be done there. We run in to this with DM stuff, and binman stuff too. So yes, your technical skills are fine and not the problem. Your
<Tartarus>
communication skills are.
eballetbo has quit [Quit: Connection closed for inactivity]
___nick___ has quit [Ping timeout: 252 seconds]
goliath has joined #u-boot
balejk has quit [Quit: nyaa~]
persmule has quit [Ping timeout: 264 seconds]
persmule has joined #u-boot
ikarso has quit [Quit: Connection closed for inactivity]
totkeks_ has quit [Read error: Connection reset by peer]
ikarso has joined #u-boot
mmu_man has joined #u-boot
<sjg1>
If I had a magic solution I would have done it. I'm not a salesman these days and I'm not sure the project would benefit from lots of salesmen selling us stuff. From my side I've been shocked at the difficulty to explain things that seem intuitively obvious to me
<sjg1>
Since we only have 153 contributors, I suppose another way would be to accept novel technical solutions, e.g. from the #1 contributor?
Jones42 has quit [Ping timeout: 248 seconds]
<marex>
#1 contributor never makes mistakes, understands all the use cases of every single person in full perfect detail without ever discussing them with anyone, and anything which does not fit the worldview is a problem with the contributor
<marex>
that kind of thing ? :)
<apalos>
marex: yes
<apalos>
and 'trust me i am anegineer' commit messages
<marex>
apalos: the software is never wrong, it is always a hardware issue (TM)
<apalos>
marex: I've long expressed how hardware should designed -- no one listened
<apalos>
so you gather a team, ask them to design something
<apalos>
Once they are done you get them into a room and shoot them, without even looking at the design
<apalos>
While a second team is watching
<apalos>
the second team will do a semi-decent design :P
<marex>
apalos: hardware and software should always be designed with both groups of people in the room, never the toss-over-the-wall design antipattern that keeps showing up, sadly
<marex>
apalos: ugh :)
<apalos>
marex: yep
<marex>
apalos: maybe a less gruesome approach would do too
<apalos>
marex: irrelevant but here's what you can do nowdays with EFI. I wrote 'simple' app that checks for secure boot, then adds a boot option automatically, reboots to trigger the new option and then download and run the generic arm64 poky image in RAM. It also measures all boot in a TPM and you can do fancy security stuff
<Tartarus>
sjg1: Every time I've had to overrule someone else, that someone else leaves. So no, I don't think making an exception just for you is healthy for the project
<sjg1>
You don't need to overrule someone else. But you could perhaps be open to pulling in some things from my tree if they come together and make sense in the end?
<sjg1>
It will also reduce my frustrations, as I feel I have to explain the whole airplane to get a wheel in
<sjg1>
As I mentioned before, we could also restart the regular U-Boot calls to discuss things that are coming up f2f. I know you are comfortable with long email threads, but they are not as effective for me
<sjg1>
Anyway I've given you my ideas
<Tartarus>
That all falls down as soon as we go back to "and so here's the efi_loader stuff that I want to put in"
<Tartarus>
And there's other examples too
<Tartarus>
i continue to be open to all the VBE stuff, and letting you try and show where the no cmdline boot image stuff will end up
<sjg1>
BTW I am not sure what to do with sunxi bootstd. It seems to be stuck, as we cannot change bootstd's EFI bootmgr code, nor implement FEL in bootmgr
<Tartarus>
Enough for you.
<Tartarus>
And yes, Andre has been busy I assume and your last iteration was "merge this OR this", and I forget which the general consensus was
<Tartarus>
And FWIW, on the platforms where there's a seemingly infinite number of consumer boards out there, I am fine being slow on merging changes
<xypron>
sjg1: Tartarus: is there a way to build 'make qemu-riscv64_smode_defconfig acpi.config' in Gitlab CI?
mmu_man has joined #u-boot
<Tartarus>
xypron: No, only by adding a defconfig that #includes both
<xypron>
Can't we have a buildman parameter to add a fragment?
<Tartarus>
But that'll only be useful imho for if it's under the test.py section where we then fire up qemu on the platform, it won't otherwise be in the world stages
<Tartarus>
(and I was thinking trying --target "qemu-riscv64_smode_defconfig acpi.config all"
<xypron>
tools/buildman/buildman -k qemu-riscv64_smode gives me
<xypron>
+make[1]: *** No rule to make target 'include/common.h', needed by 'include/config/auto.conf'. Stop