On Thu, Sep 22, 2022 at 01:03:04AM +0100, Andre Przywara wrote:
> On Wed, 21 Sep 2022 13:56:44 -0400
> Tom Rini <tr...@konsulko.com> wrote:
>
> Hi Tom,
>
> > On Wed, Sep 21, 2022 at 06:09:46PM +0100, Andre Przywara wrote:
> > > Commit c0fce929564f("vexpress64: fvp: enable OF_CONTROL") added code to
> > > consider a potential DTB address being passed in the x0 register, or
> > > revert to the built-in DTB otherwise.
> > > The former case was used when using the boot-wrapper, to which we sell
> > > U-Boot as a Linux kernel. The latter was meant for TF-A, for which we
> > > couldn't find an easy way to use the DTB it uses itself. We have some
> > > quirk to filter for a valid DTB, as TF-A happens to pass a pointer to
> > > some special devicetree blob in x0 as well.
> > >
> > > Now the TF-A case is broken, when enabling proper emulation of secure
> > > memory (-C bp.secure_memory=1). TF-A carves out some memory at the top
> > > of the first DRAM bank for its own purposes, and configures the
> > > TrustZone DRAM controller to make this region secure-only. U-Boot will
> > > then hang when it tries to relocate itself exactly to the end of DRAM.
> > > TF-A announces this by carving out that region of the /memory node, in
> > > the DT it passes on to BL33 in x1, but we miss that so far.
> > >
> > > Instead of repeating this carveout in our DT copy, let's try to look for
> > > a DTB at the address x1 points to as well. This will let U-Boot pick up
> > > the DTB provided by TF-A, which has the correct carveout in place,
> > > avoiding the hang.
> > > While we are at it, make the detection more robust: the length test (is
> > > the DT larger than 256 bytes?) is too fragile, in fact the TF-A port for
> > > a new FVP model already exceeds this. So we test x1 first, consider 0
> > > an invalid address, and also require a /memory node to detect a valid DTB.
> > >
> > > And for the records:
> > > Some asking around revealed what is really going on with TF-A and that
> > > ominous DTB pointer in x0: TF-A expects EDK-2 as its non-secure payload
> > > (BL33), and there apparently was some long-standing ad-hoc boot protocol
> > > defined just between the two: x0 would carry the MPIDR register value of
> > > the boot CPU, and the hardware DTB address would be stored in x1.
> > > Now the MPIDR of CPU 0 is typically 0, plus bit 31 set, which is defined
> > > as RES1 in the ARMv7 and ARMv8 architectures. This gives 0x80000000,
> > > which is the same value as the address of the beginning of DRAM (2GB).
> > > And coincidentally TF-A put some DTB structure exactly there, for its
> > > own purposes (passing it between stages). So U-Boot was trying to use
> > > this DTB, which requires the quirk to check for its validity.
> >
> > So, follow-up question. Why don't we just always look at x1 and never x0
> > for the DTB? That would seem to be a bugfix and should work on older
> > TF-A releases too, yes?
>
> There is a use case where the boot-wrapper[1] runs U-Boot, as a kind of
> poor-man's TF-A replacement. As the boot-wrapper normally just runs
> kernels, it follows the arm64 Linux kernel boot protocol, which puts
> the DTB address in x0. So to stay flexible, we look at both registers.
> The kernel boot protocol says x1 must be 0, so we check for that first,
> to sort that out.Ah, thanks! -- Tom
signature.asc
Description: PGP signature
