ikarso has quit [Quit: Connection closed for inactivity]
vulpes2[m]111114 is now known as vulpes2[m]
ikarso has joined #u-boot
mmu_man has quit [Ping timeout: 245 seconds]
mmu_man has joined #u-boot
sng has quit [Remote host closed the connection]
teejay_ has quit [Ping timeout: 246 seconds]
teejay has joined #u-boot
sng_ has joined #u-boot
sng_ is now known as sng
sng has quit [Remote host closed the connection]
sng has joined #u-boot
sng_ has joined #u-boot
sng has quit [Read error: Connection reset by peer]
sng_ is now known as sng
sng has quit [Remote host closed the connection]
mmu_man has quit [Ping timeout: 246 seconds]
mmu_man has joined #u-boot
sng has joined #u-boot
sng has quit [Remote host closed the connection]
mmu_man has quit [Ping timeout: 246 seconds]
<LeSpocky>
trying to get cmd 'trace' to work on at91 sam9x60-curiosity board, but I always get "trace: recursion detected, disabling" …
<LeSpocky>
according to dm at least on timer driver is probed
prabhakarlad has quit [Quit: Client closed]
sng has joined #u-boot
sng has quit [Remote host closed the connection]
ikarso has quit [Quit: Connection closed for inactivity]
sng has joined #u-boot
sng has quit [Remote host closed the connection]
sng has joined #u-boot
indy_ has joined #u-boot
indy has quit [Ping timeout: 264 seconds]
mmu_man has joined #u-boot
sng_ has joined #u-boot
sng has quit [Read error: Connection reset by peer]
indy- has joined #u-boot
sng_ has quit [Remote host closed the connection]
indy_ has quit [Ping timeout: 264 seconds]
sng has joined #u-boot
sng_ has joined #u-boot
mmu_man has quit [Ping timeout: 260 seconds]
sng has quit [Ping timeout: 246 seconds]
sng_ is now known as sng
<sng>
sjg1 Tartarus should I send the next version where the capsule generation happens only in the CI run. I can also place the capsule input files in the build dir, as part of the CI setup, instead of having them in the u-boot source
<sng>
sjg1: I have tested the changes locally with the above setup. I will send the next version if you are okay with this.
<Tartarus>
Where did we end up on having just building sandbox normally still work?
<sng>
Tartarus: so in the normal sandbox build, the capsules will not be generated, unless we enable a Kconfig symbol. I am enabling the Kconfig symbol in the CI run, similar to what is being done for the trace test. using the Override switch.
<Tartarus>
ok
<sng>
sjg1: Simon, are you okay with this? if so, I will send the patches
<sjg1>
sng: I would prefer they are always built. Is there an advantage to skipping these in the normal build?
<Tartarus>
sjg1: That brings us back to always needing to build some capsule stuff before we can even build sandbox normally
<sng>
sjg1: yep. even we have to build capsules even in the normal builds, that would need having the input files in the u-boot source. like how it is currently in my V6 series.
camus has quit [Remote host closed the connection]
<sng>
sjg1 If we are to have the capsule input files only in the build dir, then the solution is to generate the capsules only as part of the CI run, or as part of the pytest run.
<sjg1>
sng you mean those 4 crt files?
<sng>
sjg1 those, and the other input files, like u-boot.bin.new, u-boot.env.new...
<sng>
sjg1 if we do something like how the trace test gets run in CI, then we can keep the capsule certs and other input files only in the build dir. like how you always wanted.
<sng>
moreover, for the sandbox platform at least, i don't think that the capsule generation is needed for normal builds. it is primarily aimed for testing the feature in CI
<sjg1>
sng: Does it hurt? Don't forget 'make qcheck' etc.
<sjg1>
sng: Your u-boot.new etc. files can become 'text' entries in binman, I think
<sjg1>
I don't see a problem (yet) with having the .crt stuff in board/sandbox and always building the capsules
<sng>
sjg1 if you are okay with having the input files under board/sandbox, we can build the capsules with normal build as well
<sng>
should i spin the next version moving the files under board/sandbox/ then?
<sng>
sjg1 i will also check using text entries for the contents of u-boot.bin.new etc. if that works, that'll be a pretty nifty solution
<sjg1>
sng: So just the 5 .crt, .esl, .key files? Can you use 'text' entry type for the others?
<sjg1>
sng: Also, please use a real name instead of SIGNER and SIGNER2. e.g. valid and bad
<sng>
sjg1 i will check if i can use the text entry for the other files. if that works, i have no issues with this solution as well. i worked on the CI based capsule generation because i thought that you wanted the input files only in the build dir.
goliath has quit [Quit: SIGSEGV]
<sjg1>
sng: No I meant we should not *output* files to the source dir. If they are checked into source control, that's fine
<sjg1>
sng: So CAPSULE_PRIV_KEY etc. should just be a leaf name, without a full path in it
<sng>
sjg1 actually, even in V6, the keys/esl are not an absolute path. they are pointing to the test/py/tests/test_efi_capsule/test_files/ directory.
<sjg1>
sng: I don't mean absolute, I mean leaf name only, i.e. 'valid.key'
<sng>
sjg1: hmm. that would mean passing something like board/sandbox/ as input path to binman. only then can we use only leaf names
<sng>
sjg1 else tools.get_input_filename will not find the keys
<sjg1>
sng: No, please just try it. If for some reason something I say doesn't work, ask me
<sjg1>
sng: See Makefile: -I $(srctree)/board/$(BOARDDIR)
<sjg1>
sng: If it doesn't work, we should fix it
<sng>
sjg1: fine then, let me try that. but just so that i am clear, you are okay with all the capsule entries in the u-boot.dtsi that will result in generation of the capsules. is that correct?
<sjg1>
sng: Yes, still happy at the moment, but getting more nervous each time you ask. Is there something strange I should know about?
vfazio has quit [Remote host closed the connection]
sng has joined #u-boot
vfazio has joined #u-boot
<sng>
sjg1: don't get nervous :-) nothing strange going around here. but tbh, the more I work on this, the more I get the feeling that a user who would want to build capsules through u-boot is also going to have a decent understanding about binman. which is why my initial design was using simple filenames.
<sng>
sorry, i meant a user who wants to build capsules through u-boot is going to *need to have* a decent understanding of binman. in coming up with the capsule entry nodes.
ezulian has quit [Ping timeout: 244 seconds]
mmu_man has quit [Ping timeout: 246 seconds]
marc1 has quit [Quit: WeeChat 3.6]
monstr has quit [Remote host closed the connection]
<sjg1>
sng: OK...you do have some extra things in there. I imagine something like this:
<sng>
sjg1: I believe the most important thing here is for the user to figure out how to pass in the input binary. and that is not in form of a filename(which is what I had in my initial versions). and if the input is something like a FIT, or a section image, it will be even more difficult for the user to get their head around this
<sng>
that is why I feel that the user will need at least some understanding of how binman works to construct an entry. and someone working with capsules, might not be very well versed with the concepts of binman
<sng>
sjg1 so someone who, for example wants to generate a capsule with a FIP image as input binary, would first need to understand how to construct an entry node for the fip, that would generate the fip, and which in turn would need to be the subnode of the capsule entry node.
<sng>
sjg1 so you see, a good amount of binman understanding needed here to build the capsule with the above example
hanetzer has joined #u-boot
hanetzer has quit [Ping timeout: 260 seconds]
hanetzer has joined #u-boot
prabhakarlad has joined #u-boot
ezulian has joined #u-boot
ezulian has quit [Ping timeout: 246 seconds]
macromorgan has quit [Quit: Leaving]
goliath has joined #u-boot
ikarso has joined #u-boot
sng has quit [Read error: Connection reset by peer]
<bswartz>
Hey guys is there a tagged version of u-boot that's more stable than v2023.07?
<bswartz>
I'm finding it frequently won't compile after I "make menuconfig" and change some options
goliath has quit [Quit: SIGSEGV]
ladis has joined #u-boot
<marex>
bswartz: works on my machine
<marex>
bswartz: details ?
sng has joined #u-boot
<vagrantc>
you could always try building from git...