persmule has quit [Remote host closed the connection]
indy_ has joined #u-boot
indy_ has quit [Ping timeout: 244 seconds]
monstr has joined #u-boot
m5zs7k has quit [Ping timeout: 246 seconds]
m5zs7k has joined #u-boot
warpme has joined #u-boot
ldevulder has joined #u-boot
Stat_headcrabbed has joined #u-boot
mckoan|away is now known as mckoan
tnovotny has joined #u-boot
sszy has joined #u-boot
prabhakalad has quit [Quit: Konversation terminated!]
naoki has quit [Quit: naoki]
prabhakalad has joined #u-boot
naoki has joined #u-boot
monstr has quit [Ping timeout: 252 seconds]
___nick___ has joined #u-boot
glaroque has joined #u-boot
rber|res has joined #u-boot
<Kwiboo>
I am seeing "efi_free_pool: illegal free 0x00000000ecedf040" or "Synchronous Abort" handler, esr 0x96000004, far 0x144d32d622093c73 after "Starting kernel ..." using next branch with stdboot extlinux bootmethod, no such issue on master branch, something known? will try to bisect later, suspecting new lmb code
<Kwiboo>
looks like it is trying to free a page in the mittle of ramdisk: Loading Ramdisk to ecd42000, end ecedf8f5 ... OK
alexxy has quit [Quit: No Ping reply in 180 seconds.]
<pivi>
Kwiboo: I reported the same a few hours ago. cc: Tartarus apalos
<pivi>
Kwiboo: for myself this is a regression with 2024.10, 2024.07 used to be fine. I did not have the time to bisect it :-(
<Kwiboo>
sng: thanks, I will take a look later
<Kwiboo>
pivi: for my 2024.10-rc6 builds I did not see the issue, but still looked like there could have been some memory overlap, so may be that the updated code just bring the issue to surface on more targets
<sng>
pivi: you should not be observing this issue on master. are you ? this should show only on next. so this should not be a regression for 2024.10
<pivi>
sng: I do see the issue on master, so what I am experiencing is different from what Kwiboo is experiencing. or the issue is just more nasty?
<sng>
pivi: if you are seeing the exact same issue on master, then it is not related to the lmb rework series, as that is only in the next branch. this should be some other issue then.
<pivi>
at the moment I am in trouble finding the time :-(, I just wanted as a bare minimum to report it, however
<sng>
with the above series applied, the efi allocations should work properly with lmb, and should not trample over any memory that might have been allocated by lmb for some other image
<Kwiboo>
sng: my issue seem to be consistent for the same u-boot build, kernel and ramdisk used, however some builds seem to instead report illegal free and can boot into kernel, other builds just reset after the sync abort, will try that series later and see if my issue goes away
<sng>
Kwiboo: sure, please let me know the results of your findings...
mmu_man has joined #u-boot
guest92 has joined #u-boot
<guest92>
Am I correctly interpreting from mii dump command that I have link established however with speed 10Mbps and not 100Mbps
<apalos>
it's obviously not the right fix, I just need to exclude the lmb case
Wouter0100 has joined #u-boot
<apalos>
and looking at it, i doubt it's what causing it, the code looks correct
alexxy has quit [Quit: No Ping reply in 180 seconds.]
alexxy has joined #u-boot
alexxy has quit [Client Quit]
<apalos>
Kwiboo: I looked at all the efi_free_pool() calls, I couldnt immediately sop anything wrong
<pivi>
apalos: yes, am62, but not beagleplay. and our board (verdin-am62) might be different than beagleplay on this regards
<apalos>
What is probably happening, is that initrd gets loaded really high in address
<apalos>
That's where the majority of efi allocations live
<apalos>
So what I suspsect is happening, is that initrd overwrites that, then the current code is trying to free allocated pages, but it can't find the proper metadata anymore
<apalos>
pivi: can you try loading the initrd lower?
<apalos>
this, in theory should be fixed after the LMB series land
<pivi>
apalos: we are not loading any initrd, I need to double check if for some reason we are loading something at that address, maybe the bootscript or something else
<apalos>
pivi on Kwiboos example, initrd is loaded over that memory,
<apalos>
I suspect something similar happens to your case,
<pivi>
yes, make sense, I got your point
<apalos>
the efi_allocate_pool, allocates a pool and some metadata,
<apalos>
Its the metadata that gets trumped over hence the print
<apalos>
what I dont understand yet, is why it crashes
<apalos>
pivi: and patse the boot log somewhere, so I can at least figure out how the board boots etc please
<pivi>
apalos: this is easy. the reason I am struggling on doing test is that everything else is automated, and I just got it for free from our CI, logs coming in 1 min
warpme has joined #u-boot
alexxy has joined #u-boot
<marex>
Peng_Fan: thank you
<marex>
mkorpershoek: Tartarus: do we need rc7 ?
<apalos>
pivi: it should be irrelevant to board etc, If I am right I can reproduce that locally even on QEMU
<apalos>
but let's make sure moving the bootscript to lower memory fixes that
<Tartarus>
mkorpershoek: How confident are you that doesn't have other side effects?
<mkorpershoek>
Tartarus: I only tested this on VIM3. This has no side effect on bootmeth_android because we only boot image v4 there. I would say 8/10 confidence. I can run some more tests to be more confident
<pivi>
apalos: so, I was partially incorrect in what I wrote. In our CI the boot is freezing lately, but I do not have this efi error message. The boot failure with the EDI error message happened on a manual test.
ikarso has quit [Quit: Connection closed for inactivity]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
persmule has joined #u-boot
mmu_man has quit [Ping timeout: 244 seconds]
mmu_man has joined #u-boot
jaganteki has quit [Quit: Client closed]
<apalos>
pivi: ok I think you and Kwiboo are seeing different errors
<apalos>
So you -master freezxes on something completely irrelevant to EFI
<apalos>
and -next pops that efi_free_pool error message?
mmu_man has quit [Ping timeout: 248 seconds]
<apalos>
I dont have any idea what the freeze on non EFI is
<apalos>
For the -next message I can have a look
<apalos>
Kwiboo is also seeing it only in next, but I am pretty sure the error he sees is the initrd loaded too high
<apalos>
so is your issue on efi-next
<apalos>
0x0000000098ee1040 that's the free address, and the initrd starts at 0000000098eb1000 and ends 0000000098ee5fff
<apalos>
in any case, we need to sort thios but since you arent booting with EFI it should have no real sideeffects
<apalos>
and if you load with EFI the initrd doesnt need to be preloaded
hanetzer has quit [Ping timeout: 252 seconds]
hanetzer has joined #u-boot
mckoan is now known as mckoan|away
alexxy has quit [Quit: No Ping reply in 180 seconds.]
mmu_man has joined #u-boot
alexxy has joined #u-boot
alexxy has quit [Quit: No Ping reply in 180 seconds.]
alexxy has joined #u-boot
<apalos>
Kwiboo: as you see the addresses in -master don't overlap
<apalos>
Perhaps it's the efi allocation that LMB is doing now that causes that overlap
<apalos>
But fromn what I can tell, I dont see any actual bug in the code -- e.g someone not allocating memory and trying to free it etc
monstr has quit [Remote host closed the connection]
alexxy has quit [Quit: No Ping reply in 180 seconds.]
<pivi>
apalos: yes, correct. we'll have a look on what the master issue issue, I agree they are unrelated, I was mixing up things.
alexxy has joined #u-boot
hanetzer has quit [Ping timeout: 265 seconds]
<Kwiboo>
apalos: agree, something is causing an overlap, probably the changed lmb code, tried to compare boot/ and lib/ code master vs next and lmb is what stand out most, will try to dig deeper and get more details
hanetzer has joined #u-boot
___nick___ has quit [Ping timeout: 252 seconds]
f_ is now known as funderscore
funderscore is now known as f_
alexxy has quit [Quit: No Ping reply in 180 seconds.]
alexxy has quit [Quit: No Ping reply in 180 seconds.]
___nick___ has joined #u-boot
<Tartarus>
mkorpershoek: OK, let me know when you're done for the day, or is there nothing else worth testing on?
<mkorpershoek>
I don't know much (upstream) devices using this. I've ran the tests on sandbox as well
alexxy has joined #u-boot
<Tartarus>
Alright, thanks
<mkorpershoek>
sorry for the very late notice, I don't have any automated tested in place so I did not catch this earlier
<Tartarus>
Yeah, always room for more tests
<mkorpershoek>
the good thing is that VIM3 has android boot image v2 and the TI AM62X has boot image v4 so we covered both cases
alexxy has quit [Quit: No Ping reply in 180 seconds.]
<mkorpershoek>
I'm done for the day
<Tartarus>
OK, thanks
ikarso has joined #u-boot
alexxy has joined #u-boot
<sng>
Kwiboo you mention address overlap, is this happening even after applying the EFI series that I had shared earlier?
<sng>
Kwiboo pivi fwiw, the efi_free_pool() error log was also reported on one of the xilinx board where the lmb patches were being tested. and the error went away after applying the efi series. so i would suggest testing on next after applying that series
<sng>
Kwiboo: nice. thanks for testing. Tartarus sjg1 apalos I guess one more reason why we need to make progress on getting this merged
<Tartarus>
sng: I think you agreed there would be at least a v2 of what you sent, with some changes made?
urja has joined #u-boot
<apalos>
Kwiboo: because of how EFI treats memory, we mark all of u-boot memory as "EFI_CONVENTIONAL_MEMORY"
<apalos>
Which basically means 'free memory'
<sng>
Tartarus I am holding on to sending any further versions as there is still some misalignement when it comes to a series from Simon
<apalos>
Now we were not protecting that memory up to now and EFI allocates top down.
<sng>
Tartarus about using malloc for efi_allocate_pool()
<apalos>
Which means that manually loading something in the top memory could potentially overwrite something
<apalos>
What I assume is that existing location of theinitrd was close enough, so when the LMB series allocated a few more pages it blew up
<apalos>
and thanks for testin Kwiboo
<apalos>
Which brings me to my next point, since you boot ubuntu, give EFI a shot. It's supposed to make your life easier on bootind sitros
<apalos>
distros*
<apalos>
sng: I already replied publicly, I just think that syncup event should die. Other than that it looked ok,
<apalos>
I'll have a closer look on v2
mmu_man has quit [Ping timeout: 252 seconds]
<sng>
apalos Tartarus okay, i can put out a v2. but Simon had also mentioned that he does not see these changes getting merged till there is resolution on his series
<apalos>
the lmb stuff fix that in a different way, which is way more elegant
<Kwiboo>
apalos: thanks for details, boot_ramdisk_high() seem to be what moved ramdisk to high mem allocated by lmb, ramdisk was initially loaded to a much lower mem addr 0x12180000, so I can understand that there was some issues before efi and lmb are in sync
<apalos>
yes
<apalos>
that's exactly the reason for those LMB series
<apalos>
EFI was notyfying LMB for the allocations, but not the other way around :>
<Kwiboo>
hehe, also this was not full ubuntu only a minimal setup to quickly test linux kernel builds with a minimal busybox rootfs/ramdisk, for a normal setup I typically use efi boot :-)
ikarso has quit [Quit: Connection closed for inactivity]
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
alexxy has quit [Quit: No Ping reply in 180 seconds.]
alexxy has joined #u-boot
<sjg1>
Kwiboo: OK good, thanks for trying it
prabhakalad has quit [Ping timeout: 248 seconds]
prabhakalad has joined #u-boot
enok has quit [Ping timeout: 265 seconds]
warpme has joined #u-boot
alexxy has quit [Quit: No Ping reply in 180 seconds.]
alexxy has joined #u-boot
prabhakalad has quit [Ping timeout: 260 seconds]
<sjg1>
apalos: Oops, I mean which my patch does
prabhakalad has joined #u-boot
alexxy has quit [Quit: No Ping reply in 180 seconds.]
alexxy has joined #u-boot
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alexxy has quit [Quit: No Ping reply in 180 seconds.]
alexxy has joined #u-boot
guest92 has joined #u-boot
alexxy has quit [Quit: No Ping reply in 180 seconds.]
alexxy has joined #u-boot
guest92 has quit [Quit: Client closed]
alexxy has quit [Quit: No Ping reply in 180 seconds.]
alexxy has joined #u-boot
<marex>
mkorpershoek: you know ... looking at cmd/usb_mass_storage.c while (1) { dm_usb_gadget_handle_interrupts(udc); ... } , I think this could very well be a cyclic framework job too , so we could have UMS in the background, while still running U-Boot shell
alexxy has quit [Ping timeout: 252 seconds]
alexxy has joined #u-boot
alexxy has quit [Ping timeout: 248 seconds]
vagrantc has quit [Quit: leaving]
alexxy has joined #u-boot
alexxy has quit [Quit: No Ping reply in 180 seconds.]
alexxy has joined #u-boot
alperak has quit [Quit: Connection closed for inactivity]
slobodan has quit [Ping timeout: 246 seconds]
alexxy has quit [Quit: No Ping reply in 180 seconds.]
alexxy has joined #u-boot
alexxy has quit [Read error: Connection reset by peer]
alexxy has joined #u-boot
alexxy has quit [Quit: No Ping reply in 180 seconds.]