[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 at 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
========================================================================