[PATCH 1/6 v14] ARM: Handle a device tree in lowmem

Ard Biesheuvel ardb at kernel.org
Tue Oct 6 05:16:15 EDT 2020


On Tue, 6 Oct 2020 at 11:11, Linus Walleij <linus.walleij at linaro.org> wrote:
>
> On Mon, Oct 5, 2020 at 4:22 PM Ard Biesheuvel <ardb at kernel.org> wrote:
>
> > I think the problem here may be that early_init_fdt_reserve_self()
> > uses the wrong translation for obtaining the PA of the device tree
> > blob. This is also the reason we no longer use it on arm64 IIRC.
> >
> > When I add the following on top, everything works as expected with
> > MT_ROM, including the ability to dump the firmware provided DT from
> > /sys/firmware/fdt
> (...)
> > -       if (atags_vaddr)
> > +       if (atags_vaddr) {
> >                 mdesc = setup_machine_fdt(atags_vaddr);
> > +               if (mdesc)
> > +                       memblock_reserve(__atags_pointer,
> > fdt_totalsize(atags_vaddr));
>
> I tested with this too and it works fine, and makes perfect sense,
> it should protect the physical memory used by the DT even if
> that happens to be in lowmem.
>
> Please fold this into the patch! (Reviewed/Tested-by).
>

OK, thanks. The patches will look slightly different, though, so you
may have to take another look, and give these in reply.

> If we go for copying and unflattening the
> devicetree instead of just unflattning it the memblock should
> be removed, which is nice and clean to my OCD because
> then we don't have this random "hole" in the memory, but I
> suspect then we should also drop the virtual mapping and
> that seems like it could be hard.
>

We don't actually unmap the DT from the linear region, we just alias
it elsewhere in the VA space, so that we don't have to reason about
whether the DT is in the first memblock or below/above/whatever.

So the DT is just one of the many memblock_reservations, and this
actually doesn't change - the DT is still there, it is reserved, we
just access it via another route.



More information about the linux-arm-kernel mailing list