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