[U-Boot] [PATCH v2] common: fit: Allow U-Boot images to be booted

[U-Boot] [PATCH v2] common: fit: Allow U-Boot images to be booted

[Mario Six]

In certain circumstances it comes in handy to be able to boot into a second
U-Boot. But as of now it is not possible to boot a U-Boot binary that is inside
a FIT image, which is problematic for projects that e.g. need to guarantee a
unbroken chain of trust from SOC all the way into the OS, since the FIT signing
mechanism cannot be used.

This patch adds the capability to load such FIT images.

An example .its snippet (utilizing signature verification) might look
like the following:

images {
	firmware at 1 {
		description = "2nd stage U-Boot image";
		data = /incbin/("u-boot-dtb.img.gz");
		type = "firmware";
		arch = "arm";
		os = "u-boot";
		compression = "gzip";
		load = <0x8FFFC0>;
		entry = <0x900000>;
		signature at 1 {
			algo = "sha256,rsa4096";
			key-name-hint = "key";
		};
	};
};

Signed-off-by: Mario Six <mario.six@gdsys.cc>
---

Changes in v2:
 - Use images of type 'firmware' for U-Boot images (as per Wolfgang Denk's
   hint), and make them bootable

---
 common/image-fit.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/common/image-fit.c b/common/image-fit.c
