Ingo,
On 5/12/18 12:12 PM, Ingo Jürgensmann wrote:
Am 04.12.2018 um 23:32 schrieb Johny Five <kox...@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 <schmitz...@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-ge...@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
