Re: Kernel uses only half of Mac IIci memory with built-in video
On Tue, 23 Mar 2021, Michael Schmitz wrote:
> On 22/03/21 6:24 pm, Finn Thain wrote:
> > > 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.
>
> Can't fault your reasoning there. The use case of multiple large chunks
> present (and only the largest one used unless banks are rearranged)
> might have been rare back in '98.
>
The larger-bank-B issue would have to be an old one but it only affects a
few models.
The equal-sized-banks problem is only theoretical at this stage. Penguin
uses a stable sorting algorithm for the RAM chunks which means that if
banks A and B had equal size, there would be no re-ordering at all. (I'm
ignoring Penguin's Mac II hack here.)
That means RAM chunks would remain in logical address sequence. I wonder
whether that sequence could differ between the ROM execution environment
(for EMILE) and that of MacOS applications (for Penguin)...
> > > > 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.)
>
> Do you know the size of the uncompressed kernel at that stage? That way,
> you could skip all RAM banks smaller than that size (plus some margin
> for the initial mappings, one 4k page for each 4 MB of chunk size plus
> required number of pointer table pages) and use the first one (lowest
> address one) that satisfies such a minimum size criterion.
>
> In this way, you won't lose all of the smaller but still useful banks,
> just in case a user arranged the banks in ascending size order.
>
Right. The difficulty is the "some margin" part, which seems fairly
complicated.
> (Skipping the lower address banks isn't strictly required BTW - the
> kernel will warn and ignore them as it used to. No harm done.)
>
> [...]
>
> > > 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.
>
> Probably good cause to only use it for video RAM through a separate
> allocator and pool (if a user absolutely insists and someone writes a
> patch that you would accept). We can't share it with the kernel anyway
> at present (and with a fixed size of 1 MB, it would be useless for
> modern times kernels).
>
I don't understand Linux MM in sufficient depth to comment.
Anyway, Penguin does take pains to support booting from bank A when
on-board video is enabled in RBV machines. (The performance penalty can be
minimized: for 1 bpp, 640 x 480, 67 Hz the penalty is only 6% of the full
bandwidth of bank A RAM. And the framebuffer would only cost 64 KiB. So
there is value in supporting this configuration.)
> [...]
>
> I think I've found the difference: commit
> 75ce89a86b88c2dd77a0d2697c1ecaf9c53016ce (the earliest//I found) has
> head.S set up a page descriptor entry at the pointer table level (i.e.
> 'early termination' descriptor). That maps 32 MB in one go, regardless
> of size and alignment of that chunk, which would not have mattered for
> Atari and Amiga (as far as I know, the RAM banks are far enough apart
> for such mappings not to overlap) but might have caused trouble on Mac
> if the RAM banks fall within 32 MB and the kernel runs from the second
> bank (which then isn't 32 MB aligned).
>
I didn't find that commit. But it certainly sounds like you've put your
finger on the underlying issue. Thanks for solving this mystery!
> Today's head.S only uses early termination only if both size and
> alignment match.
>
OK.
> As you said, there is no distinction made between 020 and 030 in that
> code, so the same hack should have been applied to 030. Maybe the MacII
> (were there other 020 Macs?) was the only one with RAM banks A and B
> spaced closer than 32 MB?
>
Brad has already dug up the answer for that question (thanks, Brad).
> > 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.
>
> I'm quite certain that today's head.S needs no more 020 hacks and ought
> to work on MacII if you can fit enough RAM in bank B to hold the kernel.
> But finding a MacII to test this on is more than a little academic
> indeed.
>
I have most of the affected models but they probably need new capacitors
etc.
> Let's fix the meminfo chunk ordering and see whether that fixes Stan's
> issues. I have no doubt that as long as the long-standing constraint
> about the first chunk holding the kernel isn't violated, old kernels
> will continue to boot OK.
>
Good to know.
> Cheers,
>
> Michael
>
>
>
Reply to: