nf_init() uses virt_to_phys(), which depends on m68k_memoffset being set and
module_fixup() having been called, but this is only done in paging_init().
Hence call paging_init() before nf_init().
This went unnoticed, as virt_to_phys() is a no-op on Atari, unless you start
fiddling with the memory blocks in the bootinfo manually.
Signed-off-by: Geert Uytterhoeven <[email protected]>
---
arch/m68k/kernel/setup_mm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c
index 99cfe0577ad0..5b8ec4d5f8e8 100644
--- a/arch/m68k/kernel/setup_mm.c
+++ b/arch/m68k/kernel/setup_mm.c
@@ -348,12 +348,12 @@ void __init setup_arch(char **cmdline_p)
panic("No configuration setup");
}
+ paging_init();
+
#ifdef CONFIG_NATFEAT
nf_init();
#endif
- paging_init();
-
#ifndef CONFIG_SUN3
for (i = 1; i < m68k_num_memory; i++)
free_bootmem_node(NODE_DATA(i), m68k_memory[i].addr,
--
1.7.9.5
Geert,
does your fiddling with memory blocks in bootinfo now result in kernels
being possible to boot in FastRAM?
Cheers,
Michael
> nf_init() uses virt_to_phys(), which depends on m68k_memoffset being
> set and
> module_fixup() having been called, but this is only done in
> paging_init().
> Hence call paging_init() before nf_init().
>
> This went unnoticed, as virt_to_phys() is a no-op on Atari, unless you
> start
> fiddling with the memory blocks in the bootinfo manually.
>
> Signed-off-by: Geert Uytterhoeven <[email protected]>
> ---
> arch/m68k/kernel/setup_mm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c
> index 99cfe0577ad0..5b8ec4d5f8e8 100644
> --- a/arch/m68k/kernel/setup_mm.c
> +++ b/arch/m68k/kernel/setup_mm.c
> @@ -348,12 +348,12 @@ void __init setup_arch(char **cmdline_p)
> panic("No configuration setup");
> }
>
> + paging_init();
> +
> #ifdef CONFIG_NATFEAT
> nf_init();
> #endif
>
> - paging_init();
> -
> #ifndef CONFIG_SUN3
> for (i = 1; i < m68k_num_memory; i++)
> free_bootmem_node(NODE_DATA(i), m68k_memory[i].addr,
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k"
> in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Oct 18, 2013 at 9:29 AM, Michael Schmitz
<[email protected]> wrote:
> does your fiddling with memory blocks in bootinfo now result in kernels
> being possible to boot in FastRAM?
No, I only played with the start address of ST-RAM.
Probably you can run a kernel in FastRAM with some minor tweaks if
you remove the ST-RAM block from the bootinfo, but then you loose
(at least) atafb :-)
With the DISCONTIGMEM memory model, the kernel must be stored in the
first memory block. As ST-RAM is before FastRAM in memory, you cannot
have the kernel in FastRAM without losing ST-RAM (as main memory ---
you can still e.g. ioremap() it for atafb, and use the rest of it as
swap through
a block device like z2ram. This is basically what we do on Amiga with Chip RAM
and Z2 RAM).
With the SPARSEMEM memory model, you should be able to store the kernel
in FastRAM and have ST-RAM, too.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Hi Geert,
> On Fri, Oct 18, 2013 at 9:29 AM, Michael Schmitz
> <[email protected]> wrote:
>> does your fiddling with memory blocks in bootinfo now result in
>> kernels
>> being possible to boot in FastRAM?
>
> No, I only played with the start address of ST-RAM.
>
> Probably you can run a kernel in FastRAM with some minor tweaks if
> you remove the ST-RAM block from the bootinfo, but then you loose
> (at least) atafb :-)
That, plus eventual ST-RAM bounce buffers for SCSI (which has been
broken on my Falcon for a long time).
>
> With the DISCONTIGMEM memory model, the kernel must be stored in the
> first memory block. As ST-RAM is before FastRAM in memory, you cannot
> have the kernel in FastRAM without losing ST-RAM (as main memory ---
> you can still e.g. ioremap() it for atafb, and use the rest of it as
> swap through
> a block device like z2ram. This is basically what we do on Amiga with
> Chip RAM
> and Z2 RAM).
As long as we can ioremap() the ST-RAM frame buffer, we ought to be
fine in the first instance. How useful ST-RAM as swap may be is
debatable so I'd leave that aside for now.
Main benefits would be for users of TTs that have been left out with
recent kernel sizes.
OK - how would I go about ioremaping a chunk of ST-RAM when that has
been left out of the mm setup because it violates the discontigmem
layout rules? Set up a kernel private mapping for all of ST-RAM, and
make that available to the stram allocator?
> With the SPARSEMEM memory model, you should be able to store the kernel
> in FastRAM and have ST-RAM, too.
I can still remember the headache I got when last playing with the mm
code, I think I'll pass.
Cheers,
Michael
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> [email protected]
>
> In personal conversations with technical people, I call myself a
> hacker. But
> when I'm talking to journalists I just say "programmer" or something
> like that.
> -- Linus Torvalds
On Sat, Oct 19, 2013 at 2:33 AM, Michael Schmitz
<[email protected]> wrote:
>> With the DISCONTIGMEM memory model, the kernel must be stored in the
>> first memory block. As ST-RAM is before FastRAM in memory, you cannot
>> have the kernel in FastRAM without losing ST-RAM (as main memory ---
>> you can still e.g. ioremap() it for atafb, and use the rest of it as
>> swap through
>> a block device like z2ram. This is basically what we do on Amiga with Chip
>> RAM
>> and Z2 RAM).
>
> As long as we can ioremap() the ST-RAM frame buffer, we ought to be fine in
> the first instance. How useful ST-RAM as swap may be is debatable so I'd
> leave that aside for now.
>
> Main benefits would be for users of TTs that have been left out with recent
> kernel sizes.
>
> OK - how would I go about ioremaping a chunk of ST-RAM when that has been
> left out of the mm setup because it violates the discontigmem layout rules?
> Set up a kernel private mapping for all of ST-RAM, and make that available
> to the stram allocator?
Just call ioremap(), that takes care of the kernel private mapping.
ioremap() is meant to map anything that is not part of the mm setup.
>> With the SPARSEMEM memory model, you should be able to store the kernel
>> in FastRAM and have ST-RAM, too.
>
> I can still remember the headache I got when last playing with the mm code,
> I think I'll pass.
But "we" probably have to do that anyway, to please the Amiga BigRAM users.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds