<qschulz>
marex: I see I'm in Cc of most of your patches for i.MX boards.. Is there any reason for that? I have not done any upstream work on i.MX6 for the last 6 years and not even booted one in the last 4, so I'm a bit surprised :)
clarity has quit [Ping timeout: 252 seconds]
sszy has joined #u-boot
peeweep has quit [Quit: Ich komme wieder]
peeweep has joined #u-boot
peeweep has quit [Client Quit]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
peeweep has joined #u-boot
peeweep has quit [Client Quit]
peeweep has joined #u-boot
flom84 has joined #u-boot
flom84 has quit [Client Quit]
clarity has joined #u-boot
Jones42_ is now known as Jones42
mmu_man has joined #u-boot
warpme has joined #u-boot
warpme has quit [Client Quit]
warpme has joined #u-boot
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #u-boot
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #u-boot
warpme has quit [Client Quit]
mmu_man has quit [Ping timeout: 252 seconds]
warpme has joined #u-boot
mmu_man has joined #u-boot
warpme has quit [Client Quit]
dsimic has quit [Ping timeout: 248 seconds]
warpme has joined #u-boot
dsimic has joined #u-boot
warpme has quit [Client Quit]
warpme has joined #u-boot
warpme has quit [Client Quit]
persmule has quit [Quit: Leaving]
naoki has quit [Quit: naoki]
monstr has joined #u-boot
mmu_man has quit [Ping timeout: 272 seconds]
warpme has joined #u-boot
mmu_man has joined #u-boot
warpme has quit [Client Quit]
warpme has joined #u-boot
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #u-boot
monstr has quit [Remote host closed the connection]
Jones42 has quit [Remote host closed the connection]
Jones42 has joined #u-boot
Jones42_ has joined #u-boot
Jones42 has quit [Ping timeout: 252 seconds]
persmule has joined #u-boot
<apalos>
sjg1: around?
<sjg1>
Yes sort of
<apalos>
ok when you are around ping me
<apalos>
the x86 problem booting is a lot worst than you can possibly imagine :)
<apalos>
worse*
Jones42 has joined #u-boot
Jones42_ has quit [Read error: Connection reset by peer]
<sjg1>
apalos: OK, I am here for a little bit now
<apalos>
ok hold tight
<apalos>
So the problem existing since the beggining of time
<apalos>
e820 marks the u-boot code and services as 'reserved'
<apalos>
what happened pre-lmb is that the u-boot maps got added *after* e820 when EFI came up -- thats why that revert works
<apalos>
post-lmb we add the u-boot maps and e820 now marks them as reserved
<apalos>
So x86 is like "I am not executing code from reserved memory"
<apalos>
now here's the funniest part
<apalos>
SetVirtualAddressMap which is a complete mess is *REQUIRED* in x86
persmule has quit [Remote host closed the connection]
<apalos>
in u-boot we do the wrong thing and dont mark it as runtime for reasons I want to fix
<apalos>
SO unless you mark that area as BOOT_SERVICES_CODE x86 will never work....
<apalos>
if you mark it as BOOT_SERVICES_DATA x86 sets the page NX bit and it blows up again
<apalos>
all in all
<apalos>
We have
<apalos>
bugs in e820, bugs in SVAM and a sequencing problem of when we set the memory map
<apalos>
\o/
<sjg1>
apalos: OK, thanks for digging into it. What is the best path to getting it working again for the release?
<apalos>
apply that revert with a huge commit message explaining the shitshow
<sjg1>
apalos: OK, sounds good
<sjg1>
apalos: Unrelated, I have some patches to disentangle EFI and LMB somewhat, but I got stuck on the confusion of addresses vs. pointers, which I why I sent that series yesterday
<sjg1>
apalos: I have some hope of sending them out by the end of next week
<sjg1>
apalos: I have various ideas, but it boils down to flipping between lmb being in control and EFI being in control
<sjg1>
apalos: Also using the 'image-recording' series to know where important things are, and when they can be discarded
<sjg1>
I know that people probably won't like them, based on earlier feedback, but I believe it is right for U-Boot so I'm going to continue looking at it, for now
<sjg1>
apalos: Back to e820, I said to Sughosh that I could look at that sometime, as this is a problem we had before
<sjg1>
apalos: But IMO we should first focus on getting some boot scenarios going in CI. I would be happy to run some of these with my Labgrid integration
<Tartarus>
sjg1: Yes, it would be good for you to enable test_net_boot.py in your labgrid
<sjg1>
apalos: Also my bootflow_efi() test has proved very powerful in nutting out EFI pointers/addresses, albeit that this only really helps sandbox
<sjg1>
apalos: But looking at the efi-test repo, I find it quite cumbersome to use
<apalos>
sjg1: what I want in labgrid is a board with a TPM
<apalos>
and arguably clean up the sandbox TPM
<apalos>
that thing is so complex that sandbox tests are a very small fraction of what could blow up
<apalos>
but yea booting stull is also nice
<apalos>
ping me at some point, I can certianly send scripts for testing stuff when a distro is up
<sjg1>
apalos: Perhaps for some pieces we could write unit tests, e.g. memory allocation. There are already a lot of tests that Heinrich wrote
<apalos>
sjg1: yes the e820 is definitely part of that problem
<sjg1>
apalos: I don't want to duplicate effort though. I'm looking forward to seeing how you go with running SCT
<apalos>
But the biggest problem is that we dont set SetVirtualAddressMap in RT services
<apalos>
I mewan we rely on x86 not touching BootServicesCode
<sjg1>
apalos: I have a few boards with TPM in my lab
<apalos>
But x86 calls SVAM *very very* late
<apalos>
it really works out of luck
<apalos>
sjg1: I already run the SCT internally for ages
<apalos>
like 3-4 years ago,
<apalos>
But In QEMU, I can certianly send that script
<sjg1>
apalos: That might explain why I had hard-to-pin-down bugs booting Ubuntu before I figured out the USB-bootflow crash
<sng>
apalos sjg1: also, i think that the efi runtime code is calling some boot services code/data, and that seems to be triggering this issue. which is why it is needed for the u-boot image region to be marked as executable.
<sng>
i mean, ideally, the efi runtime code should not be calling/accessing the boot services code. had it been the case, this would not have caused any issues
<apalos>
I explained it above
<apalos>
it's the SVAM call
<apalos>
which we dont mark as runtime
Jones42 has quit [Ping timeout: 248 seconds]
<sng>
but the svam call is actually a runtime call. it gets called after exitbootservices
<apalos>
yes but in u-boot we dont mark it as runtime
<sng>
and that is one of the issue. and that also seems to be calling other functions not marked as runtime.
<apalos>
so thats why x86 blows up if you mark that are anything else that _CODE
<apalos>
and you cant return EFI_UNSUPPORTED because they disable all RT services if you do
<sng>
yes, so in the current scenario, i think the revert should be applied with a better explanation of the issue
<apalos>
yea I'll send a patch shortly, I just need to write a readable commit message
mmu_man has joined #u-boot
goliath has quit [Quit: SIGSEGV]
<Tartarus>
sjg1, apalos, sng, once the revert gets posted I'll apply it since I want to clear this out asap. So apalos I think you can safely pickup Simon's SoB on yours as well
<apalos>
bleeeh too late I sent it without that
<apalos>
feel free to add whatever SoB I forgot
<apalos>
Tartarus: I can send a v2 shortly btw
<apalos>
I can add something to make the commit message even more colorful