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 >
