From mboxrd@z Thu Jan  1 00:00:00 1970
From: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Date: Tue, 8 Jan 2019 07:56:58 +0100
Subject: [U-Boot] [PATCH v1 0/4] arm: socfgpa: support of-platdata
In-Reply-To: <1f8fdec8-68d0-ad64-350d-5d290294a0cf@denx.de>
References: <20190107211423.10151-1-simon.k.r.goldschmidt@gmail.com>
 <1f8fdec8-68d0-ad64-350d-5d290294a0cf@denx.de>
Message-ID: <CAAh8qsyB_tQweHaC_epVtZ8ARx1gbnpty+=d5zNJ9MokGA7d6A@mail.gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On Mon, Jan 7, 2019 at 11:59 PM Marek Vasut <marex@denx.de> wrote:
>
> On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
> > This is an initial attempt to support OF_PLATDATA for socfpga gen5.
> >
> > There are two motivations for this:
> > a) reduce code size to eventually support secure boot (where SPL has to
> >    authenticate the next stage by loading/checking U-Boot from a FIT
> >    image)
> > b) to support the cyclone 5 boot ROM's CRC check on the SPL in SRAM
> >    (on warm-restart), all bytes to check need to be in one piece. With
> >    OF_SEPARATE, this is not the case (.bss is between .rodata and the
> >    DTB). Since OF_EMBEDDED has been discouraged, OF_PLATDATA seems to
> >    be a good solution.
>
> I'd much prefer parsing the DT (and thus, decoupling the SW from HW)
> than having some ad-hoc plat data again if we can avoid that.

So you're against the whole OF_PLATDATA thing or how should I understand
that?

It's not really ad-hoc, it's the DT converted to C structs. It's just in another
format, but it's still (sort of) decoupled SW from HW.

As written above, I have two goals I want to achieve with this. Right now, I
cannot enable verified boot in SPL because the available OCRAM cannot
hold all the code. And it seemed to me OF_PLATDATA could help me there.

Regards,
Simon