Re: [PATCH] vexpress64: also consider DTB pointer in x1

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 2637 bytes --]

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.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Tested-by: Peter Hoyes <peter.hoyes@arm.com>

Applied to u-boot/master, thanks!

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]