<qschulz>
i'm wondering why we have env_get_from_linear memcpy stuff to a buffer instead of just simply returning the address to the value in the environment?
<qschulz>
surely all values are NULL-terminated so it shouldn't be any issue to return a pointer to the value
<qschulz>
(i'm trying to fix env_get_default limited to 32 chars, which is not enough to store BOOT_TARGETS :) )
ezulian has quit [Ping timeout: 255 seconds]
apritzel_ has joined #u-boot
apritzel_ has quit [Ping timeout: 258 seconds]
Mis012 has quit [Remote host closed the connection]
Mis012 has joined #u-boot
Mis012 has quit [Remote host closed the connection]
Mis012 has joined #u-boot
Mis012 has quit [Remote host closed the connection]
Mis012 has joined #u-boot
<rfs613>
marex happen to be around?
Kwiboo has quit [Quit: .]
prabhakarlad has quit [Ping timeout: 248 seconds]
Kwiboo has joined #u-boot
<marex>
rfs613: yeah ?
Clamor has joined #u-boot
<rfs613>
marex: oh hiya. Have been looking at that strange hang on rz/n1 again. You had made some helpful suggestions a few weeks back...
<rfs613>
we were thinking some kind of overwrite of the stack, causing a returin to nowhere... that sort of thing.
<rfs613>
I was finding that when I put in printfs into the area where it fails, the problem goes away
<rfs613>
so anyhow, I now have a JTAG setup, so I have been tracing it without adding printfs.
<rfs613>
and this has led to something that seems almost impossible.
<rfs613>
it seems like the contents of the text segment rather suddenly shift by 32 bytes. Without any explicit code to move the memory contents.
<Tartarus>
qschulz: Because it started out being part of env_get_f and I guess could be further simplified?
<Tartarus>
And then maybe some further historical reasons / thinking
<Tartarus>
(What happens when we / before we relocate env to memory?)
<Tartarus>
qschulz: My further pondering is related to env in NOR/SPI flash and access times tied with historic design vs how it all is now
m5zs7k has quit [Ping timeout: 248 seconds]
m5zs7k has joined #u-boot
<apalos>
sjg1: I dont know if you are receiving mails or not,
<apalos>
But the statetement that we wont be able to boot without GRUB is not entirely correct
<apalos>
The EFI bootmgr can store the initramfs you want to use with your OS, storing the DT as well is just a few lines of code
apritzel_ has joined #u-boot
<Clamor>
Tartarus: I suspect that dm_pmic gets involved and pulled into, this may cause inflation
<Tartarus>
Could be, yeah
<Tartarus>
apalos: There's a few different problems being conflated I think
<Tartarus>
One of which is that EFI bootmgr lacks the hook that just bootefi has to override what DT is passed via SCT
<Tartarus>
And that is not a grub-centric (or BSD loader centric) problem
<Tartarus>
It's a problem for everyone in that the system DT can't always be relied upon to be correct or correct enough
<apalos>
Tartarus: thats exactly what I am offering to fix on the bootmgr though :P
<apalos>
so right now on the bootmgr you can define a <kernel/initrd> pair to direclty load your kernerl
<apalos>
We can easilty do <kernel/initrd/dtb>
<Tartarus>
How do you define the kernel/initrd pair?
<apalos>
you really want to know ?
<Tartarus>
That's one of the (in my mind at least) missing parts
<apalos>
:)
<apalos>
ok let me remeber what I did there
<Tartarus>
If we're going to act like it's a real option people will use, yes.
<Tartarus>
If it's in theory we can do X but in reality everyone is using grub/systemd-boot/bsd-loader/etc
<apalos>
When you define a LoadOption, which is basically an entry on the efi bootmgr you have FilePathList
<apalos>
the first element of the array *must* be the loaded image, but you are free to use the rest
<apalos>
so we add an extra device path, with its own GUID which encodes the initrd,
<apalos>
we can just as easliy add the dtb
<apalos>
so for a *single* boot option, you can define as many 'useful' files as you want to load your OS
<apalos>
But Simon might have a point here, defining a protocol to provide the DTB isnt a bad idea
<apalos>
We already do that in the kernel for the initrd, we can reuse that
prabhakar has quit [Quit: Connection closed]
prabhakarlad has joined #u-boot
prabhakar has joined #u-boot
<apalos>
Tartarus: the short description of the kernel initrd loading mechanism is that the firmware defines those files
<apalos>
The communicated info to the os is not a path or anything,
<apalos>
so the kernel basically tells the firmware 'give me my initrd' and the firmware knows which file to provide,
<apalos>
we can probably do something similar, but I'll go read that thread moar, since I might be missing something
<Tartarus>
I assume at the end of the day it puts the right info where the kernel will be looking for it, yes, and this would also need to.
<apalos>
yea the kernel basically allocates the buffer, and hands over the buuffer to the firmware
<apalos>
if the file is bigger the firmware responds with EFI_BUFFER_TOO_SMALL and fills in the size
<apalos>
teh kernel reallocates etc, but you end up with the *kernel* deciding where to put that and not the firmware(which has casued this initrd/high/low addr madness)
<apalos>
anyway my tl;dr response is
<apalos>
1. we aint tied to grub and it's pretty easy to address that
<apalos>
2. I'll look intoi that protocol a bit more and talk to distro people and see
<Tartarus>
By kernel decides, do you mean the EFI stub code?
<apalos>
yea
Clamor has quit [Read error: Connection reset by peer]
redbrain has quit [Read error: Connection reset by peer]
redbrain has joined #u-boot
<apalos>
sjg1: git show 37c3ca5c0b1 for thge DTB details
<sjg1>
apalos: My email is working, so I'll take a look
<sjg1>
alpernebbi: That is just awful. We need an open booting standard. It cannot all be EFI
<alpernebbi>
sjg1: it puts kernel/initrd/dtb/cmdline into PE sections, iiuc we should be able to pick its pieces apart and use them in non-EFI ways still
<sjg1>
alpernebbi: OMG this is all just madness. The last thing we need is another boot format. We have FIT implemented almost everywhere now
<xypron_>
sjg1: UKI kernels are EFI binaries with an EFI stub that takes care of self extraction. So seen from U-Boot it is not a new format.
warthog9 has joined #u-boot
<xypron_>
alpernebbi: It is not U-Boot taking the pieces apart.
<xypron_>
alpernebbi: UEFI is an open booting standard. What are you missing?
<alpernebbi>
xypron_: what I meant is, at least it's possible to make UKI files even if someone wants to avoid UEFI -- no strong opinions about UEFI on my part
<alpernebbi>
s/make UKI/make use of UKI/
umbramalison has quit [Ping timeout: 258 seconds]
umbramalison has joined #u-boot
goliath has joined #u-boot
joeskb7_ has quit [Quit: Lost terminal]
joeskb7 has joined #u-boot
joeskb7 has quit [Quit: Lost terminal]
joeskb7 has joined #u-boot
JPEW has quit [Ping timeout: 260 seconds]
joeskb7 has quit [Client Quit]
JPEW has joined #u-boot
joeskb7 has joined #u-boot
<sjg1>
alpernebbi: UEFI does not specify how things boot, hence the apps. It is poorly thought out. I should probably write up what is wrong, since apparently only I can see it 🤔
joeskb7 has quit [Client Quit]
joeskb7 has joined #u-boot
<alpernebbi>
I don't know the internals enough to argue for or against it basically