Re: Kernel uses only half of Mac IIci memory with built-in video
On Tue, 16 Mar 2021, Stan Johnson wrote:
>
> This is getting complicated quickly, and some of my earlier conclusions
> were wrong.
>
Yes, it's getting complicated. But it should not be necessary to rearrange
RAM or video cards to avoid a crash from v5.11...
I suspect that v5.10 (with CONFIG_DISCONTIGMEM=y) would probably behave
the same as v4.14.167-mac-backport+ (that is, no crash). Here's a build
that will allow you to confirm that.
https://www.telegraphics.com.au/~fthain/build/linux-m68k-image-5.10.0-mac.tar.gz
https://www.telegraphics.com.au/~fthain/build/vmlinux-5.10.0-mac
MD5 (linux-m68k-image-5.10.0-mac.tar.gz) = 3d3158ba5c48ef017fbe36a6308786a5
MD5 (vmlinux-5.10.0-mac) = 02fb433fb59b1f500c5bba46a614c646
> I have these two Mac IIci systems:
>
> System A: 128 MB (64 MB in each bank), Mac II Video Card, Farallon
> EtherMac II-C
>
> System B: 80 MB (16 MB in Bank A, 64 MB in Bank B), Mac II Video Card,
> Farallon EtherMac II-C
>
> When either System A or System B is using built-in video, Linux
> 4.14.167-mac-backport+ sees only the memory that is in Bank B.
I would expect to see the same from any Linux build (?). IIUC, this
configuration would cause Penguin to log "RBV boot, logical 0x00000000 at
0x...".
> When System B uses a RasterOps video card, only the memory in Bank B is
> seen (even if the amount of memory in Banks A and B is the same). I'm
> not able to get System B to see all memory except when using the Mac II
> video card and with the same amount of memory in Banks A and B.
>
It's odd that RasterOps vs. Apple Nubus video card would have an affect on
the bootloader. In the Penguin source code, I do see some direct
interaction with Apple's video drivers. This does seem a little fragile.
But I'd need to study this code before I could claim to understand it.
> Using the 5.11.0-mac kernel with CONFIG_FLATMEM=y, System B crashes, but
> System A works. With 16 MB in both Banks A and B, System B doesn't
> crash, either, and 5.11.0-mac sees all 32 MB (see attached serial
> console log for System B, first boot crashes with 80 MB, second boot
> works with 32 MB). So where 4.14.167-mac-backport+ saw only the memory
> in Bank B, 5.11.0-mac crashes (I didn't try 5.11.0-mac without the
> CONFIG_FLATMEM=y option).
>
Am I right in thinking that Linux only crashes when Penguin loads the
kernel into Bank A (i.e. Penguin says "The kernel will be located at
physical 0x00001000") and the kernel then goes and drops that segment
(i.e. Linux says "Ignoring memory chunk at 0x0:0x1000000 before the first
chunk")?
> > ... It would be interesting to see the list of RAM segments that
> > Penguin generates on these machines (you can get Penguin to log them
> > without starting the kernel).
> >
> >> Maybe Mac OS reserves memory from Bank A for video unless the ROM
> >> recognizes a known Apple video card (such as the Mac II video card)?
> >
> > Penguin on the 80 MB machine might work better if you swapped out the
> > RasterOps board in favour of a Mac II video board... it's probably
> > worth trying.
> >
> > Are these machines running the same version of Mac OS? Penguin has
> > some funky IIci video driver patching code that might be affected by
> > ROM version or MacOS version. ...
>
> Yes, both are running Mac OS 7.5.5. The attached Penguin output is for
> 5.11.0-mac from System B; Penguin-1.txt is with 80 MB (crashes),
> Penguin-2.txt is with 32 MB (16 MB in each Bank) (works).
>
Thanks for collecting these logs. The Penguin logs show that rbv_boot is
false, indicating that the on-board video is not in use, as described.
So I think the important question is, why does Penguin fail to sort the
segments in this case? That is, why did Penguin produce this list:
Physical RAM: 80 MB
...
BI_MEMCHUNK[0].addr = 0x04000000
BI_MEMCHUNK[0].size = 0x04000000
BI_MEMCHUNK[1].addr = 0x00000000
BI_MEMCHUNK[1].size = 0x01000000
rather than a sorted list, something like the other example:
Physical RAM: 32 MB
...
BI_MEMCHUNK[0].addr = 0x00000000
BI_MEMCHUNK[0].size = 0x01000000
BI_MEMCHUNK[1].addr = 0x04000000
BI_MEMCHUNK[1].size = 0x01000000
> -Stan Johnson
>
Reply to: