[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 

> (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.


> 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 

> 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: