All of lore.kernel.org
 help / color / mirror / Atom feed
From: "François Ozog" <francois.ozog@linaro.org>
To: u-boot@lists.denx.de
Subject: Fit images and EFI_LOAD_FILE2_PROTOCOL
Date: Tue, 6 Oct 2020 16:22:07 +0200	[thread overview]
Message-ID: <CAHFG_=WJpO2O0_HunzbhV=mXtWTk61=sb91dftxCZZu_8Vyrcg@mail.gmail.com> (raw)
In-Reply-To: <91be0932-372a-7ee3-5ae4-297cc89c039a@arm.com>

Ard, there is a question for you in the below thread ;-)

On Tue, 6 Oct 2020 at 15:02, Grant Likely <grant.likely@arm.com> wrote:

>
>
> On 06/10/2020 13:52, Heinrich Schuchardt wrote:
> > On 06.10.20 14:43, Grant Likely wrote:
> >
> >>
> >> Current U-Boot by default uses the same DT image for both U-Boot
> >> internal setup and to provide to the OS. This should be split so that
> >> the U-Boot internal version has what U-Boot needs without needs to track
> >> mainline Linux DTB schema.
> >>
> >> I've been looking into a generic config for adding a separate OS-dtb to
> >> U-Boot that is not used internally and is only passed to the OS. That
> >> would solve the problem you're seeing above.

>
> > What would be the advantage of building said second device-tree into
> > U-Boot instead of loading it from a (possibly signed) file?
>
> I would see that as an implementation detail, but from the OS point of
> view EBBR requires the firmware to provide a DTB to the OS without the
> OS having any involvement in providing it. The easiest solution is to
> embed the OS dtb into U-Boot, but it could be loaded and verified from a
> file as well.
>
To strongly state that the DT is a hardware description entity,
disconnected from open source projects consuming it,
 I would still build the DT for the Booted Payload in the context of
devicetree.org and append it to either FIP or U-Boot.
From a hierarchical perspective FIP would make more sense (I was told by
the LinuxBoot guys that the ACPI tables are
tied to PEI so that they can use them while replacing EDK2. I am not sure
my understanding is correct: Ard ?)
as I consider that PEI and TF-A are at the same layer I am inclined to
promote this.
Should the DTB cause problems, the one embedded in the FIT would be
replacing the platform base one
 (I assume this is your "loaded and verified from a file" comment).

>
> g.
>


-- 
Fran?ois-Fr?d?ric Ozog | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog

  reply	other threads:[~2020-10-06 14:22 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-03  8:51 Fit images and EFI_LOAD_FILE2_PROTOCOL Heinrich Schuchardt
2020-10-03 11:14 ` François Ozog
2020-10-03 11:16   ` François Ozog
2020-10-03 13:12     ` Ard Biesheuvel
2020-10-03 16:35       ` Heinrich Schuchardt
2020-10-03 16:59         ` Ard Biesheuvel
2020-10-05  6:33       ` Ilias Apalodimas
2020-10-05 14:12       ` François Ozog
2020-10-05 15:25         ` Daniel Thompson
2020-10-05 17:14           ` François Ozog
2020-10-04 23:41 ` Cristian Ciocaltea
2020-10-05 22:37 ` Grant Likely
2020-10-06  4:35   ` Heinrich Schuchardt
2020-10-06  7:20     ` Ard Biesheuvel
2020-10-06  8:00       ` François Ozog
2020-10-06  8:05         ` Ard Biesheuvel
2020-10-06 10:13           ` François Ozog
2020-10-06 10:23             ` Ard Biesheuvel
2020-10-06  9:58         ` Daniel Thompson
2020-10-06 10:38     ` Grant Likely
2020-10-06 12:04       ` François Ozog
2020-10-06 12:36         ` Heinrich Schuchardt
2020-10-06 12:43           ` Grant Likely
2020-10-06 12:52             ` Heinrich Schuchardt
2020-10-06 13:02               ` Grant Likely
2020-10-06 14:22                 ` François Ozog [this message]
2020-10-06 14:46                   ` Ard Biesheuvel
2020-10-06 15:08                     ` François Ozog
2020-10-06 15:32                       ` François Ozog
2020-10-06 17:50                       ` Ard Biesheuvel
2020-10-06 13:00           ` François Ozog
2020-10-06 12:38         ` Grant Likely
2020-10-06 12:05       ` Heinrich Schuchardt
2020-10-06 12:15         ` François Ozog
2020-10-06 12:41       ` Ilias Apalodimas
2020-10-06 12:46         ` Grant Likely
2020-10-06 13:12           ` Heinrich Schuchardt
2020-10-06 14:09             ` François Ozog

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHFG_=WJpO2O0_HunzbhV=mXtWTk61=sb91dftxCZZu_8Vyrcg@mail.gmail.com' \
    --to=francois.ozog@linaro.org \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.