Re: [PATCH 4/5] ARM: Add basic support for EcoNet EN7523 SoC

[Ard Biesheuvel]

On Fri, 3 Sept 2021 at 18:20, Felix Fietkau <nbd@xxxxxxxx> wrote:
>
>
> On 2021-08-01 18:44, Ard Biesheuvel wrote:
> > On Fri, 30 Jul 2021 at 16:48, Arnd Bergmann <arnd@xxxxxxxx> wrote:
> >>
> >> Why is this needed?
> >>
> >> Note also the comment directly above it exlaining
> >> # Text offset. This list is sorted numerically by address in order to
> >> # provide a means to avoid/resolve conflicts in multi-arch kernels.
> >>
> >
> > Yes, please drop this - it is a horrible hack and it's already quite
> > disappointing that we are stuck with it for the foreseeable future.
> >
> > So I assume the purpose of this is to protect the first 128k of DRAM
> > to be protected from being overwritten by the decompressor?
> >
> > It would be best to move this reserved region elsewhere, but I can
> > understand that this is no longer an option. So the alternatives are
> > - omit this window from the /memory node, and rely on Geert's recent
> > decompressor changes which make it discover the usable memory from the
> > DT, or
> > - better would be to use a /memreserve/ here (which you may already
> > have?), and teach the newly added decompressor code to take those into
> > account when choosing the target window for decompressing the kernel.
> I looked into this issue myself and found that this approach has a
> significant drawback: 2 MiB of RAM is permanently wasted for something
> that only needs to be preserved during boot time.
>

How so? If that memory region carries your PSCI implementation, it
should be preserved permanently. So at least the 512k are permanently
reserved.

> If the first 256 or 512 KiB of RAM are reserved in the decompressor, it
> means that the first 2 MiB need to be reserved, because that's the
> granularity for the kernel page mapping when the MMU is turned on.
>

Indeed.

> If we reserve it, we also need to need to take it out of the physical
> RAM address range, so there's no way to reclaim it later.
>
> On the other hand, with the simple textofs solution, I believe it gets
> freed in a late initcall, making it usable.
>
> So what's the right approach to deal with this?
>

The right solution here is to fix your firmware/bootloader so that the
PSCI reserved region is moved to the top of memory. Adding more
TEXT_OFFSET hacks is really not the right approach here.