Re: Amigas with both Zorro-II and Zorro-III RAM?

[Michael Schmitz <schmitzmic@gmail.com>]

Ingo,

On 5/12/18 12:12 PM, Ingo Jürgensmann wrote:
> Am 04.12.2018 um 23:32 schrieb Johny Five <koxman@gmail.com>:
>
> > You mean A3000 or A4000 with some onboard/cpu accelerator FastRam + ZorroRAM/BigRAM in Zorro3 slot?
> >
> > On Tue, Dec 4, 2018 at 11:23 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
> > All,
> >
> > anyone on this list with an Amiga running Linux that has both Zorro-II
> > and Zorro-III RAM installed, so would trigger the warning message:
> >
> > "%dK of Zorro II memory will not be used as system memory\n"
> >
> > early during booting the kernel?
> >
> > Would be nice to get Geert's patch (see
> > <20181204195014.21461-1-geert@linux-m68k.org>) tested on such a system.
> Yes, this should be the same with the BigRamPlus extension, except that on Amigas the address scheme is of course different and Amigas will use memory priorities (the faster the memory is, the higher the priority is).
> ChipRam should be priority 0, normal (fake) FastRam is about priority 20 or so while real FastRam on an accel board like Cyberstorm MK2 is about priority 40 or so.
> See also http://amiga.nvg.org/amiga/reference/Hardware_Manual_guide/node00D4.html or https://www.amigacoding.com/index.php/Amiga_memory_map for a quick reference or search for my post on this ML about the BigRamPlus in Spice/Arrakis.
> For that link you can see several memory chunks like Chip Memory, Zorro II Memory Expansion space, Expansion Memory, Motherboard Fast RAM, maybe Copressor Slot Expansion and Zorro III Expansion.

Thanks for jogging my memory - from that memory map, I would think that 
the kernel should be able to utilize both FastRAM (on the accelerator 
board) and BigRamPlus (which would be in the Zorro-III address space?) 
as long as the kernel runs in FastRAM.

What is the problem with making use of BigRamPlus as system memory by 
the kernel? Do we need to update amiboot? Or fudge a a suitable bootinfo 
struct including the additional memory segment and use kexec to boot the 
kernel to make use of that fudged data?
> I’m not sure if that patch will fix that issue, but neither I’m a kernel hacker nor a programmer, nor do I know if memoryblock is a block of memory or memory to block from being used. ;-)
memblock is just a way of keeping track of physical memory areas in the 
kernel early on during boot. Does not solve the issue of memory 
ordering, or whatever other issue we saw with BigRamPlus.
> Back then during the discussion about BigRamPlus donation by Debian the conclusion was that memory pools need to be ported to make use of the BRP which would also solve the issue of ST-RAM for the Ataris, IIRC.


m68k would have to support the sparsemem memory model, but yes, that 
seemed a bridge too far at that time. I still have no idea how m68k 
memory management really works.

Cheers,

    Michael



>