[U-Boot] Patches for this merge window
[take 2, sorry]
Hi Tom,
I see quite a lot of non-x86 patches in my todo list - does that mean that I should pick them up if I am happy with them, or just assign them back to you once I've taken a look?
I'm keen to get the sandbox fs and memory stuff in fairly early if possible, since I fear breakages and the longer people have to test the better. No one has screamed about map_sysmem() but I'm not sure if anyone noticed. So I could pull these in, build and send a pull if that suits? Perhaps one series at a time.... Also if Mike is having a break should I pull in the SPI ones assigned to me?
There is also buildman, and I'm not sure what to do about that. It would be nice to have some feedback if people have tried it - I have had a few private emails only. I think it's a great help, but it still has some rough edges.
Anyway, please let me know your expectations with the above. Re x86, I am going to start applying things this week once the board removable patch is sorted out.
Generic board is also a big change, but since it is sort-of parallel to existing code and only turned on on a board-by-board basis the risk is lower - it just need some weeks of review time IMO.
Regards, Simon
[take 2 for me, gmail defaults to reply not reply-all]
On Sun, Feb 10, 2013 at 11:48 PM, Simon Glass sjg@google.com wrote:
Hi Tom,
I see quite a lot of non-x86 patches in my todo list - does that mean that I should pick them up if I am happy with them, or just assign them back to you once I've taken a look?
For stuff you've posted, yes, you can either toss it back to me, toss it into a branch in u-boot-x86.git or toss it into a patchwork bundle and hand 'em back to me.
I'm keen to get the sandbox fs and memory stuff in fairly early if possible, since I fear breakages and the longer people have to test the better. No one has screamed about map_sysmem() but I'm not sure if anyone noticed. So I could pull these in, build and send a pull if that suits? Perhaps one series at a time.... Also if Mike is having a break should I pull in the SPI ones assigned to me?
In general I've tried to skim patches at least, and will give things one more read over when it comes back at me to pull in (however that is). For trivial SPI stuff (more IDs, etc) yes. For the changes to writing and output and so forth, keep those in a separate request if nothing else.
There is also buildman, and I'm not sure what to do about that. It would be nice to have some feedback if people have tried it - I have had a few private emails only. I think it's a great help, but it still has some rough edges.
I still need to try that myself, sorry. Has anything changed from the last series you posted?
Anyway, please let me know your expectations with the above. Re x86, I am going to start applying things this week once the board removable patch is sorted out.
Generic board is also a big change, but since it is sort-of parallel to existing code and only turned on on a board-by-board basis the risk is lower - it just need some weeks of review time IMO.
Sounds good, thanks!
-- Tom
Hi Tom,
On Mon, Feb 11, 2013 at 12:47 PM, Tom Rini trini@ti.com wrote:
[take 2 for me, gmail defaults to reply not reply-all]
On Sun, Feb 10, 2013 at 11:48 PM, Simon Glass sjg@google.com wrote:
Hi Tom,
I see quite a lot of non-x86 patches in my todo list - does that mean that I should pick them up if I am happy with them, or just assign them back to you once I've taken a look?
For stuff you've posted, yes, you can either toss it back to me, toss it into a branch in u-boot-x86.git or toss it into a patchwork bundle and hand 'em back to me.
OK will do.
I'm keen to get the sandbox fs and memory stuff in fairly early if possible, since I fear breakages and the longer people have to test the better. No one has screamed about map_sysmem() but I'm not sure if anyone noticed. So I could pull these in, build and send a pull if that suits? Perhaps one series at a time.... Also if Mike is having a break should I pull in the SPI ones assigned to me?
In general I've tried to skim patches at least, and will give things one more read over when it comes back at me to pull in (however that is). For trivial SPI stuff (more IDs, etc) yes. For the changes to writing and output and so forth, keep those in a separate request if nothing else.
OK, will try that.
There is also buildman, and I'm not sure what to do about that. It would be nice to have some feedback if people have tried it - I have had a few private emails only. I think it's a great help, but it still has some rough edges.
I still need to try that myself, sorry. Has anything changed from the last series you posted?
Not really, it is in the same stage.
Anyway, please let me know your expectations with the above. Re x86, I am going to start applying things this week once the board removable patch is sorted out.
Generic board is also a big change, but since it is sort-of parallel to existing code and only turned on on a board-by-board basis the risk is lower - it just need some weeks of review time IMO.
Sounds good, thanks!
-- Tom
Regards, Simon
Hi Tom,
[sorry I wrote this yesterday and didn't send]
On Mon, Feb 11, 2013 at 12:47 PM, Tom Rini trini@ti.com wrote:
[take 2 for me, gmail defaults to reply not reply-all]
On Sun, Feb 10, 2013 at 11:48 PM, Simon Glass sjg@google.com wrote:
Hi Tom,
I see quite a lot of non-x86 patches in my todo list - does that mean that I should pick them up if I am happy with them, or just assign them back to you once I've taken a look?
For stuff you've posted, yes, you can either toss it back to me, toss it into a branch in u-boot-x86.git or toss it into a patchwork bundle and hand 'em back to me.
I'm keen to get the sandbox fs and memory stuff in fairly early if possible, since I fear breakages and the longer people have to test the better. No one has screamed about map_sysmem() but I'm not sure if anyone noticed. So I could pull these in, build and send a pull if that suits? Perhaps one series at a time.... Also if Mike is having a break should I pull in the SPI ones assigned to me?
Well sandbox fs and memory stuff are in thank you. So far I haven't heard of any breakages, but it is early days.
In general I've tried to skim patches at least, and will give things one more read over when it comes back at me to pull in (however that is). For trivial SPI stuff (more IDs, etc) yes. For the changes to writing and output and so forth, keep those in a separate request if nothing else.
I will bring in the SPI stuff into a separate branch in the x86 and send you a pull. I will have to rebase and run a full build first though.
There is also buildman, and I'm not sure what to do about that. It would be nice to have some feedback if people have tried it - I have had a few private emails only. I think it's a great help, but it still has some rough edges.
I still need to try that myself, sorry. Has anything changed from the last series you posted?
I have a few tweaks so I could send an updated patch.
[..]
Generic board is also a big change, but since it is sort-of parallel to existing code and only turned on on a board-by-board basis the risk is lower - it just need some weeks of review time IMO.
Sounds good, thanks!
And generic board is in also now, which is a big step. Thanks for all your effort on that.
I am about to rev the verified boot series, and FIT image series base on feedback.
Also, what is happening on the TPM side? I think we have all the pieces for making the TPM work properly in U-Boot, as previously discussed. Along with verified boot we have a pretty solid implementation now.
Regards, Simon
-- Tom
On Wed, Mar 20, 2013 at 12:53:06PM -0700, Simon Glass wrote:
Hi Tom,
[sorry I wrote this yesterday and didn't send]
On Mon, Feb 11, 2013 at 12:47 PM, Tom Rini trini@ti.com wrote:
[take 2 for me, gmail defaults to reply not reply-all]
On Sun, Feb 10, 2013 at 11:48 PM, Simon Glass sjg@google.com wrote:
[..]
Generic board is also a big change, but since it is sort-of parallel to existing code and only turned on on a board-by-board basis the risk is lower - it just need some weeks of review time IMO.
Sounds good, thanks!
And generic board is in also now, which is a big step. Thanks for all your effort on that.
I am about to rev the verified boot series, and FIT image series base on feedback.
Also, what is happening on the TPM side? I think we have all the pieces for making the TPM work properly in U-Boot, as previously discussed. Along with verified boot we have a pretty solid implementation now.
So, I really want Wolfgang to weigh in on the verified boot side of things (and I need to review it harder and think myself). On a related note, have you seen http://prosauce.org/blog/2013/2/11/embedded-trust-p2-u-boot-secured-boot.htm... yet? It almost looks like easy enough that I could get that wired up here but is also another real life case we should take into account and make easy enough to handle and support in mainline.
Hi Tom,
On Wed, Mar 20, 2013 at 1:07 PM, Tom Rini trini@ti.com wrote:
On Wed, Mar 20, 2013 at 12:53:06PM -0700, Simon Glass wrote:
Hi Tom,
[sorry I wrote this yesterday and didn't send]
On Mon, Feb 11, 2013 at 12:47 PM, Tom Rini trini@ti.com wrote:
[take 2 for me, gmail defaults to reply not reply-all]
On Sun, Feb 10, 2013 at 11:48 PM, Simon Glass sjg@google.com wrote:
[..]
Generic board is also a big change, but since it is sort-of parallel to existing code and only turned on on a board-by-board basis the risk is lower - it just need some weeks of review time IMO.
Sounds good, thanks!
And generic board is in also now, which is a big step. Thanks for all your effort on that.
I am about to rev the verified boot series, and FIT image series base on feedback.
Also, what is happening on the TPM side? I think we have all the pieces for making the TPM work properly in U-Boot, as previously discussed. Along with verified boot we have a pretty solid implementation now.
So, I really want Wolfgang to weigh in on the verified boot side of things (and I need to review it harder and think myself). On a related note, have you seen
http://prosauce.org/blog/2013/2/11/embedded-trust-p2-u-boot-secured-boot.htm... yet? It almost looks like easy enough that I could get that wired up here but is also another real life case we should take into account and make easy enough to handle and support in mainline.
Yes it would be good to get Wolfgang's feedback. I will also update the follow-on 'image' series.
I had a good look through this, after doing a rough rebase to master.
The main parts are:
- RSA - A move comprehensive TPM library - Plumbing to call tpm_extend when there is user data loaded (environment, kernel, ramdisk, command line...)
It brings in some additional code from the Chromium tree, which we have been upstreaming.
The first two (RSA and TPM library) are mostly covered by my vboot series and Che-Liang's TPM work. I suggest that the TPM additions in sboot could be done by adding the missing features on top of Che-Liang's work. For the third part (the plumbing), this could become a CONFIG option I think.
The two verified boot implementations use similar infrastructure, but are somewhat different. My one works around FIT images, assuming a read-only root of trust, and is intended to use the TPM for rollback protection only so far. Images within the FIT are verified with a public key, and image verification can be chained.
The sboot implementation also requires some trusted read-only code, but then uses tpm_extend on each new chunk of user data/code loaded. It requires the chain of tpm_extends to be played back and stored in the TPM, then the TPM is locked and future boots must replay with the same code. So it is not quite as easy to upgrade images (e.g. move to a new kernel) although I'm sure this problem could be solved using a suitable mechanism.
It would be possible to support much of the functionality of the sboot implementation within FIT, and certainly the fact that both need similar infrastructure means that I think the FIT-based verified boot is a good basis for upstreaming the sboot implementation when this is ready.
If you are interested I pushed my rebased branch to the x86 tree (branch is try-sboot) - this is missing some code since I didn't do a proper rebase, but if is much easier to diff against master.
Regards, Simon
On Sun, Feb 10, 2013 at 09:09:29PM -0800, Simon Glass wrote:
[take 2, sorry]
Hi Tom,
I see quite a lot of non-x86 patches in my todo list - does that mean that I should pick them up if I am happy with them, or just assign them back to you once I've taken a look?
I'm keen to get the sandbox fs and memory stuff in fairly early if possible, since I fear breakages and the longer people have to test the better. No one has screamed about map_sysmem() but I'm not sure if anyone noticed. So I could pull these in, build and send a pull if that suits? Perhaps one series at a time.... Also if Mike is having a break should I pull in the SPI ones assigned to me?
There is also buildman, and I'm not sure what to do about that. It would be nice to have some feedback if people have tried it - I have had a few private emails only. I think it's a great help, but it still has some rough edges.
Looking back at this, I think only buildman is left. Did all of the other patman related changes get submitted cleanly? I think the answer is we'll take in buildman now so it's easier to get folks to try it in their workflows and see where it takes us.
Hi Tom,
On Wed, Mar 20, 2013 at 12:28 PM, Tom Rini trini@ti.com wrote:
On Sun, Feb 10, 2013 at 09:09:29PM -0800, Simon Glass wrote:
[take 2, sorry]
Hi Tom,
I see quite a lot of non-x86 patches in my todo list - does that mean that I should pick them up if I am happy with them, or just assign them back to you once I've taken a look?
I'm keen to get the sandbox fs and memory stuff in fairly early if possible, since I fear breakages and the longer people have to test the better. No one has screamed about map_sysmem() but I'm not sure if anyone noticed. So I could pull these in, build and send a pull if that suits? Perhaps one series at a time.... Also if Mike is having a break should I pull in the SPI ones assigned to me?
There is also buildman, and I'm not sure what to do about that. It would be nice to have some feedback if people have tried it - I have had a few private emails only. I think it's a great help, but it still has some rough edges.
Looking back at this, I think only buildman is left. Did all of the other patman related changes get submitted cleanly? I think the answer is we'll take in buildman now so it's easier to get folks to try it in their workflows and see where it takes us.
Yes that's right. I can set up a bundle, along with the patman additions, but actually I have found some problems with patman in the latest mainline - checkpatch has changed. There are quite a few things collected now that need fixing - e.g. Doug's fix to stop removing Reviewed-by: tags.
I will start by getting some patches out and we can take a look. Until then is it OK to hold off on buildman?
Regards, Simon
-- Tom
On Wed, Mar 20, 2013 at 07:27:24PM -0700, Simon Glass wrote:
Hi Tom,
On Wed, Mar 20, 2013 at 12:28 PM, Tom Rini trini@ti.com wrote:
On Sun, Feb 10, 2013 at 09:09:29PM -0800, Simon Glass wrote:
[take 2, sorry]
Hi Tom,
I see quite a lot of non-x86 patches in my todo list - does that mean that I should pick them up if I am happy with them, or just assign them back to you once I've taken a look?
I'm keen to get the sandbox fs and memory stuff in fairly early if possible, since I fear breakages and the longer people have to test the better. No one has screamed about map_sysmem() but I'm not sure if anyone noticed. So I could pull these in, build and send a pull if that suits? Perhaps one series at a time.... Also if Mike is having a break should I pull in the SPI ones assigned to me?
There is also buildman, and I'm not sure what to do about that. It would be nice to have some feedback if people have tried it - I have had a few private emails only. I think it's a great help, but it still has some rough edges.
Looking back at this, I think only buildman is left. Did all of the other patman related changes get submitted cleanly? I think the answer is we'll take in buildman now so it's easier to get folks to try it in their workflows and see where it takes us.
Yes that's right. I can set up a bundle, along with the patman additions, but actually I have found some problems with patman in the latest mainline - checkpatch has changed. There are quite a few things collected now that need fixing - e.g. Doug's fix to stop removing Reviewed-by: tags.
I will start by getting some patches out and we can take a look. Until then is it OK to hold off on buildman?
Sounds good to me, thanks!
participants (2)
-
Simon Glass -
Tom Rini