<ccf>
Current master fails to compile when CONFIG_SPL_OPTEE_IMAGE=y, see here: https://pastebin.com/Z85dqBaz it's an Assembler message, any ideas? Board is rk3399.
apritzel_ has quit [Ping timeout: 268 seconds]
Michael23 has joined #u-boot
mckoan|away is now known as mckoan
vagrantc has quit [Quit: leaving]
zPlus has quit [Ping timeout: 248 seconds]
frieder has joined #u-boot
goliath has joined #u-boot
ikarso has quit [Quit: Connection closed for inactivity]
<indy>
hi all, is there any example of loading image using u-boot when pcie is in endpoint mode? i would like to load kernel from host passed to pcie 'device' as firmware (if it is possible with u-boot)
<indy>
i'm playing with rk3399 with pcie as endpoint
<ccf>
indy: I have no clue, but wow, that sounds so cool! I have seen some mails on linux-kernel-mailinglist regarding RK3399 PCIe endpoint controller driver. Are you involved there?
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
monstr has joined #u-boot
Michael23 has quit [Quit: Client closed]
<sjg1>
apalos: I will send a patch on top of your series showing what I mean
<sjg1>
apalos: One question is whether we should always do a self test. I thought that was just done at the factory?
<apalos>
we should always do a self test
torez has quit [Quit: torez]
<apalos>
sjg1: ^^. What the self test does is prepare the hardware for extra functionality
<apalos>
The details are in my commit message
<apalos>
because the tpm will return an error code saying "you need to do self tests is you want to run crypt alg X"
<apalos>
But we dont check for that error code
<apalos>
and tbh we shouldnt, the self tests are usually fast, so perform them unconditionally
<apalos>
and get over with it
<apalos>
Now with tpm 1.2 the init sequence is difference that what you have in that WIP patch
<apalos>
You just need toi perform the self-test
<apalos>
But my whole point is that *using* API functions for the auto start is gonna look ugly
<apalos>
We are way better of just defining an extra API function
torez has joined #u-boot
<apalos>
So I can send a PR to Tom, with my changes and the work together on that WIP you have
<sjg1>
The problem with self test is that it can take a while, several hundred milliseconds, sometimes longer. So we can't do this on every boot, unless we are using UEFI where it doesn't matter :-)
<sjg1>
How long does your TPMv2 take to do the self test?
GNUtoo_ has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
vagrantc has joined #u-boot
<apalos>
sjg1: I havent measured, but in definitely less than 1 sec
<apalos>
sjg1: the alternative is teach u-boot's core to run the selftests, if that erro code is returned
<apalos>
As far as boot times are concerned, stay tuned,
<apalos>
there's going to a presentation in Linaro connect about boot times on EFI
<sjg1>
apalos: So long as you are just wanting this for EFI I really don't mind how long it takes. We can add a full self test every time. But is tpm_auto_start() the right name in that case? Perhaps tpm_first_start() ?
<sjg1>
apalos: Bear in mind that 1000ms is the total time taken for ChromeOS firmware to get to kernel handoff. It is a long time.
<apalos>
sjg1: it only plugs in EFI for now
<apalos>
it's actually 'auto_startup', because that's the proper way to init a TPM
<apalos>
I also added the tests you asked for
<apalos>
And as I said, I am happy to help and improve testing + speed
<apalos>
What I dont like, is being asked to rewrite half of the API :>
<apalos>
I already did that for the drivers, and unfortunately I am drowing in other stuff
<apalos>
So If we can take one step at a time I am fine
prabhakarlad has quit [Ping timeout: 260 seconds]
<xypron>
sjg1: we should enable all tests on the sandbox. If you don't want them on your local machine, doable them locally.
goliath has quit [Quit: SIGSEGV]
<xypron>
disable
mmu_man has quit [Ping timeout: 255 seconds]
<sjg1>
apalos: If that is what you want auto_startup to be, it is fine with me. I will update my patch to add a full self test for TPMv1 too. But note that we probably cannot use this in general, due to the effect on boot time
mmu_man has joined #u-boot
<apalos>
you want me to send a PR to Tom with my patches?
<apalos>
If yes please have a look and tell me, I also had to change the sandbox tpm2 error code, to match the other drivers
<sjg1>
apalos: I want it supported in tpmv1 as well, so please hold off until we sort that out. If you OK with the changes I can turn them into patches (will add self test)
<sjg1>
apalos: As to changing half the API, I could about 35 functions at present. Your series adds a new one, but doesn't change anything else. My patch doesn't touch it. Are you talking about something else?
<apalos>
no I mean having add more code to sandbox etc, since 1.2 wasn't supported
<apalos>
the one new function in the API is actually needed as i said
<apalos>
Becuase if we go down the path you suggested on calling api functions for selftest etc, we will end up with spaghetti code
<apalos>
simply because 1.2 vs 2.o have a different init sequence
<apalos>
I'll respond to your email
<sjg1>
apalos: OK. I just don't know what to say. The API is the API. We can of course have things that cannot be supported. But we should not add functions that can easily be supported on both, but we don't want to...
<sjg1>
apalos: I think it is reasonable to add more tests to tpm.c as my patch does
<sjg1>
xypron: Yes, at present a lot of the tests are in the 'tpmtest' command. Many of them could usefully be brought over to test/dm/tpm.c without a lot of effort. Some of them would be harder
d-s-e has quit [Ping timeout: 248 seconds]
<apalos>
sjg1: yes it is
<apalos>
sjg1: we are saying different things on the API
<apalos>
On an older comment you told me to use the API existing functions instead of creating a new one
<apalos>
What I am trying to explain is that with the different return codes of tpm_self_test_full() doing so would look really ugly
<apalos>
because the *selftest* command returns completely differnt results
<apalos>
So you either abstract the rerutn codes in an internal u-boot API
<apalos>
Or you just keep those specific in the equivalent subsystem,
<sjg1>
apalos: We are just not communicating properly. I didn't want you to use existing API functions. I just wanted you to implement it for tpm v1 and v2. It is fine to add a new API function, of course
<sjg1>
apalos: By adding a new API which collates several things, you are creating the necessity for handling these different return codes. So long as it is documented, it seems fine to me
<sjg1>
apalos: You are wanting a way to start the TPM even if it has never been provisioned, a way to handle it no matter what state it is in. That seems fine to me. I am solely objecting to your saying that you don't have time to implement it for TPMv1
<sjg1>
apalos: That is why I sent my patch
<apalos>
sjg1: you literally replied
<apalos>
Again, tpm_self_test_full(). We are trying to provide a TPM API that
<apalos>
covers v1 and v2, to the extent possible.
monstr has quit [Remote host closed the connection]
<apalos>
So i assumed you want to re-use existing functions, which isnt really doable here :>
mmu_man has quit [Ping timeout: 252 seconds]
<apalos>
and it's not only time,
<sjg1>
apalos: Oh....I did change it to call tpm_init() at the API level, since both v1 and v2 call that. Beyond that, each one has to have its own impl
<apalos>
yea i never said anything about the init though
<apalos>
That does make sense,
<apalos>
Anyway< not gonna argue about that
<apalos>
My problem is that we are adding a tpm_auto_start which isnt equivalent with 1.2 vs 2
<apalos>
and what I said is that my main problem is that i dont have a *device* to test that
<apalos>
So I didnt want to add that code,
d-s-e has joined #u-boot
guillaume_g has quit [Quit: Konversation terminated!]
<apalos>
sjg1: I can pick it up and resend it with my series btw
<apalos>
Or just send it and i'll prepare a PR with both