[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, 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.


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 

> 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 

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