Re: Kernel uses only half of Mac IIci memory with built-in video
On Mon, 22 Mar 2021, Michael Schmitz wrote:
> On 21/03/21 2:31 pm, Finn Thain wrote:
> >
> > > 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.
>
> I see. You are correct - the only constraint really is that the largest
> chunk (with the kernel in it) come first.
>
> The remaining chunks do not have to be sorted by size but could appear
> in any order.
It seems that I misunderstood the "Ignoring memory chunk" warning. I
thought that all chunks had to be sorted by physical address. But the
actual requirement in arch/m68k/mm/motorola.c is only that
m68k_memory[0].addr < m68k_memory[i].addr, where i > 0.
The other constraints (thanks to Geert for pointing them out) come from
arch/m68k/kernel/head.S. The first chunk has to contain the kernel and
have size >= 4 MB (preferably 8 or 16 MB).
> I guess once the RAM chunk list has been sorted, it was most convenient
> to use that sorted list directly for the bootinfo records.
>
A constraint that says the first chunk must be the largest one is
undesirable because if the largest chunk has higher address than some
other large chunk, the latter would become inaccessible.
A similar problem arises when you have only two chunks of equal size.
Sorting by size doesn't help and the bootloader could theoretically end up
putting the kernel in bank B, leaving bank A unavailable.
> >
> > 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.
>
> Yes, that could be done. I don't think the kernel would mind any RAM
> banks not passed in the bootinfo struct (to wit, IIRC amiboot has a
> 'memfile' option to allow exclusion of RAM chunks from bootinfo, to skip
> RAM that's slow or unreliable).
>
Based on the commit that Geert cited, I'd be inclined to sort chunks by
physical address, find the lowest chunk having size >= 16 MB and put that
one and the higher ones into bootinfo. (Or failing that, find the one
having size >= 8 MB, or failing that, 4 MB.)
A full sort isn't really needed here but does offer some determinism. Are
there implications for mm data structures? E.g. memblock_add_node() is
called for each chunk, and if the chunks are in the "wrong" order, perhaps
that would affect mm algorithms (?)
> A warning from Penguin with advice to rearrange the largest RAM into
> bank A (if possible) would certainly be more visible to the user than
> the one-line warning early in the kernel boot log.
>
I agree. The existing warning isn't very helpful.
> Does any of this help with the problem of RBV Macs? Video RAM must start
> at address 0x0, and reordering RAM to have the largest chunk at that
> address would occupy the RBV video range and render RBV unusable? Can
> you even rearrange RAM in these machines?
>
I've argued elsewhere in this thread that the bank A issue in RBV Macs
doesn't matter that much.
If on-board video is enabled, bank A is slowed down. That suggests to me
that bank A is probably not that useful for Linux and is probably
relatively small anyway. As Brad said, bank A is always 1 MB on a IIsi. So
I don't mind if Linux ignores it in this case.
If on-board video is disabled, we can treat both banks in an RBV Mac the
same (like we would a non-RBV Mac).
> >
> > > 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 (?).
> The 68020/68851 combo is functionally equivalent to the 68030 as far as
> I recall. I don't think such a limitation exists today in today's
> head.S.
> >
> > 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.
> Yes, and what mmu_map_tt falls back to on 020 is the same code that gets
> otherwise used on 030 and 020 alike. I can't see a reason why this hack
> would still be necessary.
It appears that EMILE does not have this hack for 68020/68851. (I assume
EMILE has been tested on 68020/68851.)
> > 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?
>
> I know the head.S MMU code was completely rewritten around that time to
> accommodate changes needed for the Mac port. What we used before on
> Atari and Amiga bears little to no relation to what we have now. My
> guess is that 030 (has transparent translation register) and 020 (does
> not have tt1) used distinct code paths before the rewrite, but share
> much of the code now.
>
> I haven't found a kernel source that old on my system so I can't verify
> my recollection of this though. Geert has a git tree somewhere that
> contains all the ancient history, might be worth checking.
>
Maybe that rewrite happened around the "pre2.05" release...
https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/arch/m68k/kernel/head.S?h=2.0&id=37147b87dddfc389e97d99f078be5a0f1012ba74
Unfortunately, even in the oldest head.S at that link, it's not obvious to
me why 68020/68851 and 68030 would execute different code paths. It's easy
to believe that the Penguin hack for 68020/68851 was incomplete (should
have been extended to 68030).
But that's academic. If we change the bootloader to fix the issue that
Stan reported and if it remains backwards compatible with Linux v2.2.25
(or Debian 3) I'd be happy with that.
> Cheers,
>
> Michael
>
>
>
Reply to: