Tartarus changed the topic of #u-boot to: SOURCE MOVED TO https://source.denx.de/u-boot/u-boot.git / U-Boot v2021.10 is OUT / Merge Window is OPEN until 25 October 2021 / Release v2022.01 is scheduled for 10 January 2022 / http://www.denx.de/wiki/U-Boot / Channel archives at https://libera.irclog.whitequark.org/u-boot
Rusty_Almighty has quit [Quit: Leaving.]
zibolo has quit [Ping timeout: 252 seconds]
zibolo has joined #u-boot
mmu_man has quit [Ping timeout: 265 seconds]
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]
indy has quit [Ping timeout: 265 seconds]
jwillikers has joined #u-boot
mckoan is now known as mckoan|away
indy has joined #u-boot
torez has joined #u-boot
indy has quit [Ping timeout: 265 seconds]
<sjg1> milkylainen_: They are described here: https://www.denx.de/wiki/U-Boot/CustodianGitTrees
<milkylainen_> sjg1: mm. btw. default efi appconfig?
<sjg1> milkylainen_: What do youi mean?
<milkylainen_> efi-working, what configuration did you use?
<milkylainen_> I tried building something, got a build, but empty binaries. Without the build failing.
<milkylainen_> used efi-x86_app64_defconfig as base
<sjg1> milkylainen_: Oh yes, see the docs for that. Try efi-x86_app32
<milkylainen_> mkay.
zibolo has joined #u-boot
<milkylainen_> sjg1: Better. :)
indy has joined #u-boot
<sjg1> milkylainen_: Yes it would be :-)
<sjg1> Tartarus: What is the hash-images.its file in your mkimage test? Just something that adds hashes?
<Tartarus> sjg1: It's generated by the test, yes
<Tartarus> It's test/py/tests/test_fit_hashes.py going along and failing
<mrnuke> sjg1: test/py/tests/vboot/hash-images.its. I wrote that by hand. It's part of the tree
<mrnuke> The question is if this new test caught an actual error, or vice-versa
<Tartarus> Oh it caught a new regression
<Tartarus> WIthout further work, tools don't have what they need in order for CONFIG_IS_ENABLED(FOO) to evaluate correctly in all cases.
<Tartarus> So the tool was told to use an algorithm it didn't have, failed, test caught failure
<Tartarus> Quite happy we have that test :)
<mrnuke> Yay!
<mrnuke> I am almost converted to The Church of The Holy Testing
<sjg1> Tartarus: mrnuke: OK I got it, I has not rebased. But I cannot repeat the problem yet
<sjg1> Tartarus: Are you saying that mkimage crashes?
<Tartarus> sjg1: It shows what I put in the email, here
<Tartarus> ubuntu 18.04 host even, so not super new host tools
<Tartarus> Note that sandbox doesn't fail here
<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
<Tartarus> ok
sszy has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
vagrantc has joined #u-boot
clarity has quit [Ping timeout: 240 seconds]
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.
edrex[m] has joined #u-boot
<sjg1> Tartarus: Yes I agree, that makes sense
<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
<mrnuke> sjg1: s/Kconfig madness/ #define MAX_HASH_SIZE 64/ ?
<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
Rusty_Almighty has quit [Quit: Leaving.]
<sjg1> mrnuke: I tend to agree, but I still have this thread in my distance memory: https://patchwork.ozlabs.org/project/uboot/patch/1356548233-5570-17-git-send-email-sjg@chromium.org/
<mrnuke> sjg1: "I have ended up just using #ifdef" ? Oh my! What heresy! :p
tre has quit [Remote host closed the connection]
torez has quit [Ping timeout: 245 seconds]
<sjg1> milkylainen_: yes that's what I see. It could be a toolchain bug, but it could also be the we are using the wrong 64-bit flags. Hard to know
<sjg1> mrnuke: Yes, desperate measures
sbach has quit [Read error: Connection reset by peer]
<milkylainen_> sjg1: Must be a bug. ld.bfd shouldn't choke on input like that.
sbach has joined #u-boot
zkrx has quit [Ping timeout: 265 seconds]
torez has joined #u-boot
GNUtoo has quit [Quit: leaving]
GNUtoo has joined #u-boot
redbrain has quit [Ping timeout: 265 seconds]
GNUtoo has quit [Client Quit]
GNUtoo has joined #u-boot
<mrnuke> sjg1: I imagine a comic book where Captain #ifdef is either the hero or the villain
<mrnuke> Tartarus: what do you use when you make "Resync with savedefconfig"? Just "moveconfig.py --force-sync"
<mrnuke> ?
v0|d has joined #u-boot
<Tartarus> mrnuke: -sC
<mrnuke> Tartarus: thank you!
jwillikers has quit [Remote host closed the connection]
georgem has quit [Ping timeout: 252 seconds]
cengiz_io has quit [Ping timeout: 240 seconds]
Crofton_ has quit [Ping timeout: 252 seconds]
lvrp16 has quit [Ping timeout: 268 seconds]
robher has quit [Ping timeout: 260 seconds]
ldts has quit [Ping timeout: 260 seconds]
sjg1 has quit [Ping timeout: 260 seconds]
pbrobinson has quit [Ping timeout: 264 seconds]
bradfa has quit [Ping timeout: 250 seconds]
dgilmore has quit [Ping timeout: 268 seconds]
NishanthMenon_ has quit [Ping timeout: 246 seconds]
elvishjerricco has quit [Ping timeout: 240 seconds]
mithro has quit [Ping timeout: 260 seconds]
senzilla has quit [Ping timeout: 260 seconds]
smurray has quit [Ping timeout: 260 seconds]
Tartarus has quit [Ping timeout: 268 seconds]
ezequielg has quit [Ping timeout: 268 seconds]
narmstrong has quit [Ping timeout: 246 seconds]
ullbeking has quit [Ping timeout: 250 seconds]
ccaione has quit [Ping timeout: 250 seconds]
paulbarker has quit [Ping timeout: 260 seconds]
drewfustini_ has quit [Ping timeout: 260 seconds]
smurray has joined #u-boot
behanw has quit [Ping timeout: 268 seconds]
sjg1 has joined #u-boot
iopaniuk has quit [Ping timeout: 268 seconds]
jamestperk has quit [Ping timeout: 264 seconds]
tucanae47_ has quit [Ping timeout: 264 seconds]
bradfa has joined #u-boot
jamestperk has joined #u-boot
dgilmore has joined #u-boot
NishanthMenon_ has joined #u-boot
mithro has joined #u-boot
paulbarker has joined #u-boot
cengiz_io has joined #u-boot
senzilla has joined #u-boot
behanw has joined #u-boot
elvishjerricco has joined #u-boot
ldts has joined #u-boot
iopaniuk has joined #u-boot
narmstrong has joined #u-boot
ccaione has joined #u-boot
drewfustini_ has joined #u-boot
pbrobinson has joined #u-boot
Crofton_ has joined #u-boot
Tartarus has joined #u-boot
tucanae47_ has joined #u-boot
ezequielg has joined #u-boot
<Tartarus> sjg1: Is something like this intentional?
<Tartarus> poking it more myself
<Tartarus> sjg1: So in this case, the board does not enable CONFIG_FIT_RSASSA_PSS but it is set (of course) for tools
<sjg1> Tartarus: Hmmm actually I'm afraid it looks wrong.
ullbeking has joined #u-boot
<sjg1> Tartarus: Seems like #ifdef CONFIG_FIT_RSASSA_PSS needs to be kept, but change to #if CONFIG_IS_ENABLED(...
georgem has joined #u-boot
<sjg1> Because we don't want the driver when it is not defined
robher has joined #u-boot
lvrp16 has joined #u-boot
<sjg1> Tartarus: Like rsa_sign_with_key() does
<sjg1> Tartarus: Looks like I missed this when rebasing on top of de41f0ee0d68
<Tartarus> Yeah, so I think I see the line to rework then
<sjg1> Tartarus: Just above u32_i2osp() I think
<Tartarus> OK, yeah, got that fixed now
<Tartarus> now to check the other spots again
<sjg1> Tartarus: this feels like surgery
agust has quit [Ping timeout: 265 seconds]
agust has joined #u-boot
agust has quit [Quit: Leaving.]
indy has quit [Quit: ZNC 1.8.2 - https://znc.in]
indy has joined #u-boot
<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
<Tartarus> But I'm gonna go with it
mmu_man has quit [Ping timeout: 265 seconds]