ikarso has quit [Quit: Connection closed for inactivity]
mmu_man has quit [Ping timeout: 246 seconds]
macromorgan has joined #u-boot
ikarso has joined #u-boot
sakman has quit [Remote host closed the connection]
sakman has joined #u-boot
d-s-e has quit [Quit: Konversation terminated!]
sszy has quit [Ping timeout: 260 seconds]
frieder has quit [Remote host closed the connection]
mmu_man has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
mmu_man has quit [Ping timeout: 245 seconds]
mmu_man has joined #u-boot
<sng>
sjg1 Tartarus i am looking into the review comment from Tom about using a single dtsi file for the capsule signature node, instead of putting that node in a u-boot.dtsi for every arch
<sng>
sjg1 you had instead suggested putting the signature node under a u-boot.dtsi. however, there are a coupld of issues here. 1) Tom wants a single file for the sig node instead of one per arch. 2) the u-boot.dtsi file gets included *onlu if* there is no other *-u-boot.dtsi file present
<sng>
sjg1 i think the second point is important, as that would mean that the automatic inclusion of u-boot.dtsi depends on the absence of certain files. if say we have a $(CONFIG_SYS_SOC)-u-boot.dtsi file present. the u-boot.dtsi will not be included
<sng>
sgj1 Tartarus I think the best solution in this case is to use the solution in V1, which i have pointed above.
<sng>
sjg1 thoughts?
hanetzer has joined #u-boot
<Tartarus>
sng: OK, so, I guess part of the problem with what I've suggested is that cmd_dtc would also need to be adjusted to have some logic similar to how it handles u_boot_dtsi in order to also #include a signature dtsi fragment and then be ran through cpp
<Tartarus>
" (cat $<; $(if $(u_boot_dtsi),echo '$(pound)include "$(u_boot_dtsi)"')) > $(pre-tmp); \" would need a tiny tweak to then also if $(u_boot_efi_capsule_sig)...
<Tartarus>
I know Simon objects to new bash scripts
<sng>
Tartarus yeah, the DTC_FLAGS approach that we had discussed does not work, because the -include directive does not work as dtc does not recognise that
<Tartarus>
Yeah, I thought we -included the dtsi file, not re-worked it to be #included, sorry
<Tartarus>
I was speaking a bit more high level than I should have
<sng>
Tartarus what I was instead able to do was to do someting like this
<Tartarus>
The v1 approach is close, yes
<Tartarus>
But no new script files
<Tartarus>
We can do the same kind of "do we find.." or not find, like we do for -u-boot.dtsi, set a series of u_boot_capsule_sig variables to mirror the u_boot_dtsi ones
<Tartarus>
Yeah, we need to play the games that cmd_dtc does to #include it instead
<Tartarus>
So it'll be passed to cpp
<sng>
and then tweak the logic in cmd_dtc a bit to do a s/$(DEVICE_TREE_INCLUDES)/$(device_tree_includes)
<Tartarus>
Oh, hah
<Tartarus>
yes, or that
<Tartarus>
We should clean up u_boot_dtsi to just be the first of those
<Tartarus>
rather than a special case
hanetzer has joined #u-boot
<sng>
Tartarus hmm, okay. but this too does not work fully. since on sandbox, we have two directories of dts files that are getting built 1) arch/sandbox/dts/ and 2) test/overlay/
<sng>
and the issue is that with the /incbin/ directive that is used in dtc, it expects a path relative to the directory of the corresponding dts file. so the relative path solution does not work :(
<Tartarus>
Hmm
<Tartarus>
SO we're incbin'ing something that lives in object tree, or source tree?
<Tartarus>
Since we're basically making a static temp dtsi fragment, right?
<Tartarus>
We could just drop it in the base
<sng>
Tartarus which is why i started thinking that the solution in V1 is the best. because the signature node is in one overlay file. and we can then define the path to the esl file wrt that overlay file, and then apply the overlay to the dtb
<Tartarus>
Do we know where EFI_CAPSULE_ESL_FILE will be or can it be /read/only/secure/media/file or similar?
<sng>
we're incbin'ing something that lives in the src tree. but unfortunately, the /incbin/ directive of dtc is different from the .incbin used in assembly. in that the .incbin works with the -I paths. /incbin/ does nt
<Tartarus>
Or will it always be something in the source tree, static, or always in the obj dir
<Tartarus>
OK, so just generate in the Makefile $(objdir)/capsule.dtsi and incbin it
<Tartarus>
And make sure capsule.dtsi is cleaned
<Tartarus>
(and give it a bit better of a name ;))
<sng>
actually, the location of the ESL file is upon the user really. the user can configure it to be anywhere on the system. but for upstream code, it will be in the srctree.
<Tartarus>
... because of the tests?
<Tartarus>
What's the best practice for real ESL files
<sng>
it's really a public key certificate, converted into a data-structure defined in the UEFI spec. so the file can be anywhere on the system. and the user can really configure the config symbo l during build.
<Tartarus>
Sure, but pretend I'm a semi vendor, where do you suggest I store such a thing? Like, TomSemiconductor Inc is going to have a master ESL file for all my boards? Or would I probably end up with a new one for each SBC I make up?
<sng>
but yes, for the paths in upstream, both you and Simon asked not to use absolute paths. i was setting these files up in the /tmp/capsules/ directory, but was asked to put the files in the srctree instead.
<Tartarus>
Is there anything sensitive here, or is the ESL file just the public side of a key?
<sng>
yep, the ESL is just that. the public key crt in a UEFI format
Eschik has quit [Read error: Connection reset by peer]
<Tartarus>
If it's the public side of a key, it should be in-tree, and board/tomsemi/common/capsule-esl-file.esl
<Tartarus>
We need the upstream solution to be something the vendors will use, not ignore
<Tartarus>
public key, no reason to not check that in to the sources
<Tartarus>
private key would be another matter :)
<sng>
yep. that is not an issue. the problem is that for sandbox, the dts files reside in different locations, and at a different tree depth wrt the $(srctree).
<sng>
so when i do this - CONFIG_EFI_CAPSULE_ESL_FILE="../../../board/sandbox/capsule_pub_esl_good.esl". this works for the dts files under arch/sandbox/dts/, but not under test/overlay/
<Tartarus>
Well, what makes sandbox so odd again?
<Tartarus>
hm
<sng>
the fact that the dts files being built for sandbox reside in two different dir's
<sng>
and different tree depths
<Tartarus>
Well, everyone that does the overlay tests, which aren't sandbox specific would have this problem
<sng>
so, this will not be an issue for other platforms. because they will not have this scenario(hopfilly) of having dts files in different locations.
<Tartarus>
So we probably need to go and change the overlay tests to not break this case
<sng>
ok okay. so this might be an issue on other platforms as well
<Tartarus>
Yes
<sng>
basically, the overlay dts files should not have the capsule.dtsi get included
<Tartarus>
Yes
<sng>
which is why i thought that the ideal solution is to build the capsule.dtbo and then apply it to the dtb's.
<Tartarus>
perhaps it's an oddity of how we call dtc?
<Tartarus>
Hmm
<sng>
then we don't have this issue of multiple locations of dts files
<Tartarus>
Hmmm
<Tartarus>
Sec, digging
<sng>
i think the incbin directive in dtc has this major drawback of not being able to use the include paths for the location of the bin files
<sng>
had it worked like the .incbin, it would not be an issue
<Tartarus>
So, yes, I see part of the issue
<Tartarus>
cmd_dtc is of course how we invoke dtc every timme
<Tartarus>
But it also has logic that only makes sense for things like imx6dl-cubox-i.dts -> dtb
<Tartarus>
And not test-overlay*dtb
<Tartarus>
Hence you get in trouble with adding capsule to the overlay tests
<sng>
okay. i see. should the generation of overlay-test dtb files be split then?
<Tartarus>
I'm not sure yet
<sng>
okay
<Tartarus>
I guess since we have dtb.S rules, that gets invoked to generate dtb.o
<Tartarus>
I'm not sure
<sng>
okay. then can we make an exception for the script rule in this case? i mean the script in the first version?
<Tartarus>
An idea I have is this...
<Tartarus>
1) Update things such that u_boot_dtsi is just another part of CONFIG_DEVICE_TREE_INCLUDES
<Tartarus>
See if in test/overlay/Makefile we can blank CONFIG_DEVICE_TREE_INCLUDES for each of the test objects
<Tartarus>
Er, 2, that ^^
<sng>
okay. although that might be a little tricky, since the variables set in one Makefile are not visible to the other. it might require exporting the variable
<Tartarus>
Yes, we might need to make CONFIG_DEVICE_TREE_INCLUDES slightly more of a proper Make variable
<Tartarus>
And then set that new variable based on CONFIG_DEVICE_TREE_INCLUDES itself
<Tartarus>
Which funny enough is how some platform inserts a public key in a dts fragment to the tree :)
<Tartarus>
So I guess part of my right now question is why is CONFIG_EFI_CAPSULE_ESL_FILE a thing at all, and not just using CONFIG_DEVICE_TREE_INCLUDES
<sng>
yes i see that CONFIG_DEVICE_TREE_INCLUDES is being used by some iot platform for the pub key
<sng>
umm, that is because EFI authentication code expects the public key in the form af an ESL format. the logic used for authenticating secure variables is also used for authenticating capsules.
<sng>
but irrespective of whether we use CONFIG_EFI_CAPSULE_ESL_FILE or CONFIG_DEVICE_TREE_INCLUDES, this will an issue for the test overlay dtb's, isn't it? i mean currently, there is no user of DEVICE_TREE_INCLUDES in upstream code, which is why this isn't showing up
<sng>
ah no. this can be sorted using the include paths. this is a problem only because of /incbin/
<sjg1>
sng: Tartarus I like having a .dtsi in the board directory. For sandbox, we can just incbin a fixed file, we don't need the CONFIG. I don't like the CONFIG at all, really, but I can put up with it I suppose
<sjg1>
sng: I would really like to see a new rev of the series with just the binman stuff, since all the questions at present are about integration with tthe build which is not relevant there
<Tartarus>
I imagine the siemens board turns off the unit tests, yes, for secure boot
<Tartarus>
or secure devices rather, to try and not confuse things
<sjg1>
sng: On top of the dump_capsule command you are planning to write, I think we should look at how to describe the esl into a DT format so it is easier to understand
<sng>
sjg1 the esl format is really what is defined in the UEFI specification. so i dont know what can i change here
<Tartarus>
sng: I mean, CONFIG_DEVICE_TREE_INCLUDES and then that in turn points to the dtsi file that has the esl file in it.
<sng>
Tartarus hmm, with that, every board will have to have it's own dtsi file under the board/$BOARDDIR/?
<Tartarus>
Anyone using capsule updates, yes, and anyone using capsule updates will have to have their own ESL file in tree too anyhow
<Tartarus>
Since it's a public key, it should be in source control
<Tartarus>
and so putting it beside that dtsi file even sounds like a good practice, yes? Not a bad practice?
<sjg1>
sng: Where is the format of the .esl actually depended on?
<sng>
Tartarus yes. only thing is that i was attempting to do this automatically as part of the build
<Tartarus>
this==?
<sng>
sjg1 the format is defined in the UEFI specification.
<sng>
Tartarus i meant the embedding of the ESL data into the dtb. i wanted to do this automatically, with the user only pointing to the ESL path
<sjg1>
sng: Let's save this discussion for after the .dtsi one, since it is going to confuse things
<Tartarus>
sng: OK, so board/sandbox/capsule-esl.dtsi and that should be able to /incbin/("master-sig-file.esl") thats also in board/sandbox/
<Tartarus>
should should also work as board/tomsemi/common/capsule-esl.dtsi and master-sig-file.esl
<Tartarus>
yes?
<sng>
Tartarus yep. so you suggest creating this dtsi file for the boards which want to enable capsule authentication, is that right?
<Tartarus>
Yes, and it should be easy enough for other users to follow and re-use
<sng>
or can that be done through some logic in Makefile
<Tartarus>
I think I get it well enough now that no, we can't have a single capsule-esl.dtbi file for everyone
<Tartarus>
But arch/ is the wrong place
ikarso has quit [Quit: Connection closed for inactivity]
<Tartarus>
sjg1: Did you mean where is the ESL file format defined, or where do we need this data to be in ESL format rather than something else?
<sng>
Tartarus okay
<sjg1>
Tartarus: I mean that I don't like binary formats, in general, so I would like to figure out if we can use devicetree for the same information, eventually
<Tartarus>
sjg1: We can't, we're using a UEFI feature here not a home-grown feature
<Tartarus>
Is I think the answer
<sjg1>
OK, well I'll worry about it later
<sjg1>
So perhaps have a .dtsi in each board directory which is automatically included? Is that the result of the long thread above?
<sng>
Tartarus sjg1 yes. this is something defined by the UEFI spec to use for authentication. be it variable auth, or capsule auth
<Tartarus>
Hypothetically ASUS would be using the same keys at some level on their x8664 boards and their rockchip based tinker boards and so forth, think
<Tartarus>
And not in a transform this file to some other file manner
<sng>
sjg1 so basically we need to have a capsule*.dtsi file in the board dir. and then include that in the dtb. can be done through CONFIG_DEVICE_TREE_INCLUDES
<sjg1>
sng: We do the same thing with board.env (text environment)
<sng>
sjg1 Tartarus will make this change in the next version then
<sjg1>
Tartarus: sng: Hmm do we have to use DEVICE_TREE_INCLUDES? I would rather it were automatic
<sng>
sjg1 with the current logic in cmd_dtc, yes it would have to be through DEVICE_TREE_INCLUDES
<Tartarus>
sjg1: Yes, we talked through adding yet another automatic inclusion thing and that would just make the implementation look uglier
<Tartarus>
I'm kinda hoping I talked sng in to cleaning up u_boot_dtsi logic under the hood at least to just be the first file set in CONFIG_DEVICE_TREE_INCLUDES if it exists
<sng>
sjg1 btw, of all the *u-boot.dtsi files we have, only the first found gets included automatically
<sjg1>
sng: Yes that's right...so...?
<sjg1>
Tartarus: Hmmm OK I'll look at the patches, I suppose. It doesn't sound as automatic as the text environment, which is what I was hoping for
<Tartarus>
sjg1: It's not great because it leads to a number of #include of other -u-boot.dtsi files :)
<sng>
Tartarus sjg1 so should we change that to create a list of all existing files, u_boot_dtsi + CONFIG_DEVICE_TREE_INCLUDES, and then include them all. Tartarus is that what you are looking at?
<Tartarus>
sng: I was thinking cmd_dtc would be cleaner if it didn't have u_boot_dtsi and then CONFIG_DEVICE_TREE_INCLUDES, yes
<sng>
sjg1 so this notion of automatic inclusion of *u-boot.dtsi files is only partly correct. in that, if we have a $(CONFIG_SYS_SOC)-u-boot.dtsi, and a u-boot.dtsi, the u-boot.dtsi will not get included
<Tartarus>
sjg1: I don't want to expand what cmd_dtc looks like so that we have two automagic includes, it's already kinda ugly/complex
<Tartarus>
Check everything around u_boot_dtsi* in scripts/Makefile.lib and tell me you really want that duplicated for u_boot_capsule_esl_dtsi
<sjg1>
sng: It is correct as it is...otherwise boards cannot control what is included. You can always add a #include for the soc in the board file.
<sng>
sjg1 yes, i was referring to automatic inclusion of dtsi file with the current logic, when there are more than one such files
<sjg1>
Tartarus: OK I just looked at DEVICE_TREE_INCLUDES and that makes sense, thanks
<sjg1>
sng: Sure, but it is that way by design
<sng>
Tartarus okay, so iiuc, you want u_boot_dtsi files to be prepended to the CONFIG_DEVICE_TREE_INCLUDES. and then remove the first check in cmd_dtc?
<Tartarus>
sng: I think that would clean up cmd_dtc itself, yes?
<rfs613>
in linux drivers, the enabling of clocks is often handled by runtime PM, rather than by the driver explicitly calling eg. clock_prepare_enable(). When "porting" such a driver for u-boot, is there something equivalent? Or how should clocks be enabled?
<Tartarus>
And I don't mean literal CONFIG_DEVICE_TREE_INCLUDES, I suspect we'll need to make a proper make variable and roughly set it to u_boot_dtsi if it exists and then append $(CONFIG_DEVICE_TREE_INCLUDES)
<sng>
Tartarus i think that will result in a single line(for loop) for including all the files that need to be included
soxrok2212 has quit [Quit: Who ate my gummy worms?]
soxrok2212 has joined #u-boot
goliath has joined #u-boot
torez has quit [Remote host closed the connection]
prabhakarlad has joined #u-boot
<sjg1>
Tartarus: OK will await patches
<sjg1>
sng: Do you think you could send the binman part first so we can at least get that in?
hanetzer has quit [Ping timeout: 245 seconds]
hanetzer has joined #u-boot
<sng>
sjg1: yes, i have the binman changes ready for submission. will also send the esl embedding part since that is not that difficult to implement. should be able to send the next version tomorrow
sng_ has joined #u-boot
sng has quit [Read error: Connection reset by peer]
ezulian has quit [Ping timeout: 260 seconds]
sng_ has quit [Remote host closed the connection]
mmu_man has quit [Ping timeout: 246 seconds]
ex-parrot has joined #u-boot
<ex-parrot>
hi all. I'm trying to bring up mmc2 wired up to an SD card on the PE port on an A13 board at the moment. it's working in Linux but I can't seem to get it working in the latest u-boot
<ex-parrot>
the board is an "NTC CHIP"
<ex-parrot>
I've modified the device tree for the pin configuration and to enable mmc2, and I can see the pinmux being configured and the mmc2 device but it doesn't recognise the card, just gives me the "failed to respond to voltage select" error
<ex-parrot>
it seems like the pullups are maybe not being enabled on the pins
vagrantc has quit [Quit: leaving]
<marex>
ex-parrot: enable MMC_TRACE and see where it fails
<marex>
ex-parrot: reduce bus clock rate and width to some 1 MHz and 1 bit , see what happens
<ex-parrot>
just had a look on the scope, in u-boot I see the CLK pin floating around 2.12v and noisy, in Linux it's at 3.3v
<ex-parrot>
will enable those also
<marex>
ex-parrot: does the board have any sort of SD/MMC IO voltage selector ?
<marex>
like a regulator or GPIO or whatever ?
<ex-parrot>
ah good point, let me confirm that too
<ex-parrot>
ok I was missing vqmmc config in the device tree, the pin is not floating now :) u-boot still can't see the card but that's progress
<marex>
yep
<marex>
so is it now 2V9 or 3V3 ?
<ex-parrot>
3V3
<marex>
that is good
<ex-parrot>
yep :_
<ex-parrot>
:)
<ex-parrot>
ok I have MMC tracing enabled and buswidth set to 1. I set max-clock to 1 mhz but I'm not sure that is correct? I'm still getting cmd timeouts in any case
<ex-parrot>
I've also got DEBUG defined in sunxi_mmc.c so there's a bit of duplicated output
<marex>
ex-parrot: I mean, you can go as low as 400 kHz
<marex>
ex-parrot: that is the initial clock rate that the host controller uses to communicate even with the oldest of all cards
<ex-parrot>
it looks like maybe that is what u-boot is already doing?
<ex-parrot>
from the debug output
<marex>
ex-parrot: ancient stuff like 8 MiB SD 1.10 cards and stuff should still work with that too
<marex>
ex-parrot: but once the core figures out that the card is at least remotely capable of more, it ramps up the clock to 25 MHz
<marex>
ex-parrot: note that I am not familiar with allwinner stuff
<ex-parrot>
all good! neither really :P
<marex>
ex-parrot: check the datasheet , there is likely some "clock" block
<ex-parrot>
alright, I'll have a look at that later
<marex>
ex-parrot: clock controller, clock control, that
<ex-parrot>
thanks for the assistance
<marex>
ex-parrot: and then use 'md' commands to read those registers and see whether the right bit is set or not
<ex-parrot>
right-o
<marex>
ex-parrot: you can also check the Linux DT -> look up the SDMMC controller -> look up the IP referenced in 'clock' property -> that's the clock controller