<sjg1>
Tartarus: I actually got one on weka this morning...a compiler fault that went away on a retry
<sjg1>
Tartarus: I can run a memory test at the weekend
hanetzer has quit [Quit: WeeChat 3.8]
mmu_man has quit [Ping timeout: 246 seconds]
RecursiveG[m] has joined #u-boot
thopiekar has quit [Ping timeout: 248 seconds]
thopiekar has joined #u-boot
pwdr has joined #u-boot
torez has quit [Remote host closed the connection]
hanetzer has joined #u-boot
pwdr has quit [Ping timeout: 260 seconds]
naoki has quit [Quit: naoki]
camus has quit [Ping timeout: 246 seconds]
pwdr has joined #u-boot
camus has joined #u-boot
GNUtoo has quit [Ping timeout: 255 seconds]
GNUtoo has joined #u-boot
stefanro has joined #u-boot
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
vfazio_ has joined #u-boot
vfazio has quit [Read error: Connection reset by peer]
naoki has joined #u-boot
pwdr has quit [Ping timeout: 260 seconds]
chron0 has quit [Ping timeout: 246 seconds]
hanetzer has quit [Ping timeout: 248 seconds]
hanetzer has joined #u-boot
stefanro has quit [Ping timeout: 252 seconds]
stefanro has joined #u-boot
ldevulder has quit [Quit: Leaving]
apritzel_ has joined #u-boot
hanetzer has quit [Ping timeout: 255 seconds]
guillaume_g has joined #u-boot
hanetzer has joined #u-boot
PhoenixM2ge has joined #u-boot
<PhoenixM2ge>
Hi all, I was wondering how 'mii list' gets populated. I am trying to work out why I have no ethernet device in u-boot. I am using the same DTB as the linux kernel when does show an interface and fdt list shows an ethernet... in it
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
camus1 has joined #u-boot
monstr has joined #u-boot
camus has quit [Ping timeout: 246 seconds]
camus1 is now known as camus
apritzel has joined #u-boot
<qschulz>
FYI, we're seeing 1 to 10% incorrect DRAM initialization on some of our PX30 modules (detected as 1.5GiB instead of 2GiB but otherwise seems to be working)
<qschulz>
this seems to be related to the compiler (hello again...) as i couldn't get it to NOT work on gcc 12 from fedora but it happens often when compiled with gcc 10 from debian bullseye
<marex>
sjg1: is it now possible to build another SPL-like blob which would be started by U-Boot _after_ U-Boot , in optee-ish fashion ?
guillaume_g has quit [Quit: Konversation terminated!]
pwdr has quit [Ping timeout: 260 seconds]
monstr has quit [Remote host closed the connection]
<apalos>
Tartarus: maybe i caused more confusion
<apalos>
Heinrich's change *is* fine
<Tartarus>
apalos: It is fine, yes
<apalos>
and it's pretty safe (at least for Linux)
<Tartarus>
But it also answered my lingering question on how EFI stub does things
<apalos>
yea it does stuff :>
<apalos>
it also measures the initrd and the kernel cmdline
<apalos>
and some other magic needed to jusmp into the kernel proper
<Tartarus>
The whole reason we have things like fdt_addr_r, kernel_addr_r, initrd_addr_r, fdt_high, fdt_high is that these addresses are annoying to get right in all cases
<apalos>
yea I know
<Tartarus>
It's less suck, yes, with EFI
<apalos>
One more thing EFI solves
<apalos>
oh i forgot efi is evil
<apalos>
and bad designed
<apalos>
and slow
<Tartarus>
Since we don't _have_to_ worry about the kernel BSS nuking stuff
<apalos>
Did i forget anything?
<Tartarus>
You forgot it's the literal devil, apalos :)
<Tartarus>
I've seen so many engineering hours spent on "oh, kernel BSS overwrote ... and now things blew up"
<Tartarus>
That I'm cranky about this too
<Tartarus>
I'll grant there's _probably_ not a problem now
<Tartarus>
But there's still boards doing fdt_high=0xffffffff
<Tartarus>
and risc-v got all of this wrong from the get-go
<Tartarus>
apalos: In sum, I'd feel a lot more confident that things are truly fixed and fine if someone claimed they had a small'ish memory system, but loaded a huge distro kernel, and huge initrd and nothing shat the bed :)
<apalos>
Tartarus: the kernel initrd loading is completely solved with EFI as well
<apalos>
In principle it's *insane* to makeu-boot aware of internal kernel mappings etc
<apalos>
Because preloading the initrd assumes you *know* the per architecture peculiarities
<apalos>
On where to place theinitrd etc
<apalos>
Which again is insane
<apalos>
So if you boot with EFI and install a loadfile2 protocol (which u-boot already supports)
<apalos>
The efistub boots up, allocates memory for you and asks the bootloader to copy theinitrd there
<apalos>
So you dont need any memory awareness
<Tartarus>
Someone else does instead, yes
<apalos>
The only thing teh bootloader needs to know, is where is the psysical storage of the initrd
<apalos>
again efi is evil, misdesigned etc ;)
<Tartarus>
I agree it can be done sanely and safely by someone else
<Tartarus>
I just want someone to go off and test that it really is
<apalos>
we already do that in u-boot and we added patches to grub as well for that protocol
<Tartarus>
Since as that commit shows, oops, we had one bug already
<apalos>
Tartarus: basically for arm/risc-v the initrd= on command line is deprecated
<Tartarus>
And I don't know how much time someone spent tracking down that kind of bug, that we spent forever making it really hard to have, outside of the EFI context
<apalos>
In fact risc-v doesnt even support it
<Tartarus>
It's the "but verify" part of "trust, but verify" :)
<agraf>
️🔥 :)
<Tartarus>
sjg1: can you please turn "moa" off until you can debug it?
<agraf>
Tartarus: I think you want to make this slightly more actionable for apalos :)
<sjg1>
Tartarus afk but will try
<sjg1>
Tartarus ok I think I did it
stefanro has quit [Quit: Leaving.]
sylensky[m] has quit [Quit: You have been kicked for being idle]
macromorgan has quit [Quit: Leaving]
<apalos>
Tartarus: as far as testing for these is concerned, I can probably add testing using qemu in the CI
<Tartarus>
OK
<apalos>
iow, boot up , enable measured boot, load the kernel -> load a big initrd -> read the eventlog
<Tartarus>
load a big kernel :)
<apalos>
that still can blow up
<Tartarus>
a login prompt in Linux would be great, doesn't need to be a CI every time thing
<Tartarus>
just a manual test
<apalos>
Heinrich fixed big parts of it, but we need to rethingk the lmb/efi mappings integration
<Tartarus>
k
<apalos>
and yea in order to read the eventlog you need to reach a login prompt
<Tartarus>
And again, I don't disagree with "lmb is weird, replace it with something less weird"
<apalos>
basically the stub copies it from efi config tables -> sysfs
<apalos>
yea I got the LMB on my long long todo list