frieder has quit [Remote host closed the connection]
frieder has joined #u-boot
swiftgeek has quit [Ping timeout: 246 seconds]
swiftgeek has joined #u-boot
<calebccff>
sjg1: Tartarus: snapdragon and Apple platforms use LMB to allocate $kernel_addr_r, $loadaddr and various other similar buffers. With unifying LMB it would be great to also provide some default/automatic allocation for these so platforms don't have to care about them
<calebccff>
it's weird to have to allocate some memory regions to be used for storing a compressed and uncompressed kernel AND a (probably?) different region for storing data fetched over tftp, and a ramdisk, etc... Since it's unlikely all of these regions will be used at once, but also impossible to know which combinations might be
persmule 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]
slobodan has quit [Read error: Connection reset by peer]
slobodan has joined #u-boot
goliath has quit [Quit: SIGSEGV]
pbsds3 has quit [Ping timeout: 248 seconds]
pbsds3 has joined #u-boot
<Tartarus>
With LMB in -next, what apple/snapdragon do works as intended now
<Tartarus>
One of those things I need to look at is if we still have the concerns about memory ranges that we did, sigh, 15-20 years ago
<Tartarus>
The world is no longer 32bit chips and where a 4GB memory map is suddenly constrained
rockosov has quit [Ping timeout: 276 seconds]
rockosov has joined #u-boot
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<apalos>
that automatic mem selection is a good idea
<Tartarus>
Can be, yeah. And we're probably a lot less in to "load things in exact spots so that it can XIP the decompression" and more "any random but 8-byte aligned spot is good, actually"
frieder has quit [Remote host closed the connection]
<Kwiboo>
with next now merged into master, do we have any indication when the efi/lmb sync issue could be resolved? there is currently an overlap of the FDT loaded for kernel and lmb/efi memory touched before jumping to kernel using extlinux stdboot
<Kwiboo>
and trying to load/use a ramdisk my rockchip boards cannot boot unless I explicitly change to use EFI_LOADER=n
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
eballetbo has quit [Quit: Connection closed for inactivity]
<Kwiboo>
sjg1: "Loading Device Tree to 00000000ececb000, end 00000000ecedfd5f ... OK" and then "EFI: efi_add_memory_map_pg: 0xecedd000 0x1 7 no" in the middle of FDT memory
<Tartarus>
Kwiboo: can you paste/pastebin the extlinux.conf too please?
<Tartarus>
env is what would be seen with "make radxa-zero-3-rk3566_config u-boot-initial-env" I assume
<Kwiboo>
also no dtb or other file on fs, so FDT used is the control FDT from U-Boot
enok has joined #u-boot
enok has quit [Ping timeout: 255 seconds]
enok has joined #u-boot
enok has quit [Read error: Connection reset by peer]
enok has joined #u-boot
___nick___ has quit [Ping timeout: 246 seconds]
<Kwiboo>
when trying to use the initrd I typically see a crash or possible "efi_free_pool: illegal free" due to the memory overlap, v2024.10 is not affected so this was only next and now master, would be good to have the efi/lmb sync issue resloved before -rc1 ;-)
enok has quit [Ping timeout: 244 seconds]
<Kwiboo>
for now I will just use EFI_LOADER=n to also have LMB=n :-)
<Tartarus>
Yeah, sng will be posting v2 of his series soon I believe
alperak has quit [Quit: Connection closed for inactivity]
enok has joined #u-boot
enok71 has joined #u-boot
enok has quit [Ping timeout: 265 seconds]
enok71 is now known as enok
enok has quit [Ping timeout: 248 seconds]
enok has joined #u-boot
ikarso has quit [Quit: Connection closed for inactivity]
<Kwiboo>
another regression found in master: booting one of my rockchip rk3328 boards now take 15-20 seconds in SPL, with v2024.10 it took less than 1 second in SPL to load FIT and "Checking hash(es)" before jumping to TF-A and U-Boot proper, will try to dig deeper
enok has quit [Ping timeout: 252 seconds]
<sjg1>
Kwiboo: OK thank you, I see it. Yes EFI just uses whatever it likes at the moment :-( I am pleased to see some examples from others, as I was struggling to get people to believe me :-)
ikarso has joined #u-boot
Hypfer6 has quit [Quit: Ping timeout (120 seconds)]
Hypfer6 has joined #u-boot
vagrantc has joined #u-boot
goliath has quit [Quit: SIGSEGV]
slobodan has quit [Ping timeout: 252 seconds]
Hypfer6 has quit [Read error: Connection reset by peer]
Hypfer69 has joined #u-boot
atka has joined #u-boot
mmu_man has quit [Ping timeout: 252 seconds]
mmu_man has joined #u-boot
<Kwiboo>
commit 0252924ac6d4 ("mmc: dw_mmc: Extract FIFO data transfer into a separate routine") seem to be the first commit that cause super slow read from mmc in SPL on my board
naoki has joined #u-boot
mmu_man has quit [Ping timeout: 260 seconds]
mmu_man has joined #u-boot
ikarso has quit [Quit: Connection closed for inactivity]