On Sat, Dec 01, 2018 at 11:51:52AM +1300, Michael Schmitz wrote:
Andreas,
Am 01.12.2018 um 11:23 schrieb Andreas Schwab:
On Dez 01 2018, Michael Schmitz <schmitzmic@xxxxxxxxx> wrote:
Must be a new kind of monster kernel that wouldn't fit inside 14 MB.
There's way more than the kernel that must fit in 14 MB.
I realize that. I only said to try and load the kernel to ST-RAM, not to
switch off FastRAM entirely. Anything beyond a very minimal (or old) user
space won't fit in 14 MB anymore, running out of VM even before swapon can
run.
The 'skipping memory chunk 0:e00000 before the first chunk' to me means the
bootstrap has reordered memory chunks so FastRAM comes before ST-RAM. It
only does that when the kernel was loaded to FastRAM. Shortcomings of the
old memory model caused the mis-ordered ST-RAM chunk then not to be mapped
in kernel VM space at all. We still need ST-RAM for video framebuffer and
DMA-able memory on Falcon, so I provided a dedicated ST-RAM allocator
(similar to what Geert did for Zorro2-RAM) that will map a pool of ST-RAM
and use that to satisfy the needs of atafb, atari_scsi and the like.
I had looked over Mike's patches to check that handling of such reserved
memory hasn't changed, but I have evidently missed something. Since kernels
with 'normal' ram chunk ordering work fine, the alternate ordering code path
is my prime suspect.
If I understand correctly, there are two types of RAM on Atari/ARAnyM:
ST-RAM and FastRAM. The ST-RAM resides at the physical range 0x0 - 0xe00000 and
FastRAM takes a range somewhere above.
When the kernel is loaded into the FastRAM, bootloader sets the first entry
in the memory info to the FastRAM and the second one to ST-RAM and thus
m68k_memory becomes something like:
[0] = {
<FastRAM start>, <FastRAM size>,
},
[1] = {
0x0, 0xe00000,
}
In the paging_init() the ST-RAM chunk is essentially removed from the
m68k_memory, but it still can be used via the dedicated ST-RAM allocator.
Yet, my patch surely didn't take such reordering into account, and, more
importantly, I didn't take care of the removal of an entry from
m68k_memory. As the result, memblock sees ST-RAM as available and will
allocated memory from there, but this memory is not yet mapped.
I don't know what were the shortcomings of the old memory model, and why
ST-RAM and FastRAM are treated differently, so probably the simplest way
would be just inform memblock that the ST-RAM is not available to it:
diff --git a/arch/m68k/mm/motorola.c b/arch/m68k/mm/motorola.c
index 7497cf3..0bda2c4 100644
--- a/arch/m68k/mm/motorola.c
+++ b/arch/m68k/mm/motorola.c
@@ -233,6 +233,7 @@ void __init paging_init(void)
printk("Ignoring memory chunk at 0x%lx:0x%lx before the first chunk\n",
m68k_memory[i].addr, m68k_memory[i].size);
printk("Fix your bootloader or use a memfile to make use of this area!\n");
+ memblock_remove(m68k_memory[i].addr, m68k_memory[i].size);
m68k_num_memory--;
memmove(m68k_memory + i, m68k_memory + i + 1,
(m68k_num_memory - i) * sizeof(struct m68k_mem_info));
I've tried to reproduce the bug by attempting to get the kernel loaded to
FastRAM. Doesn't work for me - with or without -s option I get the same
ordering of memory chunks (ST-RAM first) so the kernel clearly still runs in
ST-RAM.
Hence my question - how did you get the kernel loaded to FastRAM? What
version of ARAnyM do you use? What's the size of your kernel (uncompressed)?
Cheers,
Michael
--
Sincerely yours,
Mike.
