Re: [PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled

[Greg Ungerer <gregungerer@westnet.com.au>]

[-- Attachment #1: Type: text/plain, Size: 7074 bytes --]

Hi Angelo,

I have attached a patch with a slightly different approach to
fixing this. Can you try this one out?

I have a feel for what is going on, based in particular on
the changes you made in 0002-m68k-fix-mmu-for-coldfire-mcf5441x.patch.
I see that the virt_node_shift and accessing pg_data_map when
not 0 based is going to be problematic with the code as it is.


On 02/09/17 08:08, Angelo Dureghello wrote:
> about my patch sent yesterday, unfortunately, i found btw
> at least 1 issue: the busybox "cd" doesn't change directory :)
> 
> / # cat /proc/vmallocinfo
> 0xd0006000-0xd000c000   24576 n_tty_open+0x16/0xae pages=2 vmalloc
> / # ls
> bin    etc    lib    mnt    proc   sbin   usr
> dev    home   media  opt    root   sys    var
> / # cd bin
> / # ls
> bin    etc    lib    mnt    proc   sbin   usr
> dev    home   media  opt    root   sys    var
> / # cat /proc/vm
> vmallocinfo  vmstat
> / # cat /proc/vm
> vmallocinfo  vmstat
> / # cat /proc/vmallocinfo
> 0xd0000000-0xd0006000   24576 unpurged vm_area
> 0xd0006000-0xd000c000   24576 n_tty_open+0x16/0xae pages=2 vmalloc
> 
> And after each "cd" attempt, another "unpurged" message is added.
> Removing MMU cd works as expected.

I setup a configuration with my 5475 where I moved the build
RAM base to be 32MB - so it was no longer 0 based. Then I could run
some tests to at least simulate what you have on the 54411. (The
only catch is my code could still access 0 and surrounding memory
addresses without faulting...)

Running with my attached patch I didn't see any odd behavior with
cd/ls like you see above.

Geert: interested if you have any thoughts on problems around
       virt_to_node_shift. Changing CONFIG_RAMBASE I don't think is
       going to resolve the problem in m68k_setup_node(). We access
       of the end of the array since it was divided up based on the
       size of the RAM, but we access it using an index derrived
       directly from the absolute address.


> On 01/09/2017 15:30, Geert Uytterhoeven wrote:
>> Hi Greg,
>>
>> On Fri, Sep 1, 2017 at 3:21 PM, Greg Ungerer <gregungerer@westnet.com.au> wrote:
>>> On 01/09/17 17:49, Geert Uytterhoeven wrote:
>>>> On Fri, Sep 1, 2017 at 12:38 AM, Angelo Dureghello <angelo@sysam.it>
>>>> wrote:
>>>>> did some additional study and tests.
>>>>>
>>>>> Actually i cannot find any simpler patch, i just adjusted it a
>>>>> bit. I believe this patch will work on your cpu with 0-based
>>>>> memoryas well.
>>>>> I attach it for your comments.
>>>>
>>>>
>>>> I think your issue is caused by arch/m68k/include/asm/page_offset.h:
>>>>
>>>>       #if defined(CONFIG_RAMBASE)
>>>>       #define PAGE_OFFSET_RAW         CONFIG_RAMBASE
>>>>       #elif defined(CONFIG_SUN3)
>>>>       #define PAGE_OFFSET_RAW         0x0E000000
>>>>       #else
>>>>       #define PAGE_OFFSET_RAW         0x00000000
>>>>       #endif
>>>>
>>>> and arch/m68k/Kconfig.machine:
>>>>
>>>> if !MMU || COLDFIRE
>>>>
>>>>       config RAMBASE
>>>>               hex "Address of the base of RAM"
>>>>               default "0"
>>>>
>>>> So on MC680[2346]0 with MMU (and ignoring Sun-3, which is special),
>>>> PAGE_OFFSET == PAGE_OFFSET_RAW == 0.
>>>>
>>>> On Greg's zero-based Coldfire with MMU, CONFIG_RAMBASE is zero, and thus
>>>> PAGE_OFFSET is also zero.
>>>>
>>>> On your board CONFIG_RAMBASE is non-zero, hence PAGE_OFFSET is also
>>>> non-zero,
>>>> and thus you have to compensate for that, cfr. your second patch.
>>>>
>>>> Does it work if you force PAGE_OFFSET_RAW to zero?
>>>>
>>>> If yes, we either need:
>>>>
>>>> --- a/arch/m68k/include/asm/page_offset.h
>>>> +++ b/arch/m68k/include/asm/page_offset.h
>>>> @@ -1,6 +1,6 @@
>>>>    /* This handles the memory map.. */
>>>>
>>>> -#if defined(CONFIG_RAMBASE)
>>>> +#if !defined(CONFIG_MMU)
>>>>    #define PAGE_OFFSET_RAW                CONFIG_RAMBASE
>>>>    #elif defined(CONFIG_SUN3)
>>>>    #define PAGE_OFFSET_RAW                0x0E000000
>>>>
> 
> I tested this patch, (removed mine) and kernel hangs somewhere silently at
> first init, i don't have the debug enabled now, but i suspect it still
> hangs at some initial "memset" since 0 area for kernel should
> be allocated before access.
> 
> Isn't PAGE_OFFSET the starting area for the virtual kernel address space ?
> At least so it seems to be for the famous 3G + 1G of x86.

Well, for the current working ColdFire with MMU that is the case.
The kernel virtual addresses start at 0...


> This is what i see at boot with my patch of yesterday:
> 
> [    0.000000] Virtual kernel memory layout:
> [    0.000000]     vector  : 0x40000000 - 0x40000400   (   1 KiB)
> [    0.000000]     kmap    : 0xe0000000 - 0xf0000000   ( 256 MiB)
> [    0.000000]     vmalloc : 0xd0000000 - 0xe0000000   ( 256 MiB)
> [    0.000000]     lowmem  : 0x40000000 - 0x48000000   ( 128 MiB)
> [    0.000000]       .init : 0x40196000 - 0x401d8000   ( 264 KiB)
> [    0.000000]       .text : 0x40001000 - 0x40131e70   (1220 KiB)
> [    0.000000]       .data : 0x40131e70 - 0x40193900   ( 391 KiB)
> [    0.000000]       .bss  : 0x401d86d8 - 0x401ec680   (  80 KiB)

For whatever it is worth this is what I see now on my debug setup:

Virtual kernel memory layout:
    vector  : 0x02000000 - 0x02000400   (   1 KiB)
    kmap    : 0xe0000000 - 0xf0000000   ( 256 MiB)
    vmalloc : 0xd0000000 - 0xe0000000   ( 256 MiB)
    lowmem  : 0x02000000 - 0x04000000   (  32 MiB)
      .init : 0x02288000 - 0x02296000   (  56 KiB)
      .text : 0x02020000 - 0x0221f270   (2045 KiB)
      .data : 0x0221f270 - 0x02284140   ( 404 KiB)
      .bss  : 0x022967a0 - 0x022ae60c   (  96 KiB)

Regards
Greg



>>>> or
>>>>
>>>> --- a/arch/m68k/Kconfig.machine
>>>> +++ b/arch/m68k/Kconfig.machine
>>>> @@ -325,6 +325,7 @@ comment "RAM configuration"
>>>>
>>>>    config RAMBASE
>>>>           hex "Address of the base of RAM"
>>>> +       depends on MMU
>>>
>>>
>>> Did you mean "depends on !MMU" here?
>>
>> Sorry, yes, depends on !MMU.
>>
>>>> depending on whether anything else in the Coldfire code needs RAMBASE.
>>>
>>> There are a couple of places we depend on CONFIG_RAMBASE even
>>> when running with the MMU enabled. Most importantly in setting
>>> the cachable regions in arch/m68k/include/asm/m54xxacr.h.
>>> So this is probably not going to work on its own.
>>
>> OK, as I already feared/expected...
>>
>>> But the first patch above should be ok. It should certainly work on
>>> my 0 address base 5475 ColdFire setup. Angelo can you try that one?
>>
>> Right.
>>
>> Gr{oetje,eeting}s,
>>
>>                          Geert
>>
>> -- 
>> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>>
>> 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
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 
> Regards,
> Angelo
> 


[-- Attachment #2: cf-virt-node-shift.patch --]
[-- Type: text/x-patch, Size: 471 bytes --]

diff --git a/arch/m68k/mm/mcfmmu.c b/arch/m68k/mm/mcfmmu.c
index 87131cd..6e63d24 100644
--- a/arch/m68k/mm/mcfmmu.c
+++ b/arch/m68k/mm/mcfmmu.c
@@ -169,7 +187,7 @@ void __init cf_bootmem_alloc(void)
 	max_pfn = max_low_pfn = PFN_DOWN(_ramend);
 	high_memory = (void *)_ramend;
 
-	m68k_virt_to_node_shift = fls(_ramend - _rambase - 1) - 6;
+	m68k_virt_to_node_shift = fls(_ramend - 1) - 6;
 	module_fixup(NULL, __start_fixup, __stop_fixup);
 
 	/* setup bootmem data */