jwillikers has quit [Remote host closed the connection]
mripard_ has quit [Ping timeout: 264 seconds]
zkrx has quit [Ping timeout: 265 seconds]
zkrx has joined #u-boot
mripard has joined #u-boot
Rusty_Almighty has joined #u-boot
v0|d has quit [Ping timeout: 250 seconds]
Rusty_Almighty has quit [Quit: Leaving.]
Rusty_Almighty has joined #u-boot
Rusty_Almighty has quit [Quit: Leaving.]
Rusty_Almighty has joined #u-boot
<Rusty_Almighty>
Is any one here aware of problems on u-boot booting the ipxe.efi images while handling prompted input?
Rusty_Almighty has quit [Quit: Leaving.]
Rusty_Almighty has joined #u-boot
Rusty_Almighty has quit [Quit: Leaving.]
Rusty_Almighty has joined #u-boot
Rusty_Almighty has quit [Quit: Leaving.]
Rusty_Almighty has joined #u-boot
Rusty_Almighty has quit [Ping timeout: 265 seconds]
Rusty_Almighty has joined #u-boot
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
guillaume_g has joined #u-boot
fdanis_away is now known as fdanis
guillaume_g has quit [Quit: Konversation terminated!]
guillaume_g has joined #u-boot
frieder has joined #u-boot
agust has joined #u-boot
mckoan|away is now known as mckoan
sstiller has joined #u-boot
matthias_bgg has joined #u-boot
<milkylainen_>
sjg1: Sorry. Not familiar with U-boot development. But where is u-boot-dm/efi-working located? repo?
Rusty_Almighty has quit [Ping timeout: 245 seconds]
Rusty_Almighty has joined #u-boot
Rusty_Almighty has quit [Client Quit]
Rusty_Almighty has joined #u-boot
<milkylainen_>
Ah. Custodian trees.
Rusty_Almighty has quit [Ping timeout: 265 seconds]
Rusty_Almighty has joined #u-boot
<milkylainen_>
Is machine serving custodian trees like... really slow or has a sucking straw for an internet pipe? I'm not getting much above 100k/sec.
<__ad>
checking "conf" fit signature, i get "Error in Modular exponentation" and "Bad data hash". mmm sign process seems correct
<__ad>
getting crazy. on signature check failures maybe some more info may be useful
tnovotny has joined #u-boot
matthias_bgg has quit [Ping timeout: 245 seconds]
sszy has joined #u-boot
<apalos>
Rusty_Almighty: i never used the input, I always compiled ipxe with a boot script
matthias_bgg has joined #u-boot
milkylainen_ has quit [Ping timeout: 265 seconds]
tnovotny has quit [Quit: Leaving]
__ad has quit [Excess Flood]
ad__ has joined #u-boot
zibolo has quit [Quit: bye]
kallisti5 has quit [Ping timeout: 265 seconds]
kallisti5 has joined #u-boot
mmu_man has joined #u-boot
milkylainen_ has joined #u-boot
indy_ has quit [Ping timeout: 260 seconds]
indy has joined #u-boot
indy has quit [Ping timeout: 265 seconds]
indy has joined #u-boot
indy has quit [Ping timeout: 265 seconds]
indy has joined #u-boot
indy has quit [Read error: Connection reset by peer]
indy has joined #u-boot
ad__ has joined #u-boot
ad__ has quit [Changing host]
jwillikers has joined #u-boot
jwillikers has quit [Remote host closed the connection]
<Tartarus>
sjg1: You should still have access to bill-the-cat, if you can't reproduce it locally, and try there
<milkylainen_>
sjg1: Did a standard efi app32 defconfig. The resulting binary won't start in the EDK2 shell. Shell prompt just returns. No printouts or anything.
<milkylainen_>
any hints?
<sjg1>
milkylainen_: Are you using 32-bit efi?
<sjg1>
Tartarus: ok will try in a few mins
<milkylainen_>
sjg1: EDK2 in Virtualbox for a 64-bit machine. No idea if the EFI implementation is running 32 or 64 bit mode. I don't know how to check UEFI implementation bitness?
<milkylainen_>
Apparently Virtualbox is running a 64-bit UEFI for a 64-bit Guest.
<milkylainen_>
Which makes sense.
<milkylainen_>
I don't get this. How is this done on all normal systems that boot on both 32 and 64 bit UEFI implementations?
<sjg1>
milkylainen_: yes. You could try yo figure out why the tool chain crashes for 64 bit, or use the qemu script provided to try 32 bit
Rusty_Almighty has quit [Quit: Leaving.]
<sjg1>
milkylainen_: So long as everything is the same bitness, EFI is happy. You cannot run an app with a different bitness
sstiller has quit [Quit: Leaving]
<milkylainen_>
sjg1: Yeah. Vaguely remember that. But damn is it unfriendly. How hard can it be looking at the PE/COFF headers and go like "hey stupid, wrong bitness application".
<milkylainen_>
A return with absolutely _zilch_ information is hardly helpful.
<milkylainen_>
Sorry about the aggravated clueless user attitude btw. :)
<sjg1>
milkylainen_: Yes I agree is it really odd. There isn't a lot of upstream development on UEFI though. Almost all of the computers use a closed-source and private build. So I suppose no one rubs off the corners
fdanis is now known as fdanis_away
<sjg1>
Tartarus: OK I can repeat the problem in my lab...I need to hook it up to gitlab again so this is easier. Will get back to this later
LinuxHackerman has quit [Ping timeout: 260 seconds]
edrex[m] has quit [Ping timeout: 260 seconds]
samueldr has quit [Ping timeout: 260 seconds]
cpackham[m] has quit [Ping timeout: 260 seconds]
stefanro has quit [Ping timeout: 265 seconds]
stefanro has joined #u-boot
mmind00 has quit [Ping timeout: 264 seconds]
mmind00 has joined #u-boot
chrfle_ has joined #u-boot
chrfle has quit [Ping timeout: 252 seconds]
chrfle_ is now known as chrfle
<sjg1>
Tartarus: the problem is the top of hash.h, needs to use CONFIG_IS_ENABLED(), otherwise the hash buffer is too small. That also explains why it works on snow, since it enables CONFIG_SHA512. Should we still with just including kconfig.h where needed? It seems safer to me
<Tartarus>
sjg1: I worry about these files that we automatically usually include, but then don't, for tools
<mrnuke>
sjg1: HASH_MAX_DIGEST_SIZE ?
<mrnuke>
If so, can't we just #define it to 64 for all cases?
clarity has joined #u-boot
<Tartarus>
I don't _think_ it ends up being safe to globally include linux/kconfig.h for tools, due to the oddball pollution we get from CONFIG symbols that turn in to a function, and some other fun #include games
redbrain has joined #u-boot
LinuxHackerman has joined #u-boot
<Tartarus>
I'm trying to take Yamada-san's commentary in a constructive manner. I do really wonder about making the host tools just use openssl/libressl for hashing functions, and then we need to think harder about how to clean up / separate FIT related parsing maybe, to be re-used in both cases.
samueldr has joined #u-boot
<Tartarus>
And I kinda think verifying our hashing in U-Boot vs hashes done via the normal libraries is useful to verify we're doing it right.
<sjg1>
Tartarus: That is the fix, applied to 'hash: Use Kconfig to enable hashing in host tools and SPL'
<sjg1>
Tartarus: Is it easier if I resend the series?
<mrnuke>
sjg1: why not just define HASH_MAX_DIGEST_SIZE to 64 without the kconfig madness ?
cpackham[m] has joined #u-boot
<Tartarus>
sjg1: I can fold in that change, but what about what mrnuke says?
Rusty_Almighty has joined #u-boot
<Tartarus>
and that fdt_support.h bit comes in, on the next patch
<milkylainen_>
sjg1: Yeah. I can confirm it segfaults with a recent linker (binutils 2.37). It reads the various archives from main and chokes under the disk/ builtin. Same for you?
<milkylainen_>
I saw a fd issue, but that seems closed in 2.37, so not that one.
guillaume_g has quit [Quit: Konversation terminated!]
frieder has quit [Remote host closed the connection]
<sjg1>
Tartarus: Yes it comes in the next patch, but needs to be in this one now to avoid a build error
<sjg1>
Tartarus: What is mrnuke's question?
<sjg1>
mrnuke: Yes your test catches this problem and it's a great test to have. I just wish it was in the tree when I did my series! It will be useful in future
<sjg1>
mrnuke: Yes I thought about that too...quite an increase in stack size though
matthias_bgg has quit [Ping timeout: 265 seconds]
<mrnuke>
sjg1: by 32 bytes?
<sjg1>
Yes, or multiples of that depending on the call stack which I haven't checked. But in SPL that matters
tre has joined #u-boot
<mrnuke>
Is it a significant increase, or an ominous one?
<mrnuke>
sjg1: ^
<sjg1>
mrnuke: I'm not sure, but SPL is pretty critical so we try to take fairly extreme measures to keep it small
<mrnuke>
sjg1: It seems like a microoptimization to me. We might as well set MAX_HASH_SIZE to 4 if only CRC32 is enabled, but that hashn't compe up as an issue
<Tartarus>
So, funny enough, the variable re-scoping stuff causes minor growth, because of how the compiler optimizes things, which is funny and kinda wrong feeling