Re: [PATCH 04/12] mips: Reserve memory for the kernel image resources

From: Maciej W. Rozycki
Date: Wed Oct 14 2020 - 05:49:14 EST


On Wed, 22 May 2019, Serge Semin wrote:

> > > The problem might be fixed there by the next patch:
> > > ---
> > > diff --git a/arch/mips/dec/prom/memory.c b/arch/mips/dec/prom/memory.c
> > > index 5073d2ed78bb..5a0c734b5d04 100644
> > > --- a/arch/mips/dec/prom/memory.c
> > > +++ b/arch/mips/dec/prom/memory.c
> > > @@ -91,29 +91,14 @@ void __init prom_meminit(u32 magic)
> > > pmax_setup_memory_region();
> > > else
> > > rex_setup_memory_region();
> > > -}
> > > -
> > > -void __init prom_free_prom_memory(void)
> > > -{
> > > - unsigned long end;
> > > -
> > > - /*
> > > - * Free everything below the kernel itself but leave
> > > - * the first page reserved for the exception handlers.
> > > - */
> > >
> > > #if IS_ENABLED(CONFIG_DECLANCE)
> > > /*
> > > - * Leave 128 KB reserved for Lance memory for
> > > - * IOASIC DECstations.
> > > + * Reserve 128 KB for Lance memory for IOASIC DECstations.
> > > *
> > > * XXX: save this address for use in dec_lance.c?
> > > */
> > > if (IOASIC)
> > > - end = __pa(&_text) - 0x00020000;
> > > - else
> > > + memblock_reserve(__pa_symbol(&_text), 0x00020000);
> >
> > Shouldn't that be
> >
> > memblock_reserve(__pa_symbol(&_text) - 0x00020000, 0x00020000);
> >
> > ?
> >
>
> Right. Thanks. The updated version of the patch is attached to this email.
>
> -Sergey
>
> > > #endif
> > > - end = __pa(&_text);
> > > -
> > > - free_init_pages("unused PROM memory", PAGE_SIZE, end);
> > > }
> > > ---
> > >
> > > Didn't wanna use prom_FREE_prom_memory to actually reserve a memory
> > > chunk, so I moved the reservation into the prom_meminit() method.
> >
> > I guess Maciej will test this on real hardware, eventually...

I finally got to it as I was hit by it the hard way (and I do have kept
the thread in my inbox!), however this is the wrong fix.

With DEC hardware the whole 128KiB region is reserved as firmware working
memory area and we call into the firmware throughout bootstrap on several
occasions. Therefore we have to stay away from it until we know we won't
need any firmware services any longer, which is at this point. So this
piece has to stay, and the removed reservation has to be reinstated in
platform code. I'll be posting a fix separately.

NB I suspect CFE platforms may need a similar fix, but I don't have
access to my SWARM now, so I'll verify it on another occasion.

Other platforms may need it too; at least up to a point an assumption was
the kernel load address is just at the end of any firmware working area
typically allocated right beyond the exception vector area, hence the
reservation. I realise the assumption may have changed at one point and
the oldtimers who have known it may have been away or not paying enough
attention while the newcomers did not realise that.

Maciej