index 6f920da..73ad34e 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -1684,12 +1684,13 @@ int fit_image_load(bootm_headers_t *images, ulong addr,

 	bootstage_mark(bootstage_id + BOOTSTAGE_SUB_CHECK_ALL);
 	type_ok = fit_image_check_type(fit, noffset, image_type) ||
-		(image_type == IH_TYPE_KERNEL &&
-			fit_image_check_type(fit, noffset,
-					     IH_TYPE_KERNEL_NOLOAD));
+		  fit_image_check_type(fit, noffset, IH_TYPE_FIRMWARE) ||
+		  (image_type == IH_TYPE_KERNEL &&
+		   fit_image_check_type(fit, noffset, IH_TYPE_KERNEL_NOLOAD));

 	os_ok = image_type == IH_TYPE_FLATDT || IH_TYPE_FPGA ||
 		fit_image_check_os(fit, noffset, IH_OS_LINUX) ||
+		fit_image_check_os(fit, noffset, IH_OS_U_BOOT) ||
 		fit_image_check_os(fit, noffset, IH_OS_OPENRTOS);

 	/*
--
2.9.0

[U-Boot] [PATCH v2] common: fit: Allow U-Boot images to be booted

[Tom Rini]

On Wed, Jul 20, 2016 at 08:32:50AM +0200, Mario Six wrote:

> In certain circumstances it comes in handy to be able to boot into a second
> U-Boot. But as of now it is not possible to boot a U-Boot binary that is inside
> a FIT image, which is problematic for projects that e.g. need to guarantee a
> unbroken chain of trust from SOC all the way into the OS, since the FIT signing
> mechanism cannot be used.
> 
> This patch adds the capability to load such FIT images.
> 
> An example .its snippet (utilizing signature verification) might look
> like the following:
> 
> images {
> 	firmware at 1 {
> 		description = "2nd stage U-Boot image";
> 		data = /incbin/("u-boot-dtb.img.gz");
> 		type = "firmware";
> 		arch = "arm";
> 		os = "u-boot";
> 		compression = "gzip";
> 		load = <0x8FFFC0>;
> 		entry = <0x900000>;
> 		signature at 1 {
> 			algo = "sha256,rsa4096";
> 			key-name-hint = "key";
> 		};
> 	};
> };
> 
> Signed-off-by: Mario Six <mario.six@gdsys.cc>

Reviewed-by: Tom Rini <trini@konsulko.com>

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160720/b74b3384/attachment.sig>

[U-Boot] [PATCH v2] common: fit: Allow U-Boot images to be booted

[Robert P. J. Day]

On Wed, 20 Jul 2016, Mario Six wrote:

> In certain circumstances it comes in handy to be able to boot into a second
> U-Boot. But as of now it is not possible to boot a U-Boot binary that is inside
> a FIT image, which is problematic for projects that e.g. need to guarantee a
> unbroken chain of trust from SOC all the way into the OS, since the FIT signing
> mechanism cannot be used.
>
> This patch adds the capability to load such FIT images.
>
> An example .its snippet (utilizing signature verification) might look
> like the following:
>
> images {
> 	firmware at 1 {
> 		description = "2nd stage U-Boot image";
> 		data = /incbin/("u-boot-dtb.img.gz");
> 		type = "firmware";
> 		arch = "arm";
> 		os = "u-boot";
> 		compression = "gzip";
> 		load = <0x8FFFC0>;
> 		entry = <0x900000>;
> 		signature at 1 {
> 			algo = "sha256,rsa4096";
> 			key-name-hint = "key";
> 		};
> 	};
> };

  i'm sure i'm about to embarrass myself, but the above represents
loading a second version of u-boot into RAM, no? but i thought u-boot
didn't support being run out of RAM (except in special circumstances).
so what am i misunderstanding here?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

[U-Boot] [PATCH v2] common: fit: Allow U-Boot images to be booted

[Mario Six]

On Wed, Jul 20, 2016 at 2:59 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> On Wed, 20 Jul 2016, Mario Six wrote:
>
>> In certain circumstances it comes in handy to be able to boot into a second
>> U-Boot. But as of now it is not possible to boot a U-Boot binary that is inside
>> a FIT image, which is problematic for projects that e.g. need to guarantee a
>> unbroken chain of trust from SOC all the way into the OS, since the FIT signing
>> mechanism cannot be used.
>>
>> This patch adds the capability to load such FIT images.
>>
>> An example .its snippet (utilizing signature verification) might look
>> like the following:
>>
>> images {
>>       firmware at 1 {
>>               description = "2nd stage U-Boot image";
>>               data = /incbin/("u-boot-dtb.img.gz");
>>               type = "firmware";
>>               arch = "arm";
>>               os = "u-boot";
>>               compression = "gzip";
>>               load = <0x8FFFC0>;
>>               entry = <0x900000>;
>>               signature at 1 {
>>                       algo = "sha256,rsa4096";
>>                       key-name-hint = "key";
>>               };
>>       };
>> };
>
>   i'm sure i'm about to embarrass myself, but the above represents
> loading a second version of u-boot into RAM, no? but i thought u-boot
> didn't support being run out of RAM (except in special circumstances).
> so what am i misunderstanding here?
>
> rday
>

Well, if by "special circumstances" you mean "load the U-Boot image exactly
where CONFIG_SYS_TEXT_BASE expects it to be loaded," then these are special
circumstances; the U-Boot in the example snippet has CONFIG_SYS_TEXT_BASE of
0x900000, we load it to 0x8FFFC0 (offset for the 0x40 byte header), and the
bootm routine simply jumps to the entry point.

Accordingly, the second stage U-Boot you want to run must not have the save
CONFIG_SYS_TEXT_BASE as the U-Boot you want to run it out of (otherwise you
would overwrite the existing image in memory); something like

#ifdef CONFIG_SECONDUBOOT
#define    CONFIG_SYS_TEXT_BASE    0x00800000
#else
#define    CONFIG_SYS_TEXT_BASE    0x00900000
#endif

is needed if you want to build both with the same header file.

Hope that makes things a bit clearer.

Best regards,

Mario

[U-Boot] [PATCH v2] common: fit: Allow U-Boot images to be booted

[Robert P. J. Day]

On Wed, 20 Jul 2016, Mario Six wrote:

> On Wed, Jul 20, 2016 at 2:59 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> > On Wed, 20 Jul 2016, Mario Six wrote:
> >
> >> In certain circumstances it comes in handy to be able to boot
> >> into a second U-Boot. But as of now it is not possible to boot a
> >> U-Boot binary that is inside a FIT image, which is problematic
> >> for projects that e.g. need to guarantee a unbroken chain of
> >> trust from SOC all the way into the OS, since the FIT signing
> >> mechanism cannot be used.
> >>
> >> This patch adds the capability to load such FIT images.
> >>
> >> An example .its snippet (utilizing signature verification) might
> >> look like the following:
> >>
> >> images {
> >>       firmware at 1 {
> >>               description = "2nd stage U-Boot image";
> >>               data = /incbin/("u-boot-dtb.img.gz");
> >>               type = "firmware";
> >>               arch = "arm";
> >>               os = "u-boot";
> >>               compression = "gzip";
> >>               load = <0x8FFFC0>;
> >>               entry = <0x900000>;
> >>               signature at 1 {
> >>                       algo = "sha256,rsa4096";
> >>                       key-name-hint = "key";
> >>               };
> >>       };
> >> };
> >
> >   i'm sure i'm about to embarrass myself, but the above represents
> > loading a second version of u-boot into RAM, no? but i thought
> > u-boot didn't support being run out of RAM (except in special
> > circumstances). so what am i misunderstanding here?
>
> Well, if by "special circumstances" you mean "load the U-Boot image
> exactly where CONFIG_SYS_TEXT_BASE expects it to be loaded," then
> these are special circumstances; the U-Boot in the example snippet
> has CONFIG_SYS_TEXT_BASE of 0x900000, we load it to 0x8FFFC0 (offset
> for the 0x40 byte header), and the bootm routine simply jumps to the
> entry point.
>
> Accordingly, the second stage U-Boot you want to run must not have
> the save CONFIG_SYS_TEXT_BASE as the U-Boot you want to run it out
> of (otherwise you would overwrite the existing image in memory);
> something like
>
> #ifdef CONFIG_SECONDUBOOT
> #define    CONFIG_SYS_TEXT_BASE    0x00800000
> #else
> #define    CONFIG_SYS_TEXT_BASE    0x00900000
> #endif
>
> is needed if you want to build both with the same header file.
>
> Hope that makes things a bit clearer.

  not really, since i always thought that the difficulty in loading
and booting a second-stage u-boot was explained here:

http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM

that is, loading the second image to a different address is simple;
the apparent difficulty is that the second-stage u-boot might not be
able to handle the early setup already done by the first stage.

  so i'm still confused as to what is being proposed here, and how it
works.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

[U-Boot] [PATCH v2] common: fit: Allow U-Boot images to be booted

[Mario Six]

On Wed, Jul 20, 2016 at 3:56 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> On Wed, 20 Jul 2016, Mario Six wrote:
>
>> On Wed, Jul 20, 2016 at 2:59 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>> > On Wed, 20 Jul 2016, Mario Six wrote:
>> >
>> >> In certain circumstances it comes in handy to be able to boot
>> >> into a second U-Boot. But as of now it is not possible to boot a
>> >> U-Boot binary that is inside a FIT image, which is problematic
>> >> for projects that e.g. need to guarantee a unbroken chain of
>> >> trust from SOC all the way into the OS, since the FIT signing
>> >> mechanism cannot be used.
>> >>
>> >> This patch adds the capability to load such FIT images.
>> >>
>> >> An example .its snippet (utilizing signature verification) might
>> >> look like the following:
>> >>
>> >> images {
>> >>       firmware at 1 {
>> >>               description = "2nd stage U-Boot image";
>> >>               data = /incbin/("u-boot-dtb.img.gz");
>> >>               type = "firmware";
>> >>               arch = "arm";
>> >>               os = "u-boot";
>> >>               compression = "gzip";
>> >>               load = <0x8FFFC0>;
>> >>               entry = <0x900000>;
>> >>               signature at 1 {
>> >>                       algo = "sha256,rsa4096";
>> >>                       key-name-hint = "key";
>> >>               };
>> >>       };
>> >> };
>> >
>> >   i'm sure i'm about to embarrass myself, but the above represents
>> > loading a second version of u-boot into RAM, no? but i thought
>> > u-boot didn't support being run out of RAM (except in special
>> > circumstances). so what am i misunderstanding here?
>>
>> Well, if by "special circumstances" you mean "load the U-Boot image
>> exactly where CONFIG_SYS_TEXT_BASE expects it to be loaded," then
>> these are special circumstances; the U-Boot in the example snippet
>> has CONFIG_SYS_TEXT_BASE of 0x900000, we load it to 0x8FFFC0 (offset
>> for the 0x40 byte header), and the bootm routine simply jumps to the
>> entry point.
>>
>> Accordingly, the second stage U-Boot you want to run must not have
>> the save CONFIG_SYS_TEXT_BASE as the U-Boot you want to run it out
>> of (otherwise you would overwrite the existing image in memory);
>> something like
>>
>> #ifdef CONFIG_SECONDUBOOT
>> #define    CONFIG_SYS_TEXT_BASE    0x00800000
>> #else
>> #define    CONFIG_SYS_TEXT_BASE    0x00900000
>> #endif
>>
>> is needed if you want to build both with the same header file.
>>
>> Hope that makes things a bit clearer.
>
>   not really, since i always thought that the difficulty in loading
> and booting a second-stage u-boot was explained here:
>
> http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM
>
> that is, loading the second image to a different address is simple;
> the apparent difficulty is that the second-stage u-boot might not be
> able to handle the early setup already done by the first stage.
>
>   so i'm still confused as to what is being proposed here, and how it
> works.
>
> rday
>

Ah, alright. Look at the following quote from the page:

"On machines with boot-ROM and U-Boot-SPL, you might have better luck."

I'd venture that most SoCs these days have a boot-ROM; on these U-Boot, is not
as sensitive to not finding a "virgin" system (because the boot-ROM does some
initialization beforehand). The system I tested with is a Armada 38x, and we've
also use a similar approach on a MPC85xx system (if you would like to dig that
deep, the code is upstream: board/gdsys/p1022/controlcenterd*). The whole SPL
concept would be a problem if the boot loader needed a virgin CPU (since, well,
the SPL *is* a second U-Boot), so the restrictions mentioned in the page are
not as relevant for modern SoCs.

That's as far as my knowledge goes, if anyone wants to correct me, you're
welcome to do so :-)

Best regards,

Mario

[U-Boot] [PATCH v2] common: fit: Allow U-Boot images to be booted

[Robert P. J. Day]

On Wed, 20 Jul 2016, Mario Six wrote:

> On Wed, Jul 20, 2016 at 3:56 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:

... snip ...

> >   not really, since i always thought that the difficulty in loading
> > and booting a second-stage u-boot was explained here:
> >
> > http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM
> >
> > that is, loading the second image to a different address is simple;
> > the apparent difficulty is that the second-stage u-boot might not be
> > able to handle the early setup already done by the first stage.
> >
> >   so i'm still confused as to what is being proposed here, and how it
> > works.
> >
> > rday
> >
>
> Ah, alright. Look at the following quote from the page:
>
> "On machines with boot-ROM and U-Boot-SPL, you might have better luck."
>
> I'd venture that most SoCs these days have a boot-ROM; on these
> U-Boot, is not as sensitive to not finding a "virgin" system
> (because the boot-ROM does some initialization beforehand). The
> system I tested with is a Armada 38x, and we've also use a similar
> approach on a MPC85xx system (if you would like to dig that deep,
> the code is upstream: board/gdsys/p1022/controlcenterd*). The whole
> SPL concept would be a problem if the boot loader needed a virgin
> CPU (since, well, the SPL *is* a second U-Boot), so the restrictions
> mentioned in the page are not as relevant for modern SoCs.
>
> That's as far as my knowledge goes, if anyone wants to correct me,
> you're welcome to do so :-)

  ok, so it appears that wiki page is a little on the pessimistic
side, then. i was aware of the SPL, having worked with beaglebone
black for a while. i've never looked *closely* at how limited or
restrictive the SPL is, but i did know it had to do far less than the
full-featured u-boot. maybe it's time to look into that far more
closely to understand it better, and to appreciate what's possible.

  i can see this 2013 presentation, "TPL: SPL loading SPL (and, SPL as
just another U-Boot config", from scott wood of freescale. that looks
like it might be educational.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

[U-Boot] [U-Boot, v2] common: fit: Allow U-Boot images to be booted

[Tom Rini]

On Wed, Jul 20, 2016 at 08:32:50AM +0200, mario.six at gdsys.cc wrote:

> In certain circumstances it comes in handy to be able to boot into a second
> U-Boot. But as of now it is not possible to boot a U-Boot binary that is inside
> a FIT image, which is problematic for projects that e.g. need to guarantee a
> unbroken chain of trust from SOC all the way into the OS, since the FIT signing
> mechanism cannot be used.
> 
> This patch adds the capability to load such FIT images.
> 
> An example .its snippet (utilizing signature verification) might look
> like the following:
> 
> images {
> 	firmware at 1 {
> 		description = "2nd stage U-Boot image";
> 		data = /incbin/("u-boot-dtb.img.gz");
> 		type = "firmware";
> 		arch = "arm";
> 		os = "u-boot";
> 		compression = "gzip";
> 		load = <0x8FFFC0>;
> 		entry = <0x900000>;
> 		signature at 1 {
> 			algo = "sha256,rsa4096";
> 			key-name-hint = "key";
> 		};
> 	};
> };
> 
> Signed-off-by: Mario Six <mario.six@gdsys.cc>
> Reviewed-by: Tom Rini <trini@konsulko.com>

Applied to u-boot/master, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160725/3347bfde/attachment.sig>