Tartarus changed the topic of #u-boot to: SOURCE MOVED TO https://source.denx.de/u-boot/u-boot.git / U-Boot v2024.07, v2024.10-rc5 are OUT / Merge Window is CLOSED, next branch is OPEN / Release v2024.10 is scheduled for 07 October 2024 / Channel archives at https://libera.irclog.whitequark.org/u-boot
ikarso has quit [Quit: Connection closed for inactivity]
sugoi has joined #u-boot
sugoi has quit [Ping timeout: 252 seconds]
jclsn has quit [Ping timeout: 248 seconds]
jclsn has joined #u-boot
mmu_man has quit [Ping timeout: 272 seconds]
sugoi has joined #u-boot
sugoi1 has joined #u-boot
sugoi has quit [Ping timeout: 265 seconds]
sugoi1 is now known as sugoi
RobertBerger has joined #u-boot
rber|res has quit [Ping timeout: 252 seconds]
naoki has joined #u-boot
naoki has quit [Quit: naoki]
sugoi has quit [Ping timeout: 265 seconds]
sugoi has joined #u-boot
sugoi1 has joined #u-boot
sugoi has quit [Ping timeout: 248 seconds]
sugoi1 is now known as sugoi
ikarso has joined #u-boot
zsoltiv_ has quit [Ping timeout: 246 seconds]
sugoi has quit [Ping timeout: 248 seconds]
sugoi has joined #u-boot
sugoi has quit [Ping timeout: 252 seconds]
pbsds30 has joined #u-boot
pbsds3 has quit [Ping timeout: 276 seconds]
pbsds30 is now known as pbsds3
monstr has joined #u-boot
ldevulder has joined #u-boot
eballetbo has joined #u-boot
mripard has joined #u-boot
mmu_man has joined #u-boot
naoki has joined #u-boot
naoki has quit [Client Quit]
naoki has joined #u-boot
enok has joined #u-boot
naoki has quit [Client Quit]
sugoi has joined #u-boot
enok has quit [Ping timeout: 252 seconds]
mmu_man has quit [Ping timeout: 245 seconds]
sugoi has quit [Ping timeout: 265 seconds]
warpme has joined #u-boot
prabhakalad has joined #u-boot
enok has joined #u-boot
enok has quit [Ping timeout: 265 seconds]
sszy has joined #u-boot
alperak has joined #u-boot
slobodan has joined #u-boot
enok has joined #u-boot
mmu_man has joined #u-boot
mmu_man has quit [Ping timeout: 260 seconds]
naoki has joined #u-boot
naoki has quit [Client Quit]
naoki has joined #u-boot
<MWelchUK> sjg1: After reworking the POC into a more upstreamble state and adding tests I realised there's a bit of a flaw in my plan...
<MWelchUK> I'd been doing something like `bootflow scan mmc; bootflow select 0; bootmeth set extlinux fallback 1; bootflow boot`, which works.
<MWelchUK> What doesn't work is `bootmeth set extlinux fallback 1; bootflow scan -lb`, because `bootflow scan` starts by deleting the known boot methods and thus any settings performed before the scan runs...
<MWelchUK> Which I guess is also why the "bootmeths" env variable is set?
___nick___ has joined #u-boot
alperak has quit [Quit: Connection closed for inactivity]
___nick___ has quit [Client Quit]
___nick___ has joined #u-boot
guest92 has joined #u-boot
<sjg1> MWelchUK: Are you sure that 'bootflow scan' it is deleting the bootmeths? Where is it doing that?
<MWelchUK> sjg1: `do_bootflow_scan()` calls `bootstd_clear_glob()`.
alperak has joined #u-boot
<apalos> sjg1: as far as that ACPI thread and the efi memory allocations are concerned,
<apalos> I dont mind having a call, but I am not willing to accept patches that make no sense
<apalos> and in all these emails I havent seen one single clear argument,
<apalos> There's "I like doing bloblist list and see the ACPI table" which barely clasifies as one
<apalos> On the efi allocate poool things are even worst,
<apalos> It's a hack to begin with since you only allocate half of memory there and the rest in top memory. So you basically contradict yourself every time you say "oh but memory is linear and nice"
<apalos> It violates the EFI spec which clearly says "EFI allocate pool, allocate pages" and I've explained the security reasons over and over again
<apalos> and apart from the EFI_BOUNCE_BUFFER there's literally 0 fragmentation
<apalos> So please do send me a reproducer, of where EFI overwrites whatever you think is overwriting
naoki has quit [Quit: naoki]
alan_o has quit [Remote host closed the connection]
<apalos> and ofc there's always this misconception you have that "oh we can boot efi when we are about to launch an application"
<apalos> EFI variables, TPM and measurements efi capsule updates and I am pretty sure I'll find more if I keep thinking
<apalos> EFI allocates memory, which is reserved now by LMB. Just like the U-Boot binary does
<apalos> So I fail to see any difference there, especially since the memory is allocated top down and you dont interfere with anything
<apalos> unless you want to load a 4gb image and you just miss 100kb from top memory
mmu_man has joined #u-boot
alan_o has joined #u-boot
alan_o has quit [Remote host closed the connection]
alan_o has joined #u-boot
aat596 has quit [Ping timeout: 276 seconds]
alan_o has quit [Remote host closed the connection]
alan_o has joined #u-boot
alan_o has quit [Remote host closed the connection]
alan_o has joined #u-boot
aat596 has joined #u-boot
goliath has joined #u-boot
___nick___ has quit [Ping timeout: 276 seconds]
__nick__ has joined #u-boot
guest92 has quit [Quit: Client closed]
<sjg1> MWelchUK: Yes that is removing the existing bootflows. Is that a problem? The bootmeth device (and your setting) should remain
<sjg1> apalos: OK I tried to reply again, but I am not really seeing a lot of progress. We seem to have two issues: where tables are stored, and whether it is OK to call efi-allocate-pages before booting the app
<apalos> the ACPI tables is really not worth the pain
<apalos> I like to keep the bloblist clean, so i dont see why, noone consumes it
<apalos> In fact, the OS will just discard it the moment it boots
<apalos> if you manage to convince people it's needed, its a 2 line change
<apalos> So I dont understand why we have to do it like this now, instead of doing it as we should
<apalos> the EFI allocations are completely different as I said. We are working on fixing up memory permissions
<apalos> And moving this outside pages allocation just makes this impossible, because the mallc area, is going to be RW on a proper system
<apalos> apart from the EFI bounce buffer, which might cause issues, and we can look into it
<apalos> There's literally nothing wrong with what wee do in EFI with the LMB now
<apalos> any piece of memory we allocate, (which again we make sure is out of the way) we say 'oh reserved now'
<apalos> and since EFI allocaes *via* LMB, or will alllocate by calling LMB
<apalos> There's 0 chances we overwrite something. And even if we do, that's an LMB bug now
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
enok has quit [Ping timeout: 252 seconds]
Hypfer67 has joined #u-boot
Hypfer6 has quit [Ping timeout: 272 seconds]
Hypfer67 has quit [Ping timeout: 272 seconds]
Hypfer6 has joined #u-boot
sugoi has joined #u-boot
sugoi has quit [Ping timeout: 248 seconds]
monstr has quit [Remote host closed the connection]
indy- is now known as indy
Hypfer6 has quit [Ping timeout: 272 seconds]
mmu_man has quit [Ping timeout: 252 seconds]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #u-boot
dsimic has quit [Ping timeout: 260 seconds]
dsimic has joined #u-boot
alperak has quit [Quit: Connection closed for inactivity]
mmu_man has joined #u-boot
mmu_man has quit [Ping timeout: 265 seconds]
mmu_man has joined #u-boot
Stat_headcrabbed has joined #u-boot
mmu_man has quit [Ping timeout: 246 seconds]
mmu_man has joined #u-boot
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sugoi has joined #u-boot
<MWelchUK> sjg1: Hmm, then I've got the private storage tied to the wrong thing...
sszy has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
Stat_headcrabbed has joined #u-boot
slobodan has quit [Ping timeout: 264 seconds]
warpme has joined #u-boot
enok has joined #u-boot
sugoi has quit [Quit: sugoi]
ukky_ has quit [Ping timeout: 245 seconds]
ukky has quit [Ping timeout: 252 seconds]
ukky has joined #u-boot
ukky_ has joined #u-boot
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
__nick__ has quit [Ping timeout: 252 seconds]
___nick___ has joined #u-boot
<macromorgan> does anyone have experience reading an SDIO product ID/vendor ID from within U-Boot?
<macromorgan> I'm trying, as a service to users, to make a bootloader that works for a bunch of different devices and I have yet another device with a conflicting hardware ID. The only changes versus an existing device is the larger battery (which I cannot detect) and a different SDIO wifi/UART bluetooth adapter.
vagrantc has joined #u-boot
ldevulder has quit [Quit: Leaving]
<marex> m
<marex> macromorgan: no, hum ... look at what 'mmc rescan' does , it does read SOME basic IDs from the card
<marex> macromorgan: oh wait
<marex> macromorgan: try 'CONFIG_CMD_MMC_REG' and the 'reg' command
<marex> macromorgan: that will let you read _some_ registers, but I think SD card registers are not supported (should be easy to add) , then maybe you can read out some IDs from the card and use that somehow ...
<marex> see cmd/mmc.c do_mmc_reg()
slobodan has joined #u-boot
warpme has joined #u-boot
<macromorgan> okay, thanks
<macromorgan> card did not respond to voltage select when I try to access it with the mmc command, but I can dig into that more
warpme has quit [Ping timeout: 252 seconds]
ukky is now known as Guest404
Guest404 has quit [Killed (calcium.libera.chat (Nickname regained by services))]
ukky_ is now known as ukky
ukky_ has joined #u-boot
paulbarker_ has joined #u-boot
lane_ has joined #u-boot
sfo_ has joined #u-boot
d4ve_ has joined #u-boot
cyrozap_ has joined #u-boot
Ultrasauce has joined #u-boot
manawyrm- has joined #u-boot
<sjg1> My position is that tables should be in the bloblist. We can find them, list them, etc. It is quite useful and it happens to put them in the U-Boot memory-area, which avoids EFI being involved in the allocation
<sjg1> On memory allocations, we are talking about 6-8 allocations which happen today using page allocations. We should cross the memory-permission bridge when we come to it. I can't imagine it will cause any problems, but if it does, we can look at it
warpme has joined #u-boot
derRichard has quit [*.net *.split]
cyrozap has quit [*.net *.split]
d4ve has quit [*.net *.split]
lane has quit [*.net *.split]
sfo has quit [*.net *.split]
iprusov_ has quit [*.net *.split]
manawyrm has quit [*.net *.split]
polprog has quit [*.net *.split]
sauce has quit [*.net *.split]
slow99 has quit [*.net *.split]
paulbarker has quit [*.net *.split]
agraf has quit [*.net *.split]
aurel32 has quit [*.net *.split]
calebccff has quit [*.net *.split]
d4ve_ is now known as d4ve
cyrozap_ is now known as cyrozap
sfo_ is now known as sfo
paulbarker_ is now known as paulbarker
derRichard has joined #u-boot
iprusov_ has joined #u-boot
polprog has joined #u-boot
agraf has joined #u-boot
slow99 has joined #u-boot
calebccff has joined #u-boot
aurel32 has joined #u-boot
<sjg1> apalos: ^
<marex> macromorgan: is it actually powered on ?
mmu_man has quit [Ping timeout: 265 seconds]
warpme has quit [Ping timeout: 252 seconds]
mmu_man has joined #u-boot
alexxy has quit [Ping timeout: 252 seconds]
alexxy has joined #u-boot
warpme has joined #u-boot
alan_o has quit [Remote host closed the connection]
alan_o has joined #u-boot
<macromorgan> yes, it should be
<macromorgan> the regulators say so anyway
mahk has quit [Ping timeout: 255 seconds]
warpme has quit [Ping timeout: 248 seconds]
mahk has joined #u-boot
enok has quit [Ping timeout: 264 seconds]
eballetbo has quit [Quit: Connection closed for inactivity]
mahk has quit [Ping timeout: 276 seconds]
mahk has joined #u-boot
mahk has quit [Ping timeout: 245 seconds]
mahk has joined #u-boot
warpme has joined #u-boot
mahk has quit [Ping timeout: 252 seconds]
mahk has joined #u-boot
warpme has quit [Ping timeout: 255 seconds]
<macromorgan> hmm... if SDIO doesn't pan out, is there a way to send/receive serial commands in U-Boot? From what I see so far all the MMC code is designed to work with storage (not SDIO), and all the serial code is designed to work with serial consoles (not other devices over serial)
mahk has quit [Ping timeout: 248 seconds]
enok has joined #u-boot
mahk has joined #u-boot
warpme has joined #u-boot
mahk has quit [Ping timeout: 276 seconds]
mahk has joined #u-boot
___nick___ has quit [Ping timeout: 255 seconds]
warpme has quit [Ping timeout: 264 seconds]
retr0id has quit [Ping timeout: 255 seconds]
enok has quit [Ping timeout: 260 seconds]
naoki has joined #u-boot
naoki has quit [Client Quit]
naoki has joined #u-boot
warpme has joined #u-boot
retr0id has joined #u-boot
warpme has quit [Ping timeout: 252 seconds]
warpme has joined #u-boot
warpme has quit [Ping timeout: 252 seconds]
goliath has quit [Quit: SIGSEGV]
tepperson has joined #u-boot
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
mripard has quit [Quit: mripard]
slobodan has quit [Ping timeout: 276 seconds]
warpme has joined #u-boot
tepperson has left #u-boot [#u-boot]
warpme has quit [Ping timeout: 255 seconds]
lehmanju has quit [Quit: The Lounge - https://thelounge.chat]
lehmanju has joined #u-boot
warpme has joined #u-boot
warpme has quit [Ping timeout: 252 seconds]
naoki has quit [Ping timeout: 276 seconds]
vagrantc has quit [Ping timeout: 252 seconds]
warpme has joined #u-boot
joeskb7 has quit [Quit: Lost terminal]
warpme has quit [Ping timeout: 260 seconds]
warpme has joined #u-boot
warpme has quit [Ping timeout: 255 seconds]
warpme has joined #u-boot
warpme has quit [Ping timeout: 248 seconds]
ikarso has quit [Quit: Connection closed for inactivity]