Re: Kernel uses only half of Mac IIci memory with built-in video
Hi Finn,
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. I guess once the RAM chunk list has been sorted, it was
most convenient to use that sorted list directly for the bootinfo records.
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).
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.
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 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.
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.
Cheers,
Michael
Reply to: