[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 Mon, 15 Mar 2021, Stan Johnson wrote:

> 
> The issue appears not to be limited to built-in video. With 16 MiB in 
> Bank A (4 x 4 MiB), 64 MiB in Bank B (4 x 16 MiB), a RasterOps 
> ColorBoard 264 in the Nubus slot nearest the PDS slot (which contains a 
> 32K cache card), and a Farallon Ethernet card in the middle Nubus slot, 
> Linux 4.1.167 sees only 64 MiB of memory, presumably all from Bank B. 
> Mac OS 7.5.5 and 8.1 see 80 MiB, as does NetBSD 9.1.
> 

I would also try a recent mainline build. Here's a build with 
CONFIG_FLATMEM=y.

https://www.telegraphics.com.au/~fthain/build/linux-m68k-image-5.11.0-mac.tar.gz
https://www.telegraphics.com.au/~fthain/build/vmlinux-5.11.0-mac

MD5 (linux-m68k-image-5.11.0-mac.tar.gz) = 43de77ea582f227723a858d121164992
MD5 (vmlinux-5.11.0-mac) = 7846d66dc23b72eed8c1597c643615c1

(The old 4.1.167 build that I made has too many backported patches to be 
called "4.1.167" and not enough backported fixes to be representative of 
mainline. A good compromise is 4.14.221-mac-backport+ on sourceforge.)

> With 16 MiB in each bank, using a Mac II video card and an Asante 10/100 
> Ethernet card, Linux sees all 32 MiB (I didn't test this combination 
> with 80 MiB or 128 MiB). 
> 
> Unfortunately, while the Asante 10/100 card works fine in Mac OS, I 
> couldn't find an appropriate Linux driver (I think it used to use an SMC 
> driver, but I couldn't find one in modern kernels that works). 

Linux probably has a driver for the SMC chip but it has no driver for that 
particular card.

> And the RasterOps card is a better video card than the Mac II (Toby) 
> video card, though I think the RasterOps card may be causing a "failed 
> to turn off interrupts, booting anyway" message in Penguin while booting 
> Linux (possibly causing the memory issue?).
> 

You can ignore the "failed to turn off interrupts" message (that is, until 
you see Linux fail to start).

> On a different IIci, with 64 MiB in each bank, using a Mac II video card 
> and a Farallon Ethermac II-C card, Linux sees all 128 MiB (with no 
> "failed to turn off interrupts..." message).
> 

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.

> Does anyone know whether there's a way to have Penguin send a custom 
> list of free memory ranges to Linux?
> 

Not AFAIK.

> If anyone wants to do any further testing, I'd be happy to help.
> 

The complete Penguin logs may shed some light on the pertinent differences 
between the 80 MB machine and the 32 MB machine.

In particular, if you see "Bootstrap logical 2" it would indicate that 
Penguin is performing a "rbv boot". From the source code--

        /* Get new_copy_and_go_ptr physical to logical translation, i.e. where the
         * bootstrap code will be located when the MMU is disabled. This is only
         * neccessary when logical(0) != physical(0) (a 'rbv boot' where the video
         * circuitry claims RAM to drive the display).
         * Should it be a rbv boot then we'll have to copy our bootstrap code
         * to the video base since this is where we'll have address 0.
         * If we have a logical video address equal to the physical address then
         * this not a 'real' RBV boot but a boot with no memory in bank A and
         * an external video card. This makes it possible to use the video base
         * as the boot code placement, alone, since the MMU does not affect the logical<->
         * physical mapping.
         */


Reply to: