<sjg1>
Tartarus: SPL works by filling in that struct. In any case, I suspect there are other such situations and we need at least some way of handling it
<Tartarus>
But sorry, I meant how many other PPL symbols would we need?
<Tartarus>
I don't think EFI_LOADER is one, in that I think we have a few other cases of incorrect behavior, similar to how there was a time where it was reasonable to guard changes to the environment based on SPL_BUILD or not, because it could bloat things, but that shouldn't be true now
<Tartarus>
As then it was including the env when not needed, but now we don't do that, and the env should be the same between all stages, with the caveat of SPL/etc might only be "nowhere", but the contents shouldn't change.
<sjg1>
Tartarus: If we want the env to be the same in SPL and Proper then we need to do something like this:
<sjg1>
Tartarus: Your guidance was that my series should result in no changes, so this one came up
<sjg1>
I suppose we can think of these symbols as 'shadow' symbols. We can easily access SPL and VPL symbols, etc. from any build. The only problem is trying to access Proper symbols from any SPL build
<Tartarus>
Yes, that looks kinda ugly
<sjg1>
Yes...it changes to CONFIG_PPL_EFI_LOADER in a later commit
<Tartarus>
Maybe the environment generation itself needs a re-think
<Tartarus>
esp now that we have a tool that just prints it out
<Tartarus>
rather than what we used to have to do
<Tartarus>
Generate the env itself, use that in all stages
<Tartarus>
EFI_LOADER makes sense only in the primary case tho
<sjg1>
Right, but we need an SPL symbol so that it doesn't get enabled in SPL...we already covered that yesterday
<Tartarus>
yeah, I think that really means you need to re-work the env generation
<sjg1>
Of course with bootstd we can drop the env stuff. Hoping to move that along this year
<Tartarus>
which should suck less, now that we have an actual tool to show
<Tartarus>
rather than what we used to do
<sjg1>
Hmm it is going to be bad enough just to identify these situations. Rewriting to avoid them is really expanding the task in unknown ways
<sjg1>
I think we need to find a compromise so we can move forward, then deal with the cases one by one...for now I just don't know how many there are
<sjg1>
One option we do have is to be able to say that EFI_LOADER cannot be enabled in SPL. I have a file for that now (it lists things that are no_spl)
<sjg1>
But of course that still leads to the env problem we see here
<sjg1>
for TEXT_BASE and anything else we find, I think renaming it can work, still thinking about that
<Tartarus>
I mean yes, EFI_LOADER isn't valid in SPL :)
vagrantc has joined #u-boot
<Tartarus>
And I think the env problem is solvable most easily by just making a new stage that generates the env contents, and we always use that file
<Tartarus>
And with 486aef08de091ca35386f32fe961a201c3cfa9d4 that's a lot less work than it used to be
<sjg1>
So we need a TEXT_BASE_PPL as well?
<Tartarus>
So I don't feel like that's a big ask, compared to adding a number of PPL symbols, just for the env
<Tartarus>
That would just leave TEXT_BASE_* which I'm not thrilled over
<Tartarus>
But if it's one symbol, we can rename them all better and be intentional about it, at least
<Tartarus>
Is there a 3rd case you've found?
<sjg1>
I really don't know yet how many symbols. This was just from looking at x86
<Tartarus>
Well, lets see where it goes from there
<Tartarus>
I'm open to re-evaluating my thoughts again if/when you find a 3rd case
<sjg1>
OK, well the only sensible approach is to continue to look for size changes as a way to see differences. Perhaps I won't find too many more
<sjg1>
I've already found several in struct global_data but was hoping to ignore them. Will see'
frieder has quit [Remote host closed the connection]
Net147 has joined #u-boot
Net147 has joined #u-boot
Net147 has quit [Changing host]
redbrain has quit [Read error: Connection reset by peer]
redbrain has joined #u-boot
apritzel has quit [Ping timeout: 248 seconds]
ikarso has joined #u-boot
prabhakarlad has joined #u-boot
<austriancoder>
Is there something like coreboot's cbmem for baremetal U-Boot? I would love to have a way to read back the console outputs in Linux.
<sjg1>
austriancoder: Nope, it would be a good addition though, e.g. dump it in the /chosen node
<austriancoder>
sjg1: okay.. I will hack around a little bit
Algotech75 has quit [Quit: Leaving]
___nick___ has quit [Ping timeout: 252 seconds]
<sjg1>
austriancoder: You could us a bloblist with a blob for the console, then either pass the full text or just address/size to Linux as as part of FDT fixup
<sjg1>
austriancoder: drivers/misc/cbmem_console.c shows how to record stuff
<sjg1>
austriancoder: And membuff is handy for a circular buffer (as used by console.c)
<austriancoder>
sjg1: thanks.. I am looking at the coreboot sources to see how it is done for none x86 arch's .. and also at the cbmem kernel driver.
<sjg1>
austriancoder: cbsysinfo command shows it...but basically in coreboot it is a memory region, like a blob in a U-Boot bloblist
<sjg1>
austriancoder: coreboot does not actually talk to Linux directly though, only through a payload
<austriancoder>
sjg1: Linux looks for the coreboot tables and take what it needs .. I only work with coreboot and U-Boot as payload on x86. That's why I am looking at cbmem utils and the kernel sources :)
<sjg1>
austriancoder: OK
naoki has joined #u-boot
<austriancoder>
sjg1: would it make life easier if I try to create the coreboot tables in U-Boot (stored in blobllist) and add a of node during fdt fixup with a compatible = "coreboot"? That would make the Linux part easy.
naoki has quit [Client Quit]
___nick___ has joined #u-boot
mmu_man has joined #u-boot
vagrantc has quit [Ping timeout: 248 seconds]
vagrantc has joined #u-boot
<sjg1>
austriancoder: Probably...except maybe there needs to be a proper compat string (but that could come later)
<sjg1>
austriancoder: IMO we need a schema node for this...if we come up with something I could send it to dt-schema
<sjg1>
austriancoder: Not sure if there is anything similar already?
<sjg1>
robher: Er, that's for the kernel when it crashes, I thought
<robher>
Originally, some 15 years ago, yes. Now it is multiple things that can be logged and preserved across boots.
<robher>
So either another section could be added and use all the existing support to read it out from Linux userspace, or you could copy its binding which is just a /reserved-memory node.
<sjg1>
robher: OK I see. So the -size property provides the type as well
<sjg1>
robher: If we are doing this properly, we probably want to be able to supply the console output from multiple firmware phases
<sjg1>
robher: E.g. TPL, SPL, TF-A, OP-TEE startup, ...?
<sjg1>
U-Boot
indy has quit [Ping timeout: 246 seconds]
<robher>
sjg1: Yeah, would be nice to have.
indy has joined #u-boot
goliath has quit [Quit: SIGSEGV]
ikarso has quit [Quit: Connection closed for inactivity]
<macromorgan>
is there a way to force a test driver I'm working on to probe?
<sjg1>
macromorgan: Do you mean probe or bind? If probe, then you could add something to main to call uclass_first_device() or something like that. I suppose you could even write a command do it, like we have 'bind'
<macromorgan>
okay
<macromorgan>
I'm trying to modify the stm32 dsi driver to work with rockchip devices... would like to test it out