Re: Kernel uses only half of Mac IIci memory with built-in video
Hi Finn,
On Sun, Mar 21, 2021 at 2:31 AM Finn Thain <fthain@telegraphics.com.au> wrote:
> On Sat, 20 Mar 2021, Michael Schmitz wrote:
> > Am 19.03.21 um 12:49 schrieb Finn Thain:
> > > AIUI, Penguin needs a large physically contiguous region, so it used
> > > the largest pysical RAM chunk (which was bank B). But that alone
> > > doesn't really justify the weird sort order.
> >
> > If Penguin then loads the kernel in that same chunk, there really is no
> > other choice? (The kernel expects the memory chunk it runs from to be
> > listed first in the bootinfo struct).
> >
>
> But finding the largest chunk and putting it first doesn't imply sorting
> the whole list of bootinfo memory chunks by size. Moreover, the kernel now
> apprently requires chunks to be sorted by physical address, not by size.
>
> Why not sort chunks by physical address and omit any chunks prior to the
> largest one, to satisfy both requirements? Then ask users to re-arrange
> RAM SIMMs such that bank A is the largest.
>
> > I wonder about the 020 sorting scheme though - is there a hardware rule
> > that says the first chunk must be the largest on 020?
> >
>
> The Penguin-19 source code says,
>
> /* Hack for 020/68851. Kernel "head.S" does not handle
> * 020 with > 1 memory segment and kernel not in first
> * segment. Force kernel into first memory segment on
> * these (020) machines.
> */
>
> This "hack" first appeared in Penguin-14. The file Penguin.doc says,
>
> Status: Changed 980301
>
> New setting - "68020: Don't force kernel into bank A".
> Normally the 020's requires the kernel to be placed in
> bank A memory. The Penguin will force the kernel to be put
> in that bank on these machines. This setting will ignore
> the "forcing" and put the kernel in the bank with the
> largest amount of memory available.
> NOTE: Current kernels will fail if the kernel is not
> forced into bank A. Emergency setting if all else fails.
> Only available on 020's.
>
> That suggests that the bank A requirement comes from a kernel limitation,
> perhaps stemming from a 68551 quirk (?).
>
> Looking at MMU code in head.S in current kernels, mmu_map_tt() seems to
> contain the only special case for '020. But mmu_map_tt() is only used for
> Nubus slot space. So I'm none the wiser.
>
> Perhaps we need to look at head.S from before 1998 to figure out what
> motivated Penguin's '020 special case and the option to disable it?
Current head.S requires the kernel to fit in the first memory chunk,
in 4, 8, or 16 MiB, cfr. 486df8bc4627bdfc ("m68k: Increase initial
mapping to 8 or 16 MiB if possible").
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Reply to: