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

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