wooosaiiii has quit [Read error: Connection reset by peer]
wooosaiiii1 is now known as wooosaiiii
BobBeck3 has quit [Quit: Ping timeout (120 seconds)]
fionera has quit [Quit: No Ping reply in 180 seconds.]
BobBeck3 has joined #u-boot
fionera has joined #u-boot
mrnuke has quit [Ping timeout: 244 seconds]
vagrantc has quit [Quit: leaving]
Jones42_ has joined #u-boot
Jones42 has quit [Ping timeout: 244 seconds]
Daanct12 has joined #u-boot
joeskb7 has quit [Ping timeout: 244 seconds]
Daanct12 has quit [Client Quit]
Daanct12 has joined #u-boot
ikarso has quit [Quit: Connection closed for inactivity]
mrnuke has joined #u-boot
<Tartarus>
sjg1: Something is going on with how your lab builds, it's not building and testing the right commits. You can see on https://source.denx.de/u-boot/u-boot/-/jobs/971304#L217 for example that "version" says v2025.01-rc3" but it should have built v2025.01-rc4
joeskb7 has joined #u-boot
mrnuke has quit [Ping timeout: 244 seconds]
mrnuke has joined #u-boot
rvalue has quit [Read error: Connection reset by peer]
vardhan_ has quit [Remote host closed the connection]
vardhan_ 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
MyNetAz has quit [Read error: Connection reset by peer]
MyNetAz has joined #u-boot
goliath has joined #u-boot
monstr has joined #u-boot
frieder has joined #u-boot
frieder has quit [Remote host closed the connection]
joeskb7 has quit [Ping timeout: 244 seconds]
frieder has joined #u-boot
ikarso has joined #u-boot
joeskb7 has joined #u-boot
gsz has joined #u-boot
cbeznea has joined #u-boot
mckoan|away is now known as mckoan
gsz has quit [Ping timeout: 260 seconds]
ldevulder has joined #u-boot
warpme has joined #u-boot
sszy has joined #u-boot
joeskb7 has quit [Ping timeout: 265 seconds]
Jones42 has quit [Ping timeout: 252 seconds]
gsz has joined #u-boot
___nick___ has joined #u-boot
<naoki>
include/configs/evb_rk3588.h defines ROCKCHIP_DEVICE_SETTINGS AFTER "#include <configs/rk3588_common.h>", is it correct?
slobodan has joined #u-boot
ldevulder has quit [Quit: Leaving]
mckoan is now known as mckoan|away
naoki has quit [Quit: naoki]
paulhenrys has joined #u-boot
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
gsz has quit [Ping timeout: 248 seconds]
Jones42 has joined #u-boot
Jones42_ has joined #u-boot
Jones42 has quit [Ping timeout: 252 seconds]
Jones42 has joined #u-boot
<calebccff>
Tartarus: the EFI app series and my EFI payload series are doing quite different things. One is using the EFI boot services made available by the existing EFI implementation, the other calls EBS and then has U-Boot use its own drivers and own EFI implementation
dsimic has quit [Ping timeout: 244 seconds]
<calebccff>
the reason I went for the EFI payload approach is because the stock EFI on Qualcomm X Elite laptops is crap, and we can do better in U-Boot
Jones42_ has quit [Ping timeout: 260 seconds]
dsimic has joined #u-boot
<calebccff>
sjg1: on the RFC I was hoping mostly for high level feedback like what Ilias provided. If some broader approach I took is wrong or if I'm missing something. But yes I need to get around to sending a v2
<xypron>
calebccff: What is your approach to EFI variables for the Qualcomm devices. Would U-Boot talk to the Qualcomm runtime for this purpose?
<calebccff>
xypron: we'd configure a magic boot entry for u-boot and then clobber the runtime services so whatever linux distro you install only sees U-Boot's runtime services
<calebccff>
not ideal w.r.t setting variables from userspace, but realistically i don't think it's that necessary to support SetVariable. U-Boot can infer pretty much everything it needs
<calebccff>
if someone desperately wants to boot with EFISTUB they can run => eficonfig
<xypron>
Doesn't Linux have some driver to talk to Qualcomm's security domain for variables, at leasr on X13s?
gsz has joined #u-boot
Jones42 has quit [Ping timeout: 244 seconds]
<calebccff>
xypron: yes, we'd break that
mmu_man has joined #u-boot
ldevulder has joined #u-boot
<sjg1>
calebccff: The approach looks good to me...I don't have any comments other than the ones already made (init-sequence change, code duplication). I'd like to get an EFI stub thing running in a lab so we can ensure things continue to work
slobodan has quit [Read error: Connection reset by peer]
<calebccff>
sjg1: ok awesome. something I haven't tried yet (but should just work) is to just run payload on top of an existing U-Boot
___nick___ has joined #u-boot
___nick___ has quit [Client Quit]
___nick___ has joined #u-boot
MyNetAz has quit [Read error: Connection reset by peer]
yann-kaelig has joined #u-boot
<sjg1>
Tartarus: Yes, that's very strange
<sjg1>
Tartarus: I see this: Building U-Boot in pytest-source dir for chromebook_kevin
<sjg1>
Bootstrapping U-Boot from dir /scratch/sglass/gitlab-runner/builds/maJ-y5z_5/0/u-boot/u-boot/build/
<sjg1>
I wonder if they are different dirs somehow?
<sjg1>
But I have noticed once or twice that CI passes when it should not. I wonder if it is related?
<sjg1>
You can set 'export VERBOSE=-v' to enable more verbosity
<sjg1>
Or could this be a buildman bug? I recall you saw some situations where buildman didn't report errors that it should have?
<sjg1>
calebccff: Yes, I expect it to work. Then I suppose you can make the stub run itself, ad infinitum
warpme has joined #u-boot
MyNetAz has joined #u-boot
<calebccff>
sjg1: yes, and find any quirks in the memory map handling if the amount of available memory somehow gets smaller and smaller with each run :D
<Tartarus>
sjg1: re your CI / labgrid hooks, yes, I do not know where the sources being used are coming from, but they are not the correct ones. See https://source.denx.de/u-boot/u-boot/-/jobs/971317 where pwd has the correct tree, but ${OUT}/include/generated/generated_version.h shows it built something else enitrely
<Tartarus>
sjg1: I can re-assign that series to xypron since it's efi_loader and he can take it, or not.
<Tartarus>
... here, I see how to see where the sources are, lets find that out.
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sjg1>
apalos: Hmm just taking a look, is there any documentation? It seems quite hard to find. I tried searching for "tool to create uefi sct sequence files"
prabhakalad has quit [Ping timeout: 276 seconds]
prabhakalad has joined #u-boot
<apalos>
if you scroll up a few days ago, I described exactly how to run the tests that failed
<apalos>
so you can run the ACS on qemu and just use a TUI to select a signle test category
<Tartarus>
sjg1: I don't understand your question, sorry. I don't know why buildman isn't using pwd for sources.
<sjg1>
apalos: yes, I have the instructions copied in, but I am now trying to run the tests automatically. It seems to behave strangely:
<sjg1>
Tartarus: OK, I'll take a look first thing tomorrow...
<sjg1>
apalos: It is quite amazing to me how different UEFI is to the open source industry, in just about every way. How you and Heinrich cope with it is quite beyond me :-)
<sjg1>
SCT produces huge amount of output. Did it pass or fail? Which thing failed? Who knows? It's just amazing to me
<apalos>
sjg1: you downloads SCT tests
<apalos>
and then open the file and line it failed
<apalos>
Now *why* that failed, all i can say is good luck
<Tartarus>
sjg1: Yes, I talked with him a little over on the fediverse
<Tartarus>
(imprecisely referred to as mastodon, often, sadly)
<sjg1>
apalos: Indeed, much better than no tests. Heinrich was able to get it running on sandbox at one point. That would at least be faster than QEMU. Sadly x86_64 crashes at the moment. Anyway, I believe you are hoping to get something into CI at some point?
<apalos>
We already test it internally,
<apalos>
and it works on sandbox last time I checked
<apalos>
I fixed the aarch64 runners for sandbox a few hours ago
<sjg1>
apalos: OMG I just saw it boot Linux in one test
<apalos>
So yes, I will have someone looking at it
<sjg1>
apalos: sandbox arm64 or x86_64 ?
<apalos>
sjg1: then it finished and continued
<apalos>
half of the tests run in EFI, as part of SCT, and then it boots linux and runs fwts
<apalos>
sjg1: both iirc, cant remember
<sjg1>
apalos: OK ta
<apalos>
sjg1: also i replied on that lmb series
<apalos>
the size actually decreases -- unless you applied just one patch or enabled DM
<apalos>
but noone cares about the size post SPL and we never do DM in SPL,
<apalos>
+ i plan to skrink lmb even more, most of the functions just do the same thing
<apalos>
But I'll send a v1 of the cleanup in a few days, once people have reviewed it
<sjg1>
apalos: Actually perhaps I could try sandbox on an arm machine. But for now I was just hoping to get it running