<apalos>
however binman is an internal tool used in u-boot. mkeficapsule otoh is actually used and compiled by distros
frieder has joined #u-boot
<apalos>
the whole point here is that binman gets called at the end of the build
<apalos>
In which case you need to unpack the u-boot.bin inject the node and repack it again
<apalos>
Which is counterintuitive at best
<apalos>
and generating another dtb, just to be able to showhorn stuff into binman isnt the answer I am looking for here
<apalos>
So the first reponse was that "we have u-boot.bin, which lacks the signature node, why dont we generate *another*binary called u-boot-capsule.bin"
<apalos>
and that's were my comment on being disjoint with EFI goes
<apalos>
it doesnt make sense to generate multiple binaries, if capsule authentication is enabled the binary you built must contain all the necessary signatures etc
<apalos>
reading this is like "if you enable ethernet interfaces you'll get 2 binaries, u-boot.bin and u-boot-net.bin"
<apalos>
and networking wont work in the former
monstr has quit [Remote host closed the connection]
sng has quit [Remote host closed the connection]
frieder has quit [Remote host closed the connection]
frieder has joined #u-boot
sng has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
<Kwiboo>
apalos: I understood the big issue being that dtb was re-packaged, adding such u-boot.dtsi in arch/arm/dts will be auto included for all arm u-boot.dtb without any modification to Makefile or binman or need for repacking
<Kwiboo>
and having the signature node in the dtb appended to u-boot.bin is what you where aiming for if I am not mistaken?
sszy has joined #u-boot
<Kwiboo>
with that Kconfig default "", such simple ifdef would not work but having a common u-boot.dtsi with a working if would probably be most simple to just hide including esl behind a simple Kconfig option
<apalos>
Kwiboo: ah fair enough, yea that solves the dtb problem
<Kwiboo>
"Only one of these is selected but of course you can #include another one within that file, to create a hierarchy of shared files." so you may need to update all <vendor>-u-boot.dtsi
<apalos>
and I had a Kconfig was was producting a build error if the Kconfig option was empty
<apalos>
Kwiboo: that should be ok in u-boot.dtsi
<apalos>
becase the capsule update is included regardless of the hardware
<apalos>
so instead of injecting the node, we can just create a u-boot.dtsi and if the Kconfig is empty pop a build error
<Kwiboo>
something like that, looks like u-boot.dtsi may have to explicitly be included if any of the other <board/soc/vendor>-u-boot.dtsi i is found
<Kwiboo>
seting a default value for CONFIG_DEVICE_TREE_INCLUDES if EFI_CAPSULE_ESL_FILE could also be an option
mmu_man has joined #u-boot
<apalos>
Kwiboo: yea that makes a lot of sense thanks
ikarso has joined #u-boot
<apalos>
Kwiboo: so I think the easiest way to plug this is add a u-boot-cap-sig.dtsi
<apalos>
and if capsule authentication is enabled include that file to CONFIG_DEVICE_TREE_INCLUDES (and obviously the makefiles that pick that up)
<apalos>
so the only thing you would miss from that is pop an error if the .esl Kconfig file is empty, which is doable
<apalos>
automatically generating a capsule otoh has to go throught mkeficapsule, since that's what we have and distros use that as well
<apalos>
But that can be wired up via binman post build,
<apalos>
It's a gimmick since binman will just call mkeficapsule, but we can at least have binman ''''generating'''' the capsule
<Kwiboo>
yep, that sounds like a clean solution, embedd signature during normal build and run mkeficapsule from binman
<apalos>
yea exactly
<sjg1>
s/signature/public key/ right? We need to be careful not to confuse the terms
<sjg1>
apalos: I replied to Sugosh along similar lines
<apalos>
sjg1: yes i meant public key 'signature' is the .dts term, that's why I used it
<sjg1>
apalos: oh dear. So what is the thing in the efi capsule?
<apalos>
the capsule must be signed with the private key post build
<apalos>
and that's where calling the mkeficapsule tool with thepricate key would make sense,
<apalos>
This is exactly why I started yelling yesterday :>
<apalos>
the .dts entry is just the public portion of the key and *needs* to be in the binary the build system spits out
<apalos>
sjg1: a simplified version of how capsule updates work
<apalos>
the capsule contains headers(think of them as metadata)
<apalos>
that header has a uuid which point to a callback function the board has to call to update itself
<apalos>
So you download the capsule, some code autenticates it via normal public key crypto and then u-boot reads the metadata and decides what function to call and which flashes to write
<mwalle>
hi, is it possible to boot an aarch64 Image through "fastboot boot"? I'm using 'fastboot --header-version 2 --cmdline "earlycon" --dtb arch/arm64/boot/dts/mediatek/mt8195-demo.dtb boot arch/arm64/boot/Image'. In u-boot "fastboot usb 0". Download seems to work, it's also jumping, but I'm getting "XIP Kernel Image" which isn't correct I guess. Granted I'm using the mediathek u-boot. I'm just starting
<mwalle>
to evaluate that platform
<sjg1>
apalos: It would be much easier if you didn't use 'signature' to mean the signature in the EFI capsule and the public key in the dtb
<apalos>
sjg1: the spec is a bit annoying there, I agree. It refers to the public key portion as being part of the 'efi signature list'
<sjg1>
apalos: So perhaps fix the spec, or avoid bringing that confusion into U-Boot?
<apalos>
sjg1: or alternatively, ask what .esl is if you have doubts since we are literally implementing the spec
<apalos>
And people outside u-boot might actually read and contribute
apritzel has joined #u-boot
<sng>
sjg1: Sorry, I did not get your query on the mail on modifying u-boot.bin for capsule update
mmu_man has quit [Ping timeout: 246 seconds]
<sng>
with the embedding of the pub key through dtsi, nothing changes now. the u-boot.bin = u-boot-nodtb.bin + u-boot.dtb. same as earlier. just that the u-boot.dtb will have the pub key
<sjg1>
Sng ok so where is the capsule update file written to?
<sng>
sjg1: by "capsule update file", i'm guessing you mean the capsule file. that will be on the EFI System Partition. it is not part of u-boot.bin.
<apalos>
exactly
<apalos>
sjg1: the 'capsule' is an abstract meaning,
<sng>
the capsule update module in u-boot will pick the capsule file up from the EFI System Partition, process it, and proceed with the update. so the capsule file does not mess with the u-boot.bin
<apalos>
it's a container that contain some or all of the files you need yo update multiple firmware images
<apalos>
It's wrapped in a headers with guids etc so the update system will understand it
<sjg1>
Is that capsule update created by binman as part of the build?
<apalos>
and obviously, it's not the same as u-boot.bin. It's u-boot-efi.capsule or whatever suits the naming we shoose
<apalos>
yes binman can read a config file that has the info it needs (guids, priv keys etc) and call mkeficapsule to produce that file
<sng>
sjg1: In V3, the "capsule file" will be created as part of binman. yes.
<sjg1>
I don't actually care what esl is... Just another binary format that I wish didn't exist
<apalos>
sjg1: you realize that all this predated u-boot right ?:)
<apalos>
whether we like it or not, microsoft came up with that thing,
<sng>
once the "capsule file" has been created as part of the u-boot build, the user will have to put the capsule file on the ESP.
<apalos>
At some point in time distros said "hey that's better than the hellhole we used to have"
<sjg1>
sng what is the filename of the capsule update file?
<sjg1>
sng: I cannot find it in the patches?
<apalos>
and sjg1 the 'i dont care point' is what I really dont get. You are literally commenting on patches someone spent time to implement.
<sng>
sjg1: it can be any name that the user provides. it is not related to the u-boot.bin that we generate
<apalos>
Again if you need more time, ask, if you need more explanations ask It's definitely gonna take less time than trying to respond on random comments in emails
d-s-e has quit [Ping timeout: 240 seconds]
<sjg1>
sng I'm still confused, sorry, how is the capsule created by binman? Where is that happening? Or do I need to wait for the next version of the patches?
<apalos>
wait for the next version of the patches
<sng>
sjg1: yes, it'll be better to wait for the next version. but in simple terms, there will be an capsule.py entry module in binman, which will call a bintool called mkeficapsule
<sjg1>
sng: OK I see thank you
<sng>
and that bintool will call the actual tool which generates the capsule files
mmu_man has joined #u-boot
<sjg1>
apalos: I care about the patches. I am just saying that I don't care about the esl format..there are just too many binary formats in the world and I wish it were broken out into FDT properties
<sjg1>
sng: OK
<apalos>
sng: also generate a capsule if the authentication is *not* enabled.
<apalos>
It would be useful to have that feature if people want to play around, although we should pop a warning somehwere saying. YOU SHOULDNT REALLY BE USING THIS ON A PRODUCT
<sng>
apalos: yep. it won't be dependent on authentication. it will depend on the presence of a "capsule" node in the DT under the binman node.
<sng>
apalos: so, if the user puts a "capsule" entry node under binman, the build will generate the capsule files described in the config-file.
<sjg1>
apalos: So esl predates U-Boot, so I suppose it was created in the 90s. What still disappoints me is that ARM is inflicting this ancient spec and technology on modern embedded systems. There is an opportunity to create something free of the legacy cruft
<sjg1>
apalos: (that comment is aside from the patches, BTW, and I believe you are well aware of my views on EFI)
<sjg1>
sng: apalos OK I will await the next version
<apalos>
sjg1: I am not saying efi is good, there are spec areas where it's a mess
<apalos>
For example the shitshow I fixed on guid alignment in certian structs is a trainwreck
<apalos>
and even worst an uncorrectable trainwreck because of backwards compatibility
<apalos>
However it's way better than the 'i invented a new struct params for board X'
<apalos>
And distros can abstract the whole booting,
slobodan has joined #u-boot
slobodan_ has joined #u-boot
slobodan has quit [Read error: Connection reset by peer]
camus has quit [Remote host closed the connection]
camus has joined #u-boot
vfazio_ has joined #u-boot
mncheck-m has quit [Read error: Connection reset by peer]
slobodan_ has quit [Read error: Connection reset by peer]
marcan has quit [Server closed connection]
marcan has joined #u-boot
qschulz has quit [Ping timeout: 250 seconds]
qschulz has joined #u-boot
aat596 has joined #u-boot
crb_ has quit [Server closed connection]
aat596_3 has joined #u-boot
sng has joined #u-boot
rcn-ee has quit [Server closed connection]
rcn-ee has joined #u-boot
soxrok2212 has quit [Ping timeout: 250 seconds]
soxrok2212 has joined #u-boot
sng has quit [Remote host closed the connection]
sbach has quit [Ping timeout: 250 seconds]
sbach has joined #u-boot
d-s-e has quit [Ping timeout: 252 seconds]
hanetzer has quit [Ping timeout: 246 seconds]
hanetzer has joined #u-boot
<Forty-Bot>
mwalle: I don't think so... I've only ever used fastboot with FITs
<Forty-Bot>
maybe you can make a minimal FIT image?
ikarso has quit [Quit: Connection closed for inactivity]
d-s-e has joined #u-boot
mmu_man has quit [Ping timeout: 250 seconds]
julienp has joined #u-boot
julienp has quit [Client Quit]
mmu_man has joined #u-boot
d-s-e has quit [Ping timeout: 250 seconds]
vagrantc has joined #u-boot
eloy has quit [Read error: Connection reset by peer]
eloy has joined #u-boot
___nick___ has joined #u-boot
___nick___ has quit [Client Quit]
___nick___ has joined #u-boot
___nick___ has quit [Client Quit]
___nick___ has joined #u-boot
slobodan has joined #u-boot
mmu_man has quit [Ping timeout: 250 seconds]
slobodan has quit [Read error: Connection reset by peer]
slobodan_ has joined #u-boot
mmind00 has quit [Ping timeout: 250 seconds]
mmind00 has joined #u-boot
<milkylainen>
sjg1: Hmm? I had trouble verifying with fit_check_sign because it would choke on packed dtbs. There is no point in unpacking stuff for verification. Afaiu, the hash is calculated on the compressed blob.