Hi,

On 27 May 2015 at 21:41, pratapnaidu@gmail.com wrote:

Hi Simon, Thanks for of your time and quick replies. The idea seems to be good, but still confused with the way to implement it. Please help me to give a final thought to solve this with the existing framework, sorry for my inexperience with u-boot, kindly enlighten with the following:

1. How to sign the primary and secondary u-boot image with the same key,

after that do i need to write a routine similar to “bootm_find_os” or “bootm_find_loadables" to find the secondary uboot image and load it into the memory,

If the first U-Boot is in read-only flash then it cannot be updated, so does not need to be signed. If it is in read-write flash, then you probably can't prevent it being overwritten. You could protect half of the flash, perhaps, and put the read-only U-Boot in the proetced half.

Yes you can write a simple routine to load it.

2. can we have a dummy fit image with only secondary u-boot image within the

.its file for the first u-boot loader

I don't understand this sorry.

3)Sorry to ask you this, do you have any partial code i can follow and shred some light to carry on further.

I don't have anything that reads a read-write U-Boot and jumps to it, other than the Chrome OS code that i think you have.

I really thanks you to answer my all questions with patience,i would have not disturbed you, but because of project dead-line i was forced to be carried out with the situation.

OK. Please try to make the questions clear so that I can understand what you are asking.

Thanks, pratap

Regards, Simon

On May 23, 2015, at 2:12 PM, Simon Glass sjg@chromium.org wrote:

Hi,

On 23 May 2015 at 13:02, Maddimsetty Pratap pratapnaidu@gmail.com wrote:

Hi Simon, Thanks for you quick reply and sorry for the confusion over forum,here is my request for help

        1)  Do you know any repository which had already did it

"verify second u-boot signature" over beaglebone.

I'm not sure if this was done or not. You could look in cros/amxx here:

https://chromium.googlesource.com/chromiumos/third_party/u-boot/+/chromeos-v...

or a newer version that doesn't currently support beaglebone.

https://chromium.googlesource.com/chromiumos/third_party/u-boot/+/chromeos-v...

The Chrome OS implementation uses the same crypto but has custom binary data structures. I'm working a bit on trying to bridge the gap but we are not there yet.

So the easiest way to make this work is probably to use the FIT signature verification and put your second U-Boot into the FIT. That should handle the verification and then after it loads you can turn off the cache and jump to it. It already works on Beaglebone and the only difference is that it is currently set up to load a kernel, but you want to load U-Boot.

        2) Please verify and confirm the following link, if i was going

in the right direction.

http://git.chromium.org/gitweb/?p=chromiumos/third_party/u-boot.git;a=commit...

Thanks, pratap

Regards, Simon

Thanks, pratap

On Thu, May 21, 2015 at 6:32 PM, Simon Glass sjg@chromium.org wrote:

Hi,

It's here:

https://chromium.googlesource.com/chromiumos/third_party/u-boot

in branch chromeos-v2013.06. It is implemented for chromeos_peach.

If you have further questions, please send them to the U-Boot mailing list and cc me.

Regards, Simon

On 21 May 2015 at 17:25, Maddimsetty Pratap pratapnaidu@gmail.com wrote:

Hi Simon, I am apologize to e-mail you directly. In one of your presentations regarding FIT, you had stated uboot loading a signed secondary uboot loader in chromium. I would be glad if you provide me with any reference regarding the same.

Here is the statement from LWN.net.

"Chrome OS starts up U-Boot, loads and verifies a second U-Boot, loads and verifies a kernel and jumps to it all in under 700ms on a modern SoC"

Thanks, pratap

-- pratap naidu