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

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

[Angelo Dureghello]

Hi Greg,

The Freescale ColdFire M5441x system-on-chip parts have full paged MMU
hardware support. So far though we have only allowed them to be
configured for use in non-MMU mode.

All required kernel changes to support operation of the M5441x parts
with MMU enabled have been pushed into the kernel, so now we can allow
it to be configured and used with the MMU enabled.

I don't actually have any M5441x based hardware so I can't do any real
testing on this. The changes up to now were based on Yannick Gicquel
initial patches to support this. Is anybody out there able to test
this properly?  I won't push this any further until we have some
confirmation that it all works as expected.

Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
---
  arch/m68k/Kconfig.cpu | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu
index d2219f30..4dc51c0 100644
--- a/arch/m68k/Kconfig.cpu
+++ b/arch/m68k/Kconfig.cpu
@@ -283,7 +283,7 @@ config M548x
  
  config M5441x
  	bool "MCF5441x"
-	depends on !MMU
+	select MMU_COLDFIRE if MMU
  	select GENERIC_CLOCKEVENTS
  	select HAVE_CACHE_CB
  	help
-- 
1.9.1


I tested the patch on my mcf54415 based board, get silence after u-boot at kernel execution


U-Boot 2017.05-00709-g9d9f074dfe-dirty (Jul 14 2017 - 01:11:57 +0200)

CPU:   Freescale MCF54410 (Mask:9f Version:2)
        CPU CLK 240 MHz BUS CLK 120 MHz FLB CLK 60 MHz
        INP CLK 30 MHz VCO CLK 480 MHz
SPI:   ready
DRAM:  128 MiB
SF: Detected is25lp128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
SF: Detected is25lp128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
device 0 offset 0x100000, size 0x1d9720
SF: 1939232 bytes @ 0x100000 Read: OK
## Booting kernel from Legacy Image at 40001000 ...
    Image Name:   mainline kernel
    Created:      2017-07-14  22:46:07 UTC
    Image Type:   M68K Linux Kernel Image (uncompressed)
    Data Size:    1939168 Bytes = 1.8 MiB
    Load Address: 40001000
    Entry Point:  40001000
    Verifying Checksum ... OK
    Loading Kernel Image ... OK

--- silence, kernel execution hangs here ---


Regards,
Angelo Dureghello



--
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
[prev in list] [next in list] [prev in thread] [next in thread]

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

[Angelo Dureghello]

Hi Greg,

On 15/07/2017 01:21, Angelo Dureghello wrote:
> Hi Greg,
> 
> The Freescale ColdFire M5441x system-on-chip parts have full paged MMU
> hardware support. So far though we have only allowed them to be
> configured for use in non-MMU mode.
> 
> All required kernel changes to support operation of the M5441x parts
> with MMU enabled have been pushed into the kernel, so now we can allow
> it to be configured and used with the MMU enabled.
> 
> I don't actually have any M5441x based hardware so I can't do any real
> testing on this. The changes up to now were based on Yannick Gicquel
> initial patches to support this. Is anybody out there able to test
> this properly?  I won't push this any further until we have some
> confirmation that it all works as expected.
> 
> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
> ---
>   arch/m68k/Kconfig.cpu | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu
> index d2219f30..4dc51c0 100644
> --- a/arch/m68k/Kconfig.cpu
> +++ b/arch/m68k/Kconfig.cpu
> @@ -283,7 +283,7 @@ config M548x
> 
>   config M5441x
>       bool "MCF5441x"
> -    depends on !MMU
> +    select MMU_COLDFIRE if MMU
>       select GENERIC_CLOCKEVENTS
>       select HAVE_CACHE_CB
>       help

forgot some useful info on my test:

- i built a 4.12 kernel from mainline (just pulled git master) and tested
to boot properly as no-mmu

- i have those entries in my defconfig:
....
CONFIG_BINFMT_FLAT=y
CONFIG_BINFMT_ZFLAT=y
CONFIG_BINFMT_SHARED_FLAT=y
CONFIG_BINFMT_MISC=y
....


I can help on debug when back from holidays, in 3 weeks.

Regards,
Angelo Dureghello

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

[Greg Ungerer]

Hi Angelo,

On 15/07/17 09:47, Angelo Dureghello wrote:
> On 15/07/2017 01:21, Angelo Dureghello wrote:
>> The Freescale ColdFire M5441x system-on-chip parts have full paged MMU
>> hardware support. So far though we have only allowed them to be
>> configured for use in non-MMU mode.
>>
>> All required kernel changes to support operation of the M5441x parts
>> with MMU enabled have been pushed into the kernel, so now we can allow
>> it to be configured and used with the MMU enabled.
>>
>> I don't actually have any M5441x based hardware so I can't do any real
>> testing on this. The changes up to now were based on Yannick Gicquel
>> initial patches to support this. Is anybody out there able to test
>> this properly?  I won't push this any further until we have some
>> confirmation that it all works as expected.
>>
>> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
>> ---
>>   arch/m68k/Kconfig.cpu | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu
>> index d2219f30..4dc51c0 100644
>> --- a/arch/m68k/Kconfig.cpu
>> +++ b/arch/m68k/Kconfig.cpu
>> @@ -283,7 +283,7 @@ config M548x
>>
>>   config M5441x
>>       bool "MCF5441x"
>> -    depends on !MMU
>> +    select MMU_COLDFIRE if MMU
>>       select GENERIC_CLOCKEVENTS
>>       select HAVE_CACHE_CB
>>       help
> 
> forgot some useful info on my test:
> 
> - i built a 4.12 kernel from mainline (just pulled git master) and tested
> to boot properly as no-mmu
> 
> - i have those entries in my defconfig:
> ....
> CONFIG_BINFMT_FLAT=y
> CONFIG_BINFMT_ZFLAT=y
> CONFIG_BINFMT_SHARED_FLAT=y
> CONFIG_BINFMT_MISC=y
> ....
> 
> 
> I can help on debug when back from holidays, in 3 weeks.

Thanks for trying this out.

Let me know when you have some time to debug further.
First up I would like to know what your RAM setup looks like.
Is it mapped from a base address of 0?
What is the RAM size?

Regards
Greg

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

[Angelo Dureghello]

Hi Greg,

On 09/08/2017 15:04, Greg Ungerer wrote:
> Hi Angelo,
> 
> On 15/07/17 09:47, Angelo Dureghello wrote:
>> On 15/07/2017 01:21, Angelo Dureghello wrote:
>>> The Freescale ColdFire M5441x system-on-chip parts have full paged MMU
>>> hardware support. So far though we have only allowed them to be
>>> configured for use in non-MMU mode.
>>>
>>> All required kernel changes to support operation of the M5441x parts
>>> with MMU enabled have been pushed into the kernel, so now we can allow
>>> it to be configured and used with the MMU enabled.
>>>
>>> I don't actually have any M5441x based hardware so I can't do any real
>>> testing on this. The changes up to now were based on Yannick Gicquel
>>> initial patches to support this. Is anybody out there able to test
>>> this properly?  I won't push this any further until we have some
>>> confirmation that it all works as expected.
>>>
>>> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
>>> ---
>>>   arch/m68k/Kconfig.cpu | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu
>>> index d2219f30..4dc51c0 100644
>>> --- a/arch/m68k/Kconfig.cpu
>>> +++ b/arch/m68k/Kconfig.cpu
>>> @@ -283,7 +283,7 @@ config M548x
>>>
>>>   config M5441x
>>>       bool "MCF5441x"
>>> -    depends on !MMU
>>> +    select MMU_COLDFIRE if MMU
>>>       select GENERIC_CLOCKEVENTS
>>>       select HAVE_CACHE_CB
>>>       help
>>
>> forgot some useful info on my test:
>>
>> - i built a 4.12 kernel from mainline (just pulled git master) and tested
>> to boot properly as no-mmu
>>
>> - i have those entries in my defconfig:
>> ....
>> CONFIG_BINFMT_FLAT=y
>> CONFIG_BINFMT_ZFLAT=y
>> CONFIG_BINFMT_SHARED_FLAT=y
>> CONFIG_BINFMT_MISC=y
>> ....
>>
>>
>> I can help on debug when back from holidays, in 3 weeks.
> 
> Thanks for trying this out.
> 
> Let me know when you have some time to debug further.
> First up I would like to know what your RAM setup looks like.
> Is it mapped from a base address of 0?
> What is the RAM size?
> 

sure, on this board  http://sysam.it/cff_stmark2.html
there are 128MB of ddr2.

External SDRAM is accessible, at least without any mmc support enabled,
from 0x40000000.

I have following test config:

   GNU nano 2.8.6                                                                              File: arch/m68k/configs/stmark2_defconfig

CONFIG_LOCALVERSION="stmark2-001"
CONFIG_DEFAULT_HOSTNAME="stmark2"
CONFIG_SYSVIPC=y
# CONFIG_FHANDLE is not set
CONFIG_LOG_BUF_SHIFT=14
CONFIG_NAMESPACES=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE="../uClinux-dist/romfs"
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
# CONFIG_AIO is not set
# CONFIG_ADVISE_SYSCALLS is not set
# CONFIG_MEMBARRIER is not set
CONFIG_EMBEDDED=y
# CONFIG_VM_EVENT_COUNTERS is not set
# CONFIG_COMPAT_BRK is not set
# CONFIG_LBDAF is not set
# CONFIG_BLK_DEV_BSG is not set
CONFIG_BLK_CMDLINE_PARSER=y
CONFIG_COLDFIRE=y
CONFIG_M5441x=y
CONFIG_CLOCK_FREQ=240000000
CONFIG_STMARK2=y
CONFIG_RAMBASE=0x40000000
CONFIG_RAMSIZE=0x8000000
CONFIG_VECTORBASE=0x40000000
CONFIG_KERNELBASE=0x40001000
CONFIG_BINFMT_FLAT=y
CONFIG_BINFMT_ZFLAT=y
CONFIG_BINFMT_SHARED_FLAT=y
CONFIG_BINFMT_MISC=y
# CONFIG_UEVENT_HELPER is not set
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y
# CONFIG_ALLOW_DEV_COREDUMP is not set
CONFIG_MTD=y
CONFIG_MTD_CMDLINE_PARTS=y
CONFIG_MTD_BLOCK=y
CONFIG_FTL=y
CONFIG_MTD_CFI=y
CONFIG_MTD_JEDECPROBE=y
CONFIG_MTD_CFI_ADV_OPTIONS=y
CONFIG_MTD_CFI_LE_BYTE_SWAP=y
CONFIG_MTD_CFI_GEOMETRY=y
# CONFIG_MTD_CFI_I2 is not set
CONFIG_MTD_CFI_AMDSTD=y
CONFIG_MTD_CFI_STAA=y
CONFIG_MTD_ROM=y
CONFIG_MTD_COMPLEX_MAPPINGS=y
CONFIG_MTD_PHYSMAP=y
CONFIG_MTD_PLATRAM=y
CONFIG_MTD_SPI_NOR=y
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_UNIX98_PTYS is not set
# CONFIG_DEVMEM is not set
CONFIG_SERIAL_MCF=y
CONFIG_SERIAL_MCF_BAUDRATE=115200
CONFIG_SERIAL_MCF_CONSOLE=y
# CONFIG_HW_RANDOM is not set
CONFIG_SPI=y
# CONFIG_HWMON is not set
# CONFIG_HID is not set
# CONFIG_USB_SUPPORT is not set
# CONFIG_FILE_LOCKING is not set
# CONFIG_DNOTIFY is not set
# CONFIG_INOTIFY_USER is not set
CONFIG_FSCACHE=y
# CONFIG_PROC_SYSCTL is not set
CONFIG_PRINTK_TIME=y
# CONFIG_ENABLE_WARN_DEPRECATED is not set
# CONFIG_SECTION_MISMATCH_WARN_ONLY is not set
CONFIG_PANIC_ON_OOPS=y
# CONFIG_SCHED_DEBUG is not set
# CONFIG_DEBUG_BUGVERBOSE is not set
CONFIG_BOOTPARAM=y
CONFIG_BOOTPARAM_STRING="console=ttyS0,115200 root=/dev/ram0 rw rootfstype=ramfs rdinit=/bin/init devtmpfs.mount=1"
CONFIG_CRYPTO=y
# CONFIG_CRYPTO_ECHAINIV is not set
CONFIG_CRYPTO_ANSI_CPRNG=y
# CONFIG_CRYPTO_HW is not set
CONFIG_CRC16=y


I tried still yesterday a bit, but seems there is no much support for
earlyprintk / low level debug for this architecture.

In case i can try with a gpio toggling routine, at least to find
where kernel stops.


> Regards
> Greg
> -- 
> 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

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

[Greg Ungerer]

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

Hi Angelo,

On 10/08/17 01:32, Angelo Dureghello wrote:
[snip]
> sure, on this board  http://sysam.it/cff_stmark2.html
> there are 128MB of ddr2.
> 
> External SDRAM is accessible, at least without any mmc support enabled,
> from 0x40000000.
> 
> I have following test config:
> 
>   GNU nano 2.8.6                                                                              File: arch/m68k/configs/stmark2_defconfig
> 
> CONFIG_LOCALVERSION="stmark2-001"
[snip]
> 
> 
> I tried still yesterday a bit, but seems there is no much support for
> earlyprintk / low level debug for this architecture.
> 
> In case i can try with a gpio toggling routine, at least to find
> where kernel stops.

The attached patch, is a quick and dirty early console output method.
It works for me on the m5475, should work for you "as is" on the 5441x too.

It is kind of an early printk. Of course it still needs the early
kernel boot to have succeeded before you will get anything much coming out.
But it is worth trying.

I am wondering if the non-0 base RAM may be a problem. I have only run
the MMU enabled code on platforms with 0 based RAM so far. But lets see if
the early console trace attached gives us anything before digging into that.

Regards
Greg

[-- Attachment #2: console.patch --]
[-- Type: text/x-patch, Size: 1372 bytes --]

diff --git a/drivers/tty/serial/mcf.c b/drivers/tty/serial/mcf.c
index 02eb322..58b854e 100644
--- a/drivers/tty/serial/mcf.c
+++ b/drivers/tty/serial/mcf.c
@@ -568,6 +568,30 @@ static int __init mcf_console_setup(struct console *co, char *options)
 
 /****************************************************************************/
 
+static void putrawch(char c)
+{
+	unsigned int membase = MCFUART_BASE0;
+	int i;
+
+	for (i = 0; (i < 0x10000); i++) {
+		if (readb(membase + MCFUART_USR) & MCFUART_USR_TXREADY)
+			break;
+	}
+	writeb(c, membase + MCFUART_UTB);
+	for (i = 0; (i < 0x10000); i++) {
+		if (readb(membase + MCFUART_USR) & MCFUART_USR_TXREADY)
+			break;
+	}
+}
+
+void printraw(const char *s)
+{
+	for (; *s != 0; s++)
+		putrawch(*s);
+}
+
+/****************************************************************************/
+
 static struct uart_driver mcf_driver;
 
 static struct console mcf_console = {
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 2984fb0..39e62d1 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -1721,6 +1721,8 @@ asmlinkage int vprintk_emit(int facility, int level,
 	 */
 	text_len = vscnprintf(text, sizeof(textbuf), fmt, args);
 
+	{ extern void printraw(const char *); printraw(text); }
+
 	/* mark and strip a trailing newline */
 	if (text_len && text[text_len-1] == '\n') {
 		text_len--;

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

[Angelo Dureghello]

Hi Greg,

On 10/08/2017 09:06, Greg Ungerer wrote:
> Hi Angelo,
> 
> On 10/08/17 01:32, Angelo Dureghello wrote:
> [snip]
>> sure, on this board  http://sysam.it/cff_stmark2.html
>> there are 128MB of ddr2.
>>
>> External SDRAM is accessible, at least without any mmc support enabled,
>> from 0x40000000.
>>
>> I have following test config:
>>
>>    GNU nano 2.8.6                                                                              File: arch/m68k/configs/stmark2_defconfig
>>
>> CONFIG_LOCALVERSION="stmark2-001"
> [snip]
>>
>>
>> I tried still yesterday a bit, but seems there is no much support for
>> earlyprintk / low level debug for this architecture.
>>
>> In case i can try with a gpio toggling routine, at least to find
>> where kernel stops.
> 
> The attached patch, is a quick and dirty early console output method.
> It works for me on the m5475, should work for you "as is" on the 5441x too.
> 
> It is kind of an early printk. Of course it still needs the early
> kernel boot to have succeeded before you will get anything much coming out.
> But it is worth trying.

Ok many thanks. Btw i used a __square(); function written in asm, so i am
sure i see the gpio toggling in very early stages.

> 
> I am wondering if the non-0 base RAM may be a problem. I have only run
> the MMU enabled code on platforms with 0 based RAM so far. But lets see if
> the early console trace attached gives us anything before digging into that.
> 

This MCU has sdram area physically mapped at 0x4000 0000 so U-Boot, to be
able to execute the kernel must load it to that location/area anyway.

But i have seen that it is not a problem, after MMU is enabled in head.S
the jump
         
         movel   #_vstart,%a0      /* jump to "virtual" space */
         jmp     %a0@

works fine. Since that range is not hitting anything that is maintained
physical, it can be translated into virtual without any issue.

After some hard debug, i see the execution stops at:

asmlinkage __visible void __init start_kernel(void)
    ...
    setup_arch(&command_line);      setup_mm.c
       ...
       paging_init();               mm/mcfmmu.c
          ...
          empty_zero_page = (void *) alloc_bootmem_pages(PAGE_SIZE);
          ^line 47 mcfmmu.c

Inside alloc_bootmem_pages(), execution seems to end up finally to
mm/bootmem.c and likely to alloc_bootmem_bdata().
In case i can still proceed to find the exact place where execution stops,
but i suspect in the while(1), line 545.

As a curious thing, i find in a different cf CPU code "m54xx.c"
the following:

void __init config_BSP(char *commandp, int size)
{
#ifdef CONFIG_MMU
	cf_bootmem_alloc();
	mmu_context_init();
#endif
	
Do also m5441x.c maybe need this calls ?

Would be very nice to have MMU working. Strangely, i don't see any
board_config with it enabled. Was it ever tested on some Coldfire ?
Waiting your suggestion on how to proceed.

Regards,
Angelo Dureghello
  

> Regards
> Greg
> 

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

[Angelo Dureghello]

Hi greg,

On 10/08/2017 09:06, Greg Ungerer wrote:
> Hi Angelo,
> 
> On 10/08/17 01:32, Angelo Dureghello wrote:
> [snip]
>> sure, on this board  http://sysam.it/cff_stmark2.html
>> there are 128MB of ddr2.
>>
>> External SDRAM is accessible, at least without any mmc support enabled,
>> from 0x40000000.
>>
>> I have following test config:
>>
>>    GNU nano 2.8.6                                                                              File: arch/m68k/configs/stmark2_defconfig
>>
>> CONFIG_LOCALVERSION="stmark2-001"
> [snip]
>>
>>
>> I tried still yesterday a bit, but seems there is no much support for
>> earlyprintk / low level debug for this architecture.
>>
>> In case i can try with a gpio toggling routine, at least to find
>> where kernel stops.
> 
> The attached patch, is a quick and dirty early console output method.
> It works for me on the m5475, should work for you "as is" on the 5441x too.
> 
> It is kind of an early printk. Of course it still needs the early
> kernel boot to have succeeded before you will get anything much coming out.
> But it is worth trying.
> 
> I am wondering if the non-0 base RAM may be a problem. I have only run
> the MMU enabled code on platforms with 0 based RAM so far. But lets see if
> the early console trace attached gives us anything before digging into that.
>

I have some news, found the exact point where the kernel stops,
it is a " panic("Out of memory");" but you can check
the comments in the diff below to see what exactly happen:

iff --git a/mm/bootmem.c b/mm/bootmem.c
index 9fedb27c6451..2bf51bf1bf28 100644
--- a/mm/bootmem.c
+++ b/mm/bootmem.c
@@ -20,6 +20,8 @@
  
  #include "internal.h"
  
+extern void __square(void);
+
  #ifndef CONFIG_NEED_MULTIPLE_NODES
  struct pglist_data __refdata contig_page_data = {
         .bdata = &bootmem_node_data[0]
@@ -501,6 +503,8 @@ static void * __init alloc_bootmem_bdata(struct bootmem_data *bdata,
         unsigned long fallback = 0;
         unsigned long min, max, start, sidx, midx, step;
  
+       /* we don't even enter here */
+
         bdebug("nid=%td size=%lx [%lu pages] align=%lx goal=%lx limit=%lx\n",
                 bdata - bootmem_node_data, size, PAGE_ALIGN(size) >> PAGE_SHIFT,
                 align, goal, limit);
@@ -539,6 +543,7 @@ static void * __init alloc_bootmem_bdata(struct bootmem_data *bdata,
                  * catch the fallback below.
                  */
                 fallback = sidx + 1;
+
                 sidx = align_idx(bdata, bdata->hint_idx, step);
         }
  
@@ -609,12 +614,18 @@ static void * __init alloc_bootmem_core(unsigned long size,
         bootmem_data_t *bdata;
         void *region;
  
+       /* we pass from here */
         if (WARN_ON_ONCE(slab_is_available()))
                 return kzalloc(size, GFP_NOWAIT);
  
+       /* we pass from here */
         list_for_each_entry(bdata, &bdata_list, list) {
+
+               /* we never enter here */
+
                 if (goal && bdata->node_low_pfn <= PFN_DOWN(goal))
                         continue;
+
                 if (limit && bdata->node_min_pfn >= PFN_DOWN(limit))
                         break;
  
@@ -623,6 +634,8 @@ static void * __init alloc_bootmem_core(unsigned long size,
                         return region;
         }
  
+       /* we pass from here */
+
         return NULL;
  }
  
@@ -637,11 +650,18 @@ static void * __init ___alloc_bootmem_nopanic(unsigned long size,
         ptr = alloc_bootmem_core(size, align, goal, limit);
         if (ptr)
                 return ptr;
+
+       /* alloc_bootmem_core returns null, ptr = 0 */
+
         if (goal) {
                 goal = 0;
                 goto restart;
+
+               /* we pass from here yes */
         }
  
+       /* we pass from here yes */
+
         return NULL;
  }
  
@@ -677,7 +697,10 @@ static void * __init ___alloc_bootmem(unsigned long size, unsigned long align,
          * Whoops, we cannot satisfy the allocation request.
          */
         pr_alert("bootmem alloc of %lu bytes failed!\n", size);
+
+       /* we finally stop here */
         panic("Out of memory");
+
         return NULL;
  }


So trying now to understand why that

list_for_each_entry(bdata, &bdata_list, list)

looks as an emtty list.

Regards,
Angelo



> Regards
> Greg
> 

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

[Greg Ungerer]

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

Hi Angelo,

On 12/08/17 21:17, Angelo Dureghello wrote:
> On 10/08/2017 09:06, Greg Ungerer wrote:
>> On 10/08/17 01:32, Angelo Dureghello wrote:
>> [snip]
>>> sure, on this board  http://sysam.it/cff_stmark2.html
>>> there are 128MB of ddr2.
>>>
>>> External SDRAM is accessible, at least without any mmc support enabled,
>>> from 0x40000000.
>>>
>>> I have following test config:
>>>
>>>    GNU nano 2.8.6                                                                              File: arch/m68k/configs/stmark2_defconfig
>>>
>>> CONFIG_LOCALVERSION="stmark2-001"
>> [snip]
>>>
>>>
>>> I tried still yesterday a bit, but seems there is no much support for
>>> earlyprintk / low level debug for this architecture.
>>>
>>> In case i can try with a gpio toggling routine, at least to find
>>> where kernel stops.
>>
>> The attached patch, is a quick and dirty early console output method.
>> It works for me on the m5475, should work for you "as is" on the 5441x too.
>>
>> It is kind of an early printk. Of course it still needs the early
>> kernel boot to have succeeded before you will get anything much coming out.
>> But it is worth trying.
> 
> Ok many thanks. Btw i used a __square(); function written in asm, so i am
> sure i see the gpio toggling in very early stages.
> 
>>
>> I am wondering if the non-0 base RAM may be a problem. I have only run
>> the MMU enabled code on platforms with 0 based RAM so far. But lets see if
>> the early console trace attached gives us anything before digging into that.
>>
> 
> This MCU has sdram area physically mapped at 0x4000 0000 so U-Boot, to be
> able to execute the kernel must load it to that location/area anyway.
> 
> But i have seen that it is not a problem, after MMU is enabled in head.S
> the jump
>                 movel   #_vstart,%a0      /* jump to "virtual" space */
>         jmp     %a0@
> 
> works fine. Since that range is not hitting anything that is maintained
> physical, it can be translated into virtual without any issue.

Yeah, it is not so much the initial start up that I think will
be the problem. More the setup of the MMU mapping tables later
in boot.


> After some hard debug, i see the execution stops at:
> 
> asmlinkage __visible void __init start_kernel(void)
>    ...
>    setup_arch(&command_line);      setup_mm.c
>       ...
>       paging_init();               mm/mcfmmu.c
>          ...
>          empty_zero_page = (void *) alloc_bootmem_pages(PAGE_SIZE);
>          ^line 47 mcfmmu.c
> 
> Inside alloc_bootmem_pages(), execution seems to end up finally to
> mm/bootmem.c and likely to alloc_bootmem_bdata().
> In case i can still proceed to find the exact place where execution stops,
> but i suspect in the while(1), line 545.
> 
> As a curious thing, i find in a different cf CPU code "m54xx.c"
> the following:
> 
> void __init config_BSP(char *commandp, int size)
> {
> #ifdef CONFIG_MMU
>     cf_bootmem_alloc();
>     mmu_context_init();
> #endif
>     
> Do also m5441x.c maybe need this calls ?

Yes, you will need this. So that code above is only getting run when
configured for a 547x CPU family. Attached is a rework of that code
so that it will be run for all ColdFire MMU varients. Can you try
that out?


> Would be very nice to have MMU working. Strangely, i don't see any
> board_config with it enabled. Was it ever tested on some Coldfire ?

Oh, yeah, I run this on a real M5475 EVB board for every kernel
mainline release, with and without MMU enabled. See the
arch/m68k/configs/m5475evb_defconfig, it will default to having
the MMU enabled.

I have todays linux-4.13-rc5 running on it here now:

# cat /proc/version
Linux version 4.13.0-rc5-00001-gb014090-dirty (gerg@goober) (gcc version 5.4.0 (GCC)) #1 Mon Aug 14 10:14:12 AEST 2017

# cat /proc/cpuinfo
CPU:            ColdFire
MMU:            ColdFire
FPU:            ColdFire
Clocking:       264.1MHz
BogoMips:       264.19
Calibration:    1320960 loops
# 

Regards
Greg

[-- Attachment #2: cf-mmu-init.patch --]
[-- Type: text/x-patch, Size: 2951 bytes --]

diff --git a/arch/m68k/coldfire/m54xx.c b/arch/m68k/coldfire/m54xx.c
index c552851..704efea 100644
--- a/arch/m68k/coldfire/m54xx.c
+++ b/arch/m68k/coldfire/m54xx.c
@@ -95,10 +95,6 @@ static void mcf54xx_reset(void)
 
 void __init config_BSP(char *commandp, int size)
 {
-#ifdef CONFIG_MMU
-	cf_bootmem_alloc();
-	mmu_context_init();
-#endif
 	mach_reset = mcf54xx_reset;
 	mach_sched_init = hw_timer_init;
 	m54xx_uarts_init();
diff --git a/arch/m68k/include/asm/mmu_context.h b/arch/m68k/include/asm/mmu_context.h
index 4a6ae6d..00c28b1 100644
--- a/arch/m68k/include/asm/mmu_context.h
+++ b/arch/m68k/include/asm/mmu_context.h
@@ -91,7 +91,6 @@ static inline void activate_mm(struct mm_struct *active_mm,
 
 #define deactivate_mm(tsk, mm) do { } while (0)
 
-extern void mmu_context_init(void);
 #define prepare_arch_switch(next) load_ksp_mmu(next)
 
 static inline void load_ksp_mmu(struct task_struct *task)
diff --git a/arch/m68k/kernel/setup_mm.c b/linux/arch/m68k/kernel/setup_mm.c
index 7a2c212..5632c48 100644
--- a/arch/m68k/kernel/setup_mm.c
+++ b/arch/m68k/kernel/setup_mm.c
@@ -343,6 +343,7 @@ void __init setup_arch(char **cmdline_p)
 #ifdef CONFIG_COLDFIRE
 	case MACH_M54XX:
 	case MACH_M5441X:
+		cf_bootmem_alloc();
 		config_BSP(NULL, 0);
 		break;
 #endif
diff --git a/arch/m68k/mm/mcfmmu.c b/arch/m68k/mm/mcfmmu.c
index 87131cd..d09a317 100644
--- a/arch/m68k/mm/mcfmmu.c
+++ b/arch/m68k/mm/mcfmmu.c
@@ -150,6 +150,24 @@ int cf_tlb_miss(struct pt_regs *regs, int write, int dtlb, int extension_word)
 	return 0;
 }
 
+/*
+ * Initialize the context management stuff.
+ * The following was taken from arch/ppc/mmu_context.c
+ */
+static void __init mmu_context_init(void)
+{
+	/*
+	 * Some processors have too few contexts to reserve one for
+	 * init_mm, and require using context 0 for a normal task.
+	 * Other processors reserve the use of context zero for the kernel.
+	 * This code assumes FIRST_CONTEXT < 32.
+	 */
+	context_map[0] = (1 << FIRST_CONTEXT) - 1;
+	next_mmu_context = FIRST_CONTEXT;
+	atomic_set(&nr_free_contexts, LAST_CONTEXT - FIRST_CONTEXT + 1);
+}
+
+
 void __init cf_bootmem_alloc(void)
 {
 	unsigned long start_pfn;
@@ -177,23 +195,8 @@ void __init cf_bootmem_alloc(void)
 	memstart += init_bootmem_node(NODE_DATA(0), start_pfn,
 		min_low_pfn, max_low_pfn);
 	free_bootmem_node(NODE_DATA(0), memstart, _ramend - memstart);
-}
 
-/*
- * Initialize the context management stuff.
- * The following was taken from arch/ppc/mmu_context.c
- */
-void __init mmu_context_init(void)
-{
-	/*
-	 * Some processors have too few contexts to reserve one for
-	 * init_mm, and require using context 0 for a normal task.
-	 * Other processors reserve the use of context zero for the kernel.
-	 * This code assumes FIRST_CONTEXT < 32.
-	 */
-	context_map[0] = (1 << FIRST_CONTEXT) - 1;
-	next_mmu_context = FIRST_CONTEXT;
-	atomic_set(&nr_free_contexts, LAST_CONTEXT - FIRST_CONTEXT + 1);
+	mmu_context_init();
 }
 
 /*

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

[Angelo Dureghello]

Hi Greg,

On 14/08/2017 06:16, Greg Ungerer wrote:
> Hi Angelo,
> 
> On 12/08/17 21:17, Angelo Dureghello wrote:
>> On 10/08/2017 09:06, Greg Ungerer wrote:
>>> On 10/08/17 01:32, Angelo Dureghello wrote:
>>> [snip]
>>>> sure, on this board  http://sysam.it/cff_stmark2.html
>>>> there are 128MB of ddr2.
>>>>
>>>> External SDRAM is accessible, at least without any mmc support enabled,
>>>> from 0x40000000.
>>>>
>>>> I have following test config:
>>>>
>>>>     GNU nano 2.8.6                                                                              File: arch/m68k/configs/stmark2_defconfig
>>>>
>>>> CONFIG_LOCALVERSION="stmark2-001"
>>> [snip]
>>>>
>>>>
>>>> I tried still yesterday a bit, but seems there is no much support for
>>>> earlyprintk / low level debug for this architecture.
>>>>
>>>> In case i can try with a gpio toggling routine, at least to find
>>>> where kernel stops.
>>>
>>> The attached patch, is a quick and dirty early console output method.
>>> It works for me on the m5475, should work for you "as is" on the 5441x too.
>>>
>>> It is kind of an early printk. Of course it still needs the early
>>> kernel boot to have succeeded before you will get anything much coming out.
>>> But it is worth trying.
>>
>> Ok many thanks. Btw i used a __square(); function written in asm, so i am
>> sure i see the gpio toggling in very early stages.
>>
>>>
>>> I am wondering if the non-0 base RAM may be a problem. I have only run
>>> the MMU enabled code on platforms with 0 based RAM so far. But lets see if
>>> the early console trace attached gives us anything before digging into that.
>>>
>>
>> This MCU has sdram area physically mapped at 0x4000 0000 so U-Boot, to be
>> able to execute the kernel must load it to that location/area anyway.
>>
>> But i have seen that it is not a problem, after MMU is enabled in head.S
>> the jump
>>                  movel   #_vstart,%a0      /* jump to "virtual" space */
>>          jmp     %a0@
>>
>> works fine. Since that range is not hitting anything that is maintained
>> physical, it can be translated into virtual without any issue.
> 
> Yeah, it is not so much the initial start up that I think will
> be the problem. More the setup of the MMU mapping tables later
> in boot.
> 
> 
>> After some hard debug, i see the execution stops at:
>>
>> asmlinkage __visible void __init start_kernel(void)
>>     ...
>>     setup_arch(&command_line);      setup_mm.c
>>        ...
>>        paging_init();               mm/mcfmmu.c
>>           ...
>>           empty_zero_page = (void *) alloc_bootmem_pages(PAGE_SIZE);
>>           ^line 47 mcfmmu.c
>>
>> Inside alloc_bootmem_pages(), execution seems to end up finally to
>> mm/bootmem.c and likely to alloc_bootmem_bdata().
>> In case i can still proceed to find the exact place where execution stops,
>> but i suspect in the while(1), line 545.
>>
>> As a curious thing, i find in a different cf CPU code "m54xx.c"
>> the following:
>>
>> void __init config_BSP(char *commandp, int size)
>> {
>> #ifdef CONFIG_MMU
>>      cf_bootmem_alloc();
>>      mmu_context_init();
>> #endif
>>      
>> Do also m5441x.c maybe need this calls ?
> 
> Yes, you will need this. So that code above is only getting run when
> configured for a 547x CPU family. Attached is a rework of that code
> so that it will be run for all ColdFire MMU varients. Can you try
> that out?
> 
> 
>> Would be very nice to have MMU working. Strangely, i don't see any
>> board_config with it enabled. Was it ever tested on some Coldfire ?
> 
> Oh, yeah, I run this on a real M5475 EVB board for every kernel
> mainline release, with and without MMU enabled. See the
> arch/m68k/configs/m5475evb_defconfig, it will default to having
> the MMU enabled.
> 
> I have todays linux-4.13-rc5 running on it here now:
> 
> # cat /proc/version
> Linux version 4.13.0-rc5-00001-gb014090-dirty (gerg@goober) (gcc version 5.4.0 (GCC)) #1 Mon Aug 14 10:14:12 AEST 2017
> 
> # cat /proc/cpuinfo
> CPU:            ColdFire
> MMU:            ColdFire
> FPU:            ColdFire
> Clocking:       264.1MHz
> BogoMips:       264.19
> Calibration:    1320960 loops
> #
> 
> Regards
> Greg

Ok, i applied your patch, and still the kernel is hanging silently,
so i started up a new debug session again.

What is actually happening (after your patch has been applied) is:

setup_arch()                arch/m68k/kernel/setup_mm.c
  paging_init()
memmap_init()               mm/page_alloc.c
memmap_init_zone()
  __init_single_page()
      set_page_links()       include/linux/mm.h
         set_page_zone()
           kernel hangs silently on this line
           page->flags &= ~(ZONES_MASK << ZONES_PGSHIFT);

> 

I am wondering how mmu works, so at the moment mmu is enabled,
in head.S, i would expect that code compiled for 0x40001000 would
not run, since jumps would be translated to some different physical
addresses, but execution sill works.
At the same, after enabling mmu i would expect .data vars to be
invalid, since their address would be translated to a different
location, while not, the init values of .data variables are still
valid. In case, i am interested to understand this points.


Regards,
Angelo

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

[Greg Ungerer]

Hi Angelo,

On 18/08/17 01:02, Angelo Dureghello wrote:
> On 14/08/2017 06:16, Greg Ungerer wrote:
>> On 12/08/17 21:17, Angelo Dureghello wrote:
>>> On 10/08/2017 09:06, Greg Ungerer wrote:
>>>> On 10/08/17 01:32, Angelo Dureghello wrote:
>>>> [snip]
>>>>> sure, on this board  http://sysam.it/cff_stmark2.html
>>>>> there are 128MB of ddr2.
>>>>>
>>>>> External SDRAM is accessible, at least without any mmc support 
>>>>> enabled,
>>>>> from 0x40000000.
>>>>>
>>>>> I have following test config:
>>>>>
>>>>>     GNU nano 
>>>>> 2.8.6                                                                              
>>>>> File: arch/m68k/configs/stmark2_defconfig
>>>>>
>>>>> CONFIG_LOCALVERSION="stmark2-001"
>>>> [snip]
>>>>>
>>>>>
>>>>> I tried still yesterday a bit, but seems there is no much support for
>>>>> earlyprintk / low level debug for this architecture.
>>>>>
>>>>> In case i can try with a gpio toggling routine, at least to find
>>>>> where kernel stops.
>>>>
>>>> The attached patch, is a quick and dirty early console output method.
>>>> It works for me on the m5475, should work for you "as is" on the 
>>>> 5441x too.
>>>>
>>>> It is kind of an early printk. Of course it still needs the early
>>>> kernel boot to have succeeded before you will get anything much 
>>>> coming out.
>>>> But it is worth trying.
>>>
>>> Ok many thanks. Btw i used a __square(); function written in asm, so 
>>> i am
>>> sure i see the gpio toggling in very early stages.
>>>
>>>>
>>>> I am wondering if the non-0 base RAM may be a problem. I have only run
>>>> the MMU enabled code on platforms with 0 based RAM so far. But lets 
>>>> see if
>>>> the early console trace attached gives us anything before digging 
>>>> into that.
>>>>
>>>
>>> This MCU has sdram area physically mapped at 0x4000 0000 so U-Boot, 
>>> to be
>>> able to execute the kernel must load it to that location/area anyway.
>>>
>>> But i have seen that it is not a problem, after MMU is enabled in head.S
>>> the jump
>>>                  movel   #_vstart,%a0      /* jump to "virtual" space */
>>>          jmp     %a0@
>>>
>>> works fine. Since that range is not hitting anything that is maintained
>>> physical, it can be translated into virtual without any issue.
>>
>> Yeah, it is not so much the initial start up that I think will
>> be the problem. More the setup of the MMU mapping tables later
>> in boot.
>>
>>
>>> After some hard debug, i see the execution stops at:
>>>
>>> asmlinkage __visible void __init start_kernel(void)
>>>     ...
>>>     setup_arch(&command_line);      setup_mm.c
>>>        ...
>>>        paging_init();               mm/mcfmmu.c
>>>           ...
>>>           empty_zero_page = (void *) alloc_bootmem_pages(PAGE_SIZE);
>>>           ^line 47 mcfmmu.c
>>>
>>> Inside alloc_bootmem_pages(), execution seems to end up finally to
>>> mm/bootmem.c and likely to alloc_bootmem_bdata().
>>> In case i can still proceed to find the exact place where execution 
>>> stops,
>>> but i suspect in the while(1), line 545.
>>>
>>> As a curious thing, i find in a different cf CPU code "m54xx.c"
>>> the following:
>>>
>>> void __init config_BSP(char *commandp, int size)
>>> {
>>> #ifdef CONFIG_MMU
>>>      cf_bootmem_alloc();
>>>      mmu_context_init();
>>> #endif
>>> Do also m5441x.c maybe need this calls ?
>>
>> Yes, you will need this. So that code above is only getting run when
>> configured for a 547x CPU family. Attached is a rework of that code
>> so that it will be run for all ColdFire MMU varients. Can you try
>> that out?
>>
>>
>>> Would be very nice to have MMU working. Strangely, i don't see any
>>> board_config with it enabled. Was it ever tested on some Coldfire ?
>>
>> Oh, yeah, I run this on a real M5475 EVB board for every kernel
>> mainline release, with and without MMU enabled. See the
>> arch/m68k/configs/m5475evb_defconfig, it will default to having
>> the MMU enabled.
>>
>> I have todays linux-4.13-rc5 running on it here now:
>>
>> # cat /proc/version
>> Linux version 4.13.0-rc5-00001-gb014090-dirty (gerg@goober) (gcc 
>> version 5.4.0 (GCC)) #1 Mon Aug 14 10:14:12 AEST 2017
>>
>> # cat /proc/cpuinfo
>> CPU:            ColdFire
>> MMU:            ColdFire
>> FPU:            ColdFire
>> Clocking:       264.1MHz
>> BogoMips:       264.19
>> Calibration:    1320960 loops
>> #
>>
>> Regards
>> Greg
> 
> Ok, i applied your patch, and still the kernel is hanging silently,
> so i started up a new debug session again.
> 
> What is actually happening (after your patch has been applied) is:
> 
> setup_arch()                arch/m68k/kernel/setup_mm.c
>   paging_init()
> memmap_init()               mm/page_alloc.c
> memmap_init_zone()
>   __init_single_page()
>       set_page_links()       include/linux/mm.h
>          set_page_zone()
>            kernel hangs silently on this line
>            page->flags &= ~(ZONES_MASK << ZONES_PGSHIFT);
> 
>>
> 
> I am wondering how mmu works, so at the moment mmu is enabled,
> in head.S, i would expect that code compiled for 0x40001000 would
> not run, since jumps would be translated to some different physical
> addresses, but execution sill works.
> At the same, after enabling mmu i would expect .data vars to be
> invalid, since their address would be translated to a different
> location, while not, the init values of .data variables are still
> valid. In case, i am interested to understand this points.

On the ColdFire the kernel relies on all RAM and IO peripheral
addresses) to "hit" the ACR registers - and essentially be passed
through as an identity physical = virtual mapping. If you look at
the operation of the memory address translation when virtual mode
is enabled (in the ColdFire MMU sections of the 5475 and 54411
reference manual) you will see that addresses are checked in order
to be for the MMUBAR, RAMBAR, ACR, then MMU.

For example a kernel address when in supervisor mode will hit
ACR1 or ACR3 the way we set them up in arch/m68k/coldfire/head.S.
And that is why you see kernel code and data still being valid after
the MMU is enabled in virtual mode. No TLB entries required for this.

Looking at your call sequence above I can see that the physical
RAM start address being non-zero is going to come into play. I'll
dig into this a little more tomorrow see if I can figure out what
is going on.

Regards
Greg

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

[Angelo Dureghello]

Hi Greg,

On 20/08/2017 14:44, Greg Ungerer wrote:
> Hi Angelo,
> 
> On 18/08/17 01:02, Angelo Dureghello wrote:
>> On 14/08/2017 06:16, Greg Ungerer wrote:
>>> On 12/08/17 21:17, Angelo Dureghello wrote:
>>>> On 10/08/2017 09:06, Greg Ungerer wrote:
>>>>> On 10/08/17 01:32, Angelo Dureghello wrote:
>>>>> [snip]
>>>>>> sure, on this board  http://sysam.it/cff_stmark2.html
>>>>>> there are 128MB of ddr2.
>>>>>>
>>>>>> External SDRAM is accessible, at least without any mmc support enabled,
>>>>>> from 0x40000000.
>>>>>>
>>>>>> I have following test config:
>>>>>>
>>>>>>     GNU nano 2.8.6 File: arch/m68k/configs/stmark2_defconfig
>>>>>>
>>>>>> CONFIG_LOCALVERSION="stmark2-001"
>>>>> [snip]
>>>>>>
>>>>>>
>>>>>> I tried still yesterday a bit, but seems there is no much support for
>>>>>> earlyprintk / low level debug for this architecture.
>>>>>>
>>>>>> In case i can try with a gpio toggling routine, at least to find
>>>>>> where kernel stops.
>>>>>
>>>>> The attached patch, is a quick and dirty early console output method.
>>>>> It works for me on the m5475, should work for you "as is" on the 5441x too.
>>>>>
>>>>> It is kind of an early printk. Of course it still needs the early
>>>>> kernel boot to have succeeded before you will get anything much coming out.
>>>>> But it is worth trying.
>>>>
>>>> Ok many thanks. Btw i used a __square(); function written in asm, so i am
>>>> sure i see the gpio toggling in very early stages.
>>>>
>>>>>
>>>>> I am wondering if the non-0 base RAM may be a problem. I have only run
>>>>> the MMU enabled code on platforms with 0 based RAM so far. But lets see if
>>>>> the early console trace attached gives us anything before digging into that.
>>>>>
>>>>
>>>> This MCU has sdram area physically mapped at 0x4000 0000 so U-Boot, to be
>>>> able to execute the kernel must load it to that location/area anyway.
>>>>
>>>> But i have seen that it is not a problem, after MMU is enabled in head.S
>>>> the jump
>>>>                  movel   #_vstart,%a0      /* jump to "virtual" space */
>>>>          jmp     %a0@
>>>>
>>>> works fine. Since that range is not hitting anything that is maintained
>>>> physical, it can be translated into virtual without any issue.
>>>
>>> Yeah, it is not so much the initial start up that I think will
>>> be the problem. More the setup of the MMU mapping tables later
>>> in boot.
>>>
>>>
>>>> After some hard debug, i see the execution stops at:
>>>>
>>>> asmlinkage __visible void __init start_kernel(void)
>>>>     ...
>>>>     setup_arch(&command_line);      setup_mm.c
>>>>        ...
>>>>        paging_init();               mm/mcfmmu.c
>>>>           ...
>>>>           empty_zero_page = (void *) alloc_bootmem_pages(PAGE_SIZE);
>>>>           ^line 47 mcfmmu.c
>>>>
>>>> Inside alloc_bootmem_pages(), execution seems to end up finally to
>>>> mm/bootmem.c and likely to alloc_bootmem_bdata().
>>>> In case i can still proceed to find the exact place where execution stops,
>>>> but i suspect in the while(1), line 545.
>>>>
>>>> As a curious thing, i find in a different cf CPU code "m54xx.c"
>>>> the following:
>>>>
>>>> void __init config_BSP(char *commandp, int size)
>>>> {
>>>> #ifdef CONFIG_MMU
>>>>      cf_bootmem_alloc();
>>>>      mmu_context_init();
>>>> #endif
>>>> Do also m5441x.c maybe need this calls ?
>>>
>>> Yes, you will need this. So that code above is only getting run when
>>> configured for a 547x CPU family. Attached is a rework of that code
>>> so that it will be run for all ColdFire MMU varients. Can you try
>>> that out?
>>>
>>>
>>>> Would be very nice to have MMU working. Strangely, i don't see any
>>>> board_config with it enabled. Was it ever tested on some Coldfire ?
>>>
>>> Oh, yeah, I run this on a real M5475 EVB board for every kernel
>>> mainline release, with and without MMU enabled. See the
>>> arch/m68k/configs/m5475evb_defconfig, it will default to having
>>> the MMU enabled.
>>>
>>> I have todays linux-4.13-rc5 running on it here now:
>>>
>>> # cat /proc/version
>>> Linux version 4.13.0-rc5-00001-gb014090-dirty (gerg@goober) (gcc version 5.4.0 (GCC)) #1 Mon Aug 14 10:14:12 AEST 2017
>>>
>>> # cat /proc/cpuinfo
>>> CPU:            ColdFire
>>> MMU:            ColdFire
>>> FPU:            ColdFire
>>> Clocking:       264.1MHz
>>> BogoMips:       264.19
>>> Calibration:    1320960 loops
>>> #
>>>
>>> Regards
>>> Greg
>>
>> Ok, i applied your patch, and still the kernel is hanging silently,
>> so i started up a new debug session again.
>>
>> What is actually happening (after your patch has been applied) is:
>>
>> setup_arch()                arch/m68k/kernel/setup_mm.c
>>   paging_init()
>> memmap_init()               mm/page_alloc.c
>> memmap_init_zone()
>>   __init_single_page()
>>       set_page_links()       include/linux/mm.h
>>          set_page_zone()
>>            kernel hangs silently on this line
>>            page->flags &= ~(ZONES_MASK << ZONES_PGSHIFT);
>>
>>>
>>
>> I am wondering how mmu works, so at the moment mmu is enabled,
>> in head.S, i would expect that code compiled for 0x40001000 would
>> not run, since jumps would be translated to some different physical
>> addresses, but execution sill works.
>> At the same, after enabling mmu i would expect .data vars to be
>> invalid, since their address would be translated to a different
>> location, while not, the init values of .data variables are still
>> valid. In case, i am interested to understand this points.
> 
> On the ColdFire the kernel relies on all RAM and IO peripheral
> addresses) to "hit" the ACR registers - and essentially be passed
> through as an identity physical = virtual mapping. If you look at
> the operation of the memory address translation when virtual mode
> is enabled (in the ColdFire MMU sections of the 5475 and 54411
> reference manual) you will see that addresses are checked in order
> to be for the MMUBAR, RAMBAR, ACR, then MMU.
> 
> For example a kernel address when in supervisor mode will hit
> ACR1 or ACR3 the way we set them up in arch/m68k/coldfire/head.S.
> And that is why you see kernel code and data still being valid after
> the MMU is enabled in virtual mode. No TLB entries required for this.
> 
> Looking at your call sequence above I can see that the physical
> RAM start address being non-zero is going to come into play. I'll
> dig into this a little more tomorrow see if I can figure out what
> is going on.
> 

Thanks for the kind clarifications.

I'll look in this things too in next days, learning is always nice.
Btw, about load/entry address, i have noticed a possible basic
difference betweeen mcf5441x and mcf547x series:

The second one (your cpu) is v4e and probably more recent i guess, and
one major difference from datasheet seems to be that it is Harvard.
So probably, for this reason, you can address ram from 0 there.

> Regards
> Greg
> 
> 
Reagrds
Angelo
> 
> 
> 

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

[Greg Ungerer]

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

Hi Angelo,

On 20/08/17 23:26, Angelo Dureghello wrote:
> On 20/08/2017 14:44, Greg Ungerer wrote:
>> On 18/08/17 01:02, Angelo Dureghello wrote:
>>> On 14/08/2017 06:16, Greg Ungerer wrote:
>>>> On 12/08/17 21:17, Angelo Dureghello wrote:
>>>>> On 10/08/2017 09:06, Greg Ungerer wrote:
>>>>>> On 10/08/17 01:32, Angelo Dureghello wrote:
>>>>>> [snip]
>>>>>>> sure, on this board  http://sysam.it/cff_stmark2.html
>>>>>>> there are 128MB of ddr2.
>>>>>>>
>>>>>>> External SDRAM is accessible, at least without any mmc support enabled,
>>>>>>> from 0x40000000.
>>>>>>>
>>>>>>> I have following test config:
>>>>>>>
>>>>>>>     GNU nano 2.8.6 File: arch/m68k/configs/stmark2_defconfig
>>>>>>>
>>>>>>> CONFIG_LOCALVERSION="stmark2-001"
>>>>>> [snip]
>>>>>>>
>>>>>>>
>>>>>>> I tried still yesterday a bit, but seems there is no much support for
>>>>>>> earlyprintk / low level debug for this architecture.
>>>>>>>
>>>>>>> In case i can try with a gpio toggling routine, at least to find
>>>>>>> where kernel stops.
>>>>>>
>>>>>> The attached patch, is a quick and dirty early console output method.
>>>>>> It works for me on the m5475, should work for you "as is" on the 5441x too.
>>>>>>
>>>>>> It is kind of an early printk. Of course it still needs the early
>>>>>> kernel boot to have succeeded before you will get anything much coming out.
>>>>>> But it is worth trying.
>>>>>
>>>>> Ok many thanks. Btw i used a __square(); function written in asm, so i am
>>>>> sure i see the gpio toggling in very early stages.
>>>>>
>>>>>>
>>>>>> I am wondering if the non-0 base RAM may be a problem. I have only run
>>>>>> the MMU enabled code on platforms with 0 based RAM so far. But lets see if
>>>>>> the early console trace attached gives us anything before digging into that.
>>>>>>
>>>>>
>>>>> This MCU has sdram area physically mapped at 0x4000 0000 so U-Boot, to be
>>>>> able to execute the kernel must load it to that location/area anyway.
>>>>>
>>>>> But i have seen that it is not a problem, after MMU is enabled in head.S
>>>>> the jump
>>>>>                  movel   #_vstart,%a0      /* jump to "virtual" space */
>>>>>          jmp     %a0@
>>>>>
>>>>> works fine. Since that range is not hitting anything that is maintained
>>>>> physical, it can be translated into virtual without any issue.
>>>>
>>>> Yeah, it is not so much the initial start up that I think will
>>>> be the problem. More the setup of the MMU mapping tables later
>>>> in boot.
>>>>
>>>>
>>>>> After some hard debug, i see the execution stops at:
>>>>>
>>>>> asmlinkage __visible void __init start_kernel(void)
>>>>>     ...
>>>>>     setup_arch(&command_line);      setup_mm.c
>>>>>        ...
>>>>>        paging_init();               mm/mcfmmu.c
>>>>>           ...
>>>>>           empty_zero_page = (void *) alloc_bootmem_pages(PAGE_SIZE);
>>>>>           ^line 47 mcfmmu.c
>>>>>
>>>>> Inside alloc_bootmem_pages(), execution seems to end up finally to
>>>>> mm/bootmem.c and likely to alloc_bootmem_bdata().
>>>>> In case i can still proceed to find the exact place where execution stops,
>>>>> but i suspect in the while(1), line 545.
>>>>>
>>>>> As a curious thing, i find in a different cf CPU code "m54xx.c"
>>>>> the following:
>>>>>
>>>>> void __init config_BSP(char *commandp, int size)
>>>>> {
>>>>> #ifdef CONFIG_MMU
>>>>>      cf_bootmem_alloc();
>>>>>      mmu_context_init();
>>>>> #endif
>>>>> Do also m5441x.c maybe need this calls ?
>>>>
>>>> Yes, you will need this. So that code above is only getting run when
>>>> configured for a 547x CPU family. Attached is a rework of that code
>>>> so that it will be run for all ColdFire MMU varients. Can you try
>>>> that out?
>>>>
>>>>
>>>>> Would be very nice to have MMU working. Strangely, i don't see any
>>>>> board_config with it enabled. Was it ever tested on some Coldfire ?
>>>>
>>>> Oh, yeah, I run this on a real M5475 EVB board for every kernel
>>>> mainline release, with and without MMU enabled. See the
>>>> arch/m68k/configs/m5475evb_defconfig, it will default to having
>>>> the MMU enabled.
>>>>
>>>> I have todays linux-4.13-rc5 running on it here now:
>>>>
>>>> # cat /proc/version
>>>> Linux version 4.13.0-rc5-00001-gb014090-dirty (gerg@goober) (gcc version 5.4.0 (GCC)) #1 Mon Aug 14 10:14:12 AEST 2017
>>>>
>>>> # cat /proc/cpuinfo
>>>> CPU:            ColdFire
>>>> MMU:            ColdFire
>>>> FPU:            ColdFire
>>>> Clocking:       264.1MHz
>>>> BogoMips:       264.19
>>>> Calibration:    1320960 loops
>>>> #
>>>>
>>>> Regards
>>>> Greg
>>>
>>> Ok, i applied your patch, and still the kernel is hanging silently,
>>> so i started up a new debug session again.
>>>
>>> What is actually happening (after your patch has been applied) is:
>>>
>>> setup_arch()                arch/m68k/kernel/setup_mm.c
>>>   paging_init()
>>> memmap_init()               mm/page_alloc.c
>>> memmap_init_zone()
>>>   __init_single_page()
>>>       set_page_links()       include/linux/mm.h
>>>          set_page_zone()
>>>            kernel hangs silently on this line
>>>            page->flags &= ~(ZONES_MASK << ZONES_PGSHIFT);
>>>
>>>>
>>>

Can you run your current code with the console debug code I sent
a little while back?

I ask because I suspect it should give something based on your debug
above. I played around a little trying to fake out my configuration
to make it look like the RAM was non-zero based. I couldn't get a fail,
but I would like to add some more debug to see what is going on with
the page pointers from your debug.

Can you apply the attached patch and get any extra debug?


>>> I am wondering how mmu works, so at the moment mmu is enabled,
>>> in head.S, i would expect that code compiled for 0x40001000 would
>>> not run, since jumps would be translated to some different physical
>>> addresses, but execution sill works.
>>> At the same, after enabling mmu i would expect .data vars to be
>>> invalid, since their address would be translated to a different
>>> location, while not, the init values of .data variables are still
>>> valid. In case, i am interested to understand this points.
>>
>> On the ColdFire the kernel relies on all RAM and IO peripheral
>> addresses) to "hit" the ACR registers - and essentially be passed
>> through as an identity physical = virtual mapping. If you look at
>> the operation of the memory address translation when virtual mode
>> is enabled (in the ColdFire MMU sections of the 5475 and 54411
>> reference manual) you will see that addresses are checked in order
>> to be for the MMUBAR, RAMBAR, ACR, then MMU.
>>
>> For example a kernel address when in supervisor mode will hit
>> ACR1 or ACR3 the way we set them up in arch/m68k/coldfire/head.S.
>> And that is why you see kernel code and data still being valid after
>> the MMU is enabled in virtual mode. No TLB entries required for this.
>>
>> Looking at your call sequence above I can see that the physical
>> RAM start address being non-zero is going to come into play. I'll
>> dig into this a little more tomorrow see if I can figure out what
>> is going on.
>>
> 
> Thanks for the kind clarifications.
> 
> I'll look in this things too in next days, learning is always nice.
> Btw, about load/entry address, i have noticed a possible basic
> difference betweeen mcf5441x and mcf547x series:
> 
> The second one (your cpu) is v4e and probably more recent i guess, and
> one major difference from datasheet seems to be that it is Harvard.
> So probably, for this reason, you can address ram from 0 there.

IIRC the 5475 was the first ColdFire with MMU, it is pretty old. Pretty
sure the 54411 came later. Not sure what the thinking was on the different
default memory layout though.

Regards
Greg



[-- Attachment #2: page-trace.patch --]
[-- Type: text/x-patch, Size: 493 bytes --]

diff --git a/linux/mm/page_alloc.c b/linux/mm/page_alloc.c
index a2019fc..38bafc9 100644
--- a/linux/mm/page_alloc.c
+++ b/linux/mm/page_alloc.c
@@ -1178,6 +1178,7 @@ static void free_one_page(struct zone *zone,
 static void __meminit __init_single_page(struct page *page, unsigned long pfn,
 				unsigned long zone, int nid)
 {
+	printk("%s(%d): page=%p pfn=%ld\n", __FILE__, __LINE__, page, pfn);
 	set_page_links(page, zone, nid, pfn);
 	init_page_count(page);
 	page_mapcount_reset(page);

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

[Angelo Dureghello]

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

Hi Greg,

On 21/08/2017 09:15, Greg Ungerer wrote:
> Hi Angelo,
> 
> On 20/08/17 23:26, Angelo Dureghello wrote:
>> On 20/08/2017 14:44, Greg Ungerer wrote:
>>> On 18/08/17 01:02, Angelo Dureghello wrote:
>>>> On 14/08/2017 06:16, Greg Ungerer wrote:
>>>>> On 12/08/17 21:17, Angelo Dureghello wrote:
>>>>>> On 10/08/2017 09:06, Greg Ungerer wrote:
>>>>>>> On 10/08/17 01:32, Angelo Dureghello wrote:
>>>>>>> [snip]
>>>>>>>> sure, on this board  http://sysam.it/cff_stmark2.html
>>>>>>>> there are 128MB of ddr2.
>>>>>>>>
>>>>>>>> External SDRAM is accessible, at least without any mmc support enabled,
>>>>>>>> from 0x40000000.
>>>>>>>>
>>>>>>>> I have following test config:
>>>>>>>>
>>>>>>>>      GNU nano 2.8.6 File: arch/m68k/configs/stmark2_defconfig
>>>>>>>>
>>>>>>>> CONFIG_LOCALVERSION="stmark2-001"
>>>>>>> [snip]
>>>>>>>>
>>>>>>>>
>>>>>>>> I tried still yesterday a bit, but seems there is no much support for
>>>>>>>> earlyprintk / low level debug for this architecture.
>>>>>>>>
>>>>>>>> In case i can try with a gpio toggling routine, at least to find
>>>>>>>> where kernel stops.
>>>>>>>
>>>>>>> The attached patch, is a quick and dirty early console output method.
>>>>>>> It works for me on the m5475, should work for you "as is" on the 5441x too.
>>>>>>>
>>>>>>> It is kind of an early printk. Of course it still needs the early
>>>>>>> kernel boot to have succeeded before you will get anything much coming out.
>>>>>>> But it is worth trying.
>>>>>>
>>>>>> Ok many thanks. Btw i used a __square(); function written in asm, so i am
>>>>>> sure i see the gpio toggling in very early stages.
>>>>>>
>>>>>>>
>>>>>>> I am wondering if the non-0 base RAM may be a problem. I have only run
>>>>>>> the MMU enabled code on platforms with 0 based RAM so far. But lets see if
>>>>>>> the early console trace attached gives us anything before digging into that.
>>>>>>>
>>>>>>
>>>>>> This MCU has sdram area physically mapped at 0x4000 0000 so U-Boot, to be
>>>>>> able to execute the kernel must load it to that location/area anyway.
>>>>>>
>>>>>> But i have seen that it is not a problem, after MMU is enabled in head.S
>>>>>> the jump
>>>>>>                   movel   #_vstart,%a0      /* jump to "virtual" space */
>>>>>>           jmp     %a0@
>>>>>>
>>>>>> works fine. Since that range is not hitting anything that is maintained
>>>>>> physical, it can be translated into virtual without any issue.
>>>>>
>>>>> Yeah, it is not so much the initial start up that I think will
>>>>> be the problem. More the setup of the MMU mapping tables later
>>>>> in boot.
>>>>>
>>>>>
>>>>>> After some hard debug, i see the execution stops at:
>>>>>>
>>>>>> asmlinkage __visible void __init start_kernel(void)
>>>>>>      ...
>>>>>>      setup_arch(&command_line);      setup_mm.c
>>>>>>         ...
>>>>>>         paging_init();               mm/mcfmmu.c
>>>>>>            ...
>>>>>>            empty_zero_page = (void *) alloc_bootmem_pages(PAGE_SIZE);
>>>>>>            ^line 47 mcfmmu.c
>>>>>>
>>>>>> Inside alloc_bootmem_pages(), execution seems to end up finally to
>>>>>> mm/bootmem.c and likely to alloc_bootmem_bdata().
>>>>>> In case i can still proceed to find the exact place where execution stops,
>>>>>> but i suspect in the while(1), line 545.
>>>>>>
>>>>>> As a curious thing, i find in a different cf CPU code "m54xx.c"
>>>>>> the following:
>>>>>>
>>>>>> void __init config_BSP(char *commandp, int size)
>>>>>> {
>>>>>> #ifdef CONFIG_MMU
>>>>>>       cf_bootmem_alloc();
>>>>>>       mmu_context_init();
>>>>>> #endif
>>>>>> Do also m5441x.c maybe need this calls ?
>>>>>
>>>>> Yes, you will need this. So that code above is only getting run when
>>>>> configured for a 547x CPU family. Attached is a rework of that code
>>>>> so that it will be run for all ColdFire MMU varients. Can you try
>>>>> that out?
>>>>>
>>>>>
>>>>>> Would be very nice to have MMU working. Strangely, i don't see any
>>>>>> board_config with it enabled. Was it ever tested on some Coldfire ?
>>>>>
>>>>> Oh, yeah, I run this on a real M5475 EVB board for every kernel
>>>>> mainline release, with and without MMU enabled. See the
>>>>> arch/m68k/configs/m5475evb_defconfig, it will default to having
>>>>> the MMU enabled.
>>>>>
>>>>> I have todays linux-4.13-rc5 running on it here now:
>>>>>
>>>>> # cat /proc/version
>>>>> Linux version 4.13.0-rc5-00001-gb014090-dirty (gerg@goober) (gcc version 5.4.0 (GCC)) #1 Mon Aug 14 10:14:12 AEST 2017
>>>>>
>>>>> # cat /proc/cpuinfo
>>>>> CPU:            ColdFire
>>>>> MMU:            ColdFire
>>>>> FPU:            ColdFire
>>>>> Clocking:       264.1MHz
>>>>> BogoMips:       264.19
>>>>> Calibration:    1320960 loops
>>>>> #
>>>>>
>>>>> Regards
>>>>> Greg
>>>>
>>>> Ok, i applied your patch, and still the kernel is hanging silently,
>>>> so i started up a new debug session again.
>>>>
>>>> What is actually happening (after your patch has been applied) is:
>>>>
>>>> setup_arch()                arch/m68k/kernel/setup_mm.c
>>>>    paging_init()
>>>> memmap_init()               mm/page_alloc.c
>>>> memmap_init_zone()
>>>>    __init_single_page()
>>>>        set_page_links()       include/linux/mm.h
>>>>           set_page_zone()
>>>>             kernel hangs silently on this line
>>>>             page->flags &= ~(ZONES_MASK << ZONES_PGSHIFT);
>>>>
>>>>>
>>>>
> 
> Can you run your current code with the console debug code I sent
> a little while back?
> 
> I ask because I suspect it should give something based on your debug
> above. I played around a little trying to fake out my configuration
> to make it look like the RAM was non-zero based. I couldn't get a fail,
> but I would like to add some more debug to see what is going on with
> the page pointers from your debug.
> 
> Can you apply the attached patch and get any extra debug?
> 

Sure. Done as you required, removed all my debug parts
and just added yours.

Not sure why, but seems there is now a kind of rollback, as the error
now comes again before reaching your printk line. Also some strange
ctrl char is printed at each line begin, in the debug printf.

This is the output:

U-Boot 2017.09-rc2-00136-gf069d2fd3e (Aug 20 2017 - 00:08:11 +0200)

CPU:   Freescale MCF54410 (Mask:9f Version:2)
        CPU CLK 240 MHz BUS CLK 120 MHz FLB CLK 60 MHz
        INP CLK 30 MHz VCO CLK 480 MHz
SPI:   ready
DRAM:  128 MiB
Using default environment

In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
SF: Detected is25lp128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
device 0 offset 0x100000, size 0x700000
SF: 7340032 bytes @ 0x100000 Read: OK
## Booting kernel from Legacy Image at 40001000 ...
    Image Name:   mainline kernel
    Created:      2017-08-21  14:18:52 UTC
    Image Type:   M68K Linux Kernel Image (uncompressed)
    Data Size:    1939176 Bytes = 1.8 MiB
    Load Address: 40001000
    Entry Point:  40001000
    Verifying Checksum ... OK
    Loading Kernel Image ... OK
\x015Linux version 4.12.0stmark2-001-11691-g571d81b2b55f-dirty (angelo@jerusalem) (gcc version 4.9.0 (crosstools-sysam-2016.04.16)) #177 Mon Aug 21 16:18:51 CEST 2017
                                                   \x011bootmem alloc of 8192 bytes failed!
                                                                                        \x010Kernel panic - not syncing: Out of memory
                  \x010---[ end Kernel panic - not syncing: Out of memory


Or better, https://snag.gy/X8y4JM.jpg

I attach my whole current patch.

> 
>>>> I am wondering how mmu works, so at the moment mmu is enabled,
>>>> in head.S, i would expect that code compiled for 0x40001000 would
>>>> not run, since jumps would be translated to some different physical
>>>> addresses, but execution sill works.
>>>> At the same, after enabling mmu i would expect .data vars to be
>>>> invalid, since their address would be translated to a different
>>>> location, while not, the init values of .data variables are still
>>>> valid. In case, i am interested to understand this points.
>>>
>>> On the ColdFire the kernel relies on all RAM and IO peripheral
>>> addresses) to "hit" the ACR registers - and essentially be passed
>>> through as an identity physical = virtual mapping. If you look at
>>> the operation of the memory address translation when virtual mode
>>> is enabled (in the ColdFire MMU sections of the 5475 and 54411
>>> reference manual) you will see that addresses are checked in order
>>> to be for the MMUBAR, RAMBAR, ACR, then MMU.
>>>
>>> For example a kernel address when in supervisor mode will hit
>>> ACR1 or ACR3 the way we set them up in arch/m68k/coldfire/head.S.
>>> And that is why you see kernel code and data still being valid after
>>> the MMU is enabled in virtual mode. No TLB entries required for this.
>>>
>>> Looking at your call sequence above I can see that the physical
>>> RAM start address being non-zero is going to come into play. I'll
>>> dig into this a little more tomorrow see if I can figure out what
>>> is going on.
>>>
>>
>> Thanks for the kind clarifications.
>>
>> I'll look in this things too in next days, learning is always nice.
>> Btw, about load/entry address, i have noticed a possible basic
>> difference betweeen mcf5441x and mcf547x series:
>>
>> The second one (your cpu) is v4e and probably more recent i guess, and
>> one major difference from datasheet seems to be that it is Harvard.
>> So probably, for this reason, you can address ram from 0 there.
> 
> IIRC the 5475 was the first ColdFire with MMU, it is pretty old. Pretty
> sure the 54411 came later. Not sure what the thinking was on the different
> default memory layout though.
> 

Mmm, i was just curiously noticing that 5475 reaches and higher clock speed
as it could be a newer technology. But not important probably.

> Regards
> Greg
> 
> 

Will also look into this later.

Regards,
Angelo

[-- Attachment #2: current_mmu.patch --]
[-- Type: text/x-patch, Size: 5754 bytes --]

diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu
index d2219f30b78f..4dc51c090a45 100644
--- a/arch/m68k/Kconfig.cpu
+++ b/arch/m68k/Kconfig.cpu
@@ -283,7 +283,7 @@ config M548x
 
 config M5441x
 	bool "MCF5441x"
-	depends on !MMU
+	select MMU_COLDFIRE if MMU
 	select GENERIC_CLOCKEVENTS
 	select HAVE_CACHE_CB
 	help
diff --git a/arch/m68k/coldfire/m54xx.c b/arch/m68k/coldfire/m54xx.c
index c552851ec617..704efeaeab2d 100644
--- a/arch/m68k/coldfire/m54xx.c
+++ b/arch/m68k/coldfire/m54xx.c
@@ -95,10 +95,6 @@ static void mcf54xx_reset(void)
 
 void __init config_BSP(char *commandp, int size)
 {
-#ifdef CONFIG_MMU
-	cf_bootmem_alloc();
-	mmu_context_init();
-#endif
 	mach_reset = mcf54xx_reset;
 	mach_sched_init = hw_timer_init;
 	m54xx_uarts_init();
diff --git a/arch/m68k/configs/stmark2_defconfig b/arch/m68k/configs/stmark2_defconfig
index ea78b8f6a68e..b886f303cc3f 100644
--- a/arch/m68k/configs/stmark2_defconfig
+++ b/arch/m68k/configs/stmark2_defconfig
@@ -21,7 +21,7 @@ CONFIG_EMBEDDED=y
 # CONFIG_LBDAF is not set
 # CONFIG_BLK_DEV_BSG is not set
 CONFIG_BLK_CMDLINE_PARSER=y
-# CONFIG_MMU is not set
+CONFIG_COLDFIRE=y
 CONFIG_M5441x=y
 CONFIG_CLOCK_FREQ=240000000
 CONFIG_STMARK2=y
@@ -30,6 +30,8 @@ CONFIG_RAMSIZE=0x8000000
 CONFIG_VECTORBASE=0x40000000
 CONFIG_KERNELBASE=0x40001000
 CONFIG_BINFMT_FLAT=y
+CONFIG_BINFMT_ZFLAT=y
+CONFIG_BINFMT_SHARED_FLAT=y
 CONFIG_BINFMT_MISC=y
 # CONFIG_UEVENT_HELPER is not set
 CONFIG_DEVTMPFS=y
@@ -53,7 +55,6 @@ CONFIG_MTD_COMPLEX_MAPPINGS=y
 CONFIG_MTD_PHYSMAP=y
 CONFIG_MTD_PLATRAM=y
 CONFIG_MTD_SPI_NOR=y
-# CONFIG_INPUT_MOUSEDEV is not set
 # CONFIG_INPUT_KEYBOARD is not set
 # CONFIG_INPUT_MOUSE is not set
 CONFIG_SERIO_LIBPS2=y
diff --git a/arch/m68k/include/asm/mmu_context.h b/arch/m68k/include/asm/mmu_context.h
index 4a6ae6dffa34..00c28b1dc47b 100644
--- a/arch/m68k/include/asm/mmu_context.h
+++ b/arch/m68k/include/asm/mmu_context.h
@@ -91,7 +91,6 @@ static inline void activate_mm(struct mm_struct *active_mm,
 
 #define deactivate_mm(tsk, mm) do { } while (0)
 
-extern void mmu_context_init(void);
 #define prepare_arch_switch(next) load_ksp_mmu(next)
 
 static inline void load_ksp_mmu(struct task_struct *task)
diff --git a/arch/m68k/mm/mcfmmu.c b/arch/m68k/mm/mcfmmu.c
index 87131cd3bc8f..c7efdf8e8eae 100644
--- a/arch/m68k/mm/mcfmmu.c
+++ b/arch/m68k/mm/mcfmmu.c
@@ -150,6 +150,23 @@ int cf_tlb_miss(struct pt_regs *regs, int write, int dtlb, int extension_word)
 	return 0;
 }
 
+/*
+ * Initialize the context management stuff.
+ * The following was taken from arch/ppc/mmu_context.c
+ */
+static void __init mmu_context_init(void)
+{
+	/*
+	 * Some processors have too few contexts to reserve one for
+	 * init_mm, and require using context 0 for a normal task.
+	 * Other processors reserve the use of context zero for the kernel.
+	 * This code assumes FIRST_CONTEXT < 32.
+	 */
+	context_map[0] = (1 << FIRST_CONTEXT) - 1;
+	next_mmu_context = FIRST_CONTEXT;
+	atomic_set(&nr_free_contexts, LAST_CONTEXT - FIRST_CONTEXT + 1);
+}
+
 void __init cf_bootmem_alloc(void)
 {
 	unsigned long start_pfn;
@@ -177,23 +194,7 @@ void __init cf_bootmem_alloc(void)
 	memstart += init_bootmem_node(NODE_DATA(0), start_pfn,
 		min_low_pfn, max_low_pfn);
 	free_bootmem_node(NODE_DATA(0), memstart, _ramend - memstart);
-}
-
-/*
- * Initialize the context management stuff.
- * The following was taken from arch/ppc/mmu_context.c
- */
-void __init mmu_context_init(void)
-{
-	/*
-	 * Some processors have too few contexts to reserve one for
-	 * init_mm, and require using context 0 for a normal task.
-	 * Other processors reserve the use of context zero for the kernel.
-	 * This code assumes FIRST_CONTEXT < 32.
-	 */
-	context_map[0] = (1 << FIRST_CONTEXT) - 1;
-	next_mmu_context = FIRST_CONTEXT;
-	atomic_set(&nr_free_contexts, LAST_CONTEXT - FIRST_CONTEXT + 1);
+	mmu_context_init();
 }
 
 /*
diff --git a/drivers/tty/serial/mcf.c b/drivers/tty/serial/mcf.c
index 02eb32217685..58b854e0713f 100644
--- a/drivers/tty/serial/mcf.c
+++ b/drivers/tty/serial/mcf.c
@@ -568,6 +568,30 @@ static int __init mcf_console_setup(struct console *co, char *options)
 
 /****************************************************************************/
 
+static void putrawch(char c)
+{
+	unsigned int membase = MCFUART_BASE0;
+	int i;
+
+	for (i = 0; (i < 0x10000); i++) {
+		if (readb(membase + MCFUART_USR) & MCFUART_USR_TXREADY)
+			break;
+	}
+	writeb(c, membase + MCFUART_UTB);
+	for (i = 0; (i < 0x10000); i++) {
+		if (readb(membase + MCFUART_USR) & MCFUART_USR_TXREADY)
+			break;
+	}
+}
+
+void printraw(const char *s)
+{
+	for (; *s != 0; s++)
+		putrawch(*s);
+}
+
+/****************************************************************************/
+
 static struct uart_driver mcf_driver;
 
 static struct console mcf_console = {
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index fc47863f629c..880a36d05abe 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -1720,6 +1720,8 @@ asmlinkage int vprintk_emit(int facility, int level,
 	 */
 	text_len = vscnprintf(text, sizeof(textbuf), fmt, args);
 
+	{ extern void printraw(const char *); printraw(text); }
+
 	/* mark and strip a trailing newline */
 	if (text_len && text[text_len-1] == '\n') {
 		text_len--;
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 6d30e914afb6..4a6bdaa118a4 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1168,6 +1168,7 @@ static void free_one_page(struct zone *zone,
 static void __meminit __init_single_page(struct page *page, unsigned long pfn,
 				unsigned long zone, int nid)
 {
+	printk("%s(%d): page=%p pfn=%ld\n", __FILE__, __LINE__, page, pfn);
 	set_page_links(page, zone, nid, pfn);
 	init_page_count(page);
 	page_mapcount_reset(page);

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

[Geert Uytterhoeven]

Hi Angelo,

On Mon, Aug 21, 2017 at 4:58 PM, Angelo Dureghello <angelo@sysam.it> wrote:
> On 21/08/2017 09:15, Greg Ungerer wrote:
>> Can you apply the attached patch and get any extra debug?
>
> Sure. Done as you required, removed all my debug parts
> and just added yours.
>
> Not sure why, but seems there is now a kind of rollback, as the error
> now comes again before reaching your printk line. Also some strange
> ctrl char is printed at each line begin, in the debug printf.

See include/linux/kern_levels.h.

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

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

[Angelo Dureghello]

Hi Geert,

nice to hear you :)

On 21/08/2017 22:11, Geert Uytterhoeven wrote:
> Hi Angelo,
> 
> On Mon, Aug 21, 2017 at 4:58 PM, Angelo Dureghello <angelo@sysam.it> wrote:
>> On 21/08/2017 09:15, Greg Ungerer wrote:
>>> Can you apply the attached patch and get any extra debug?
>>
>> Sure. Done as you required, removed all my debug parts
>> and just added yours.
>>
>> Not sure why, but seems there is now a kind of rollback, as the error
>> now comes again before reaching your printk line. Also some strange
>> ctrl char is printed at each line begin, in the debug printf.
> 
> See include/linux/kern_levels.h.

many thanks, i fixed a bit the debug routine now it is perfect.

> 
> Gr{oetje,eeting}s,
> 
>                          Geert
> 
Regards,
Angelo

> --
> 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
> 

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

[Angelo Dureghello]

Hi Greg,

On 21/08/2017 09:15, Greg Ungerer wrote:
> Hi Angelo,
> 
> On 20/08/17 23:26, Angelo Dureghello wrote:
>> On 20/08/2017 14:44, Greg Ungerer wrote:
>>> On 18/08/17 01:02, Angelo Dureghello wrote:
>>>> On 14/08/2017 06:16, Greg Ungerer wrote:
>>>>> On 12/08/17 21:17, Angelo Dureghello wrote:
>>>>>> On 10/08/2017 09:06, Greg Ungerer wrote:
>>>>>>> On 10/08/17 01:32, Angelo Dureghello wrote:
>>>>>>> [snip]
>>>>>>>> sure, on this board  http://sysam.it/cff_stmark2.html
>>>>>>>> there are 128MB of ddr2.
>>>>>>>>
>>>>>>>> External SDRAM is accessible, at least without any mmc support enabled,
>>>>>>>> from 0x40000000.
>>>>>>>>
>>>>>>>> I have following test config:
>>>>>>>>
>>>>>>>>      GNU nano 2.8.6 File: arch/m68k/configs/stmark2_defconfig
>>>>>>>>
>>>>>>>> CONFIG_LOCALVERSION="stmark2-001"
>>>>>>> [snip]
>>>>>>>>
>>>>>>>>
>>>>>>>> I tried still yesterday a bit, but seems there is no much support for
>>>>>>>> earlyprintk / low level debug for this architecture.
>>>>>>>>
>>>>>>>> In case i can try with a gpio toggling routine, at least to find
>>>>>>>> where kernel stops.
>>>>>>>
>>>>>>> The attached patch, is a quick and dirty early console output method.
>>>>>>> It works for me on the m5475, should work for you "as is" on the 5441x too.
>>>>>>>
>>>>>>> It is kind of an early printk. Of course it still needs the early
>>>>>>> kernel boot to have succeeded before you will get anything much coming out.
>>>>>>> But it is worth trying.
>>>>>>
>>>>>> Ok many thanks. Btw i used a __square(); function written in asm, so i am
>>>>>> sure i see the gpio toggling in very early stages.
>>>>>>
>>>>>>>
>>>>>>> I am wondering if the non-0 base RAM may be a problem. I have only run
>>>>>>> the MMU enabled code on platforms with 0 based RAM so far. But lets see if
>>>>>>> the early console trace attached gives us anything before digging into that.
>>>>>>>
>>>>>>
>>>>>> This MCU has sdram area physically mapped at 0x4000 0000 so U-Boot, to be
>>>>>> able to execute the kernel must load it to that location/area anyway.
>>>>>>
>>>>>> But i have seen that it is not a problem, after MMU is enabled in head.S
>>>>>> the jump
>>>>>>                   movel   #_vstart,%a0      /* jump to "virtual" space */
>>>>>>           jmp     %a0@
>>>>>>
>>>>>> works fine. Since that range is not hitting anything that is maintained
>>>>>> physical, it can be translated into virtual without any issue.
>>>>>
>>>>> Yeah, it is not so much the initial start up that I think will
>>>>> be the problem. More the setup of the MMU mapping tables later
>>>>> in boot.
>>>>>
>>>>>
>>>>>> After some hard debug, i see the execution stops at:
>>>>>>
>>>>>> asmlinkage __visible void __init start_kernel(void)
>>>>>>      ...
>>>>>>      setup_arch(&command_line);      setup_mm.c
>>>>>>         ...
>>>>>>         paging_init();               mm/mcfmmu.c
>>>>>>            ...
>>>>>>            empty_zero_page = (void *) alloc_bootmem_pages(PAGE_SIZE);
>>>>>>            ^line 47 mcfmmu.c
>>>>>>
>>>>>> Inside alloc_bootmem_pages(), execution seems to end up finally to
>>>>>> mm/bootmem.c and likely to alloc_bootmem_bdata().
>>>>>> In case i can still proceed to find the exact place where execution stops,
>>>>>> but i suspect in the while(1), line 545.
>>>>>>
>>>>>> As a curious thing, i find in a different cf CPU code "m54xx.c"
>>>>>> the following:
>>>>>>
>>>>>> void __init config_BSP(char *commandp, int size)
>>>>>> {
>>>>>> #ifdef CONFIG_MMU
>>>>>>       cf_bootmem_alloc();
>>>>>>       mmu_context_init();
>>>>>> #endif
>>>>>> Do also m5441x.c maybe need this calls ?
>>>>>
>>>>> Yes, you will need this. So that code above is only getting run when
>>>>> configured for a 547x CPU family. Attached is a rework of that code
>>>>> so that it will be run for all ColdFire MMU varients. Can you try
>>>>> that out?
>>>>>
>>>>>
>>>>>> Would be very nice to have MMU working. Strangely, i don't see any
>>>>>> board_config with it enabled. Was it ever tested on some Coldfire ?
>>>>>
>>>>> Oh, yeah, I run this on a real M5475 EVB board for every kernel
>>>>> mainline release, with and without MMU enabled. See the
>>>>> arch/m68k/configs/m5475evb_defconfig, it will default to having
>>>>> the MMU enabled.
>>>>>
>>>>> I have todays linux-4.13-rc5 running on it here now:
>>>>>
>>>>> # cat /proc/version
>>>>> Linux version 4.13.0-rc5-00001-gb014090-dirty (gerg@goober) (gcc version 5.4.0 (GCC)) #1 Mon Aug 14 10:14:12 AEST 2017
>>>>>
>>>>> # cat /proc/cpuinfo
>>>>> CPU:            ColdFire
>>>>> MMU:            ColdFire
>>>>> FPU:            ColdFire
>>>>> Clocking:       264.1MHz
>>>>> BogoMips:       264.19
>>>>> Calibration:    1320960 loops
>>>>> #
>>>>>
>>>>> Regards
>>>>> Greg
>>>>
>>>> Ok, i applied your patch, and still the kernel is hanging silently,
>>>> so i started up a new debug session again.
>>>>
>>>> What is actually happening (after your patch has been applied) is:
>>>>
>>>> setup_arch()                arch/m68k/kernel/setup_mm.c
>>>>    paging_init()
>>>> memmap_init()               mm/page_alloc.c
>>>> memmap_init_zone()
>>>>    __init_single_page()
>>>>        set_page_links()       include/linux/mm.h
>>>>           set_page_zone()
>>>>             kernel hangs silently on this line
>>>>             page->flags &= ~(ZONES_MASK << ZONES_PGSHIFT);
>>>>
>>>>>
>>>>
> 
> Can you run your current code with the console debug code I sent
> a little while back?
> 
> I ask because I suspect it should give something based on your debug
> above. I played around a little trying to fake out my configuration
> to make it look like the RAM was non-zero based. I couldn't get a fail,
> but I would like to add some more debug to see what is going on with
> the page pointers from your debug.
> 
> Can you apply the attached patch and get any extra debug?
> 
> 
>>>> I am wondering how mmu works, so at the moment mmu is enabled,
>>>> in head.S, i would expect that code compiled for 0x40001000 would
>>>> not run, since jumps would be translated to some different physical
>>>> addresses, but execution sill works.
>>>> At the same, after enabling mmu i would expect .data vars to be
>>>> invalid, since their address would be translated to a different
>>>> location, while not, the init values of .data variables are still
>>>> valid. In case, i am interested to understand this points.
>>>
>>> On the ColdFire the kernel relies on all RAM and IO peripheral
>>> addresses) to "hit" the ACR registers - and essentially be passed
>>> through as an identity physical = virtual mapping. If you look at
>>> the operation of the memory address translation when virtual mode
>>> is enabled (in the ColdFire MMU sections of the 5475 and 54411
>>> reference manual) you will see that addresses are checked in order
>>> to be for the MMUBAR, RAMBAR, ACR, then MMU.
>>>
>>> For example a kernel address when in supervisor mode will hit
>>> ACR1 or ACR3 the way we set them up in arch/m68k/coldfire/head.S.
>>> And that is why you see kernel code and data still being valid after
>>> the MMU is enabled in virtual mode. No TLB entries required for this.
>>>
>>> Looking at your call sequence above I can see that the physical
>>> RAM start address being non-zero is going to come into play. I'll
>>> dig into this a little more tomorrow see if I can figure out what
>>> is going on.
>>>
>>
>> Thanks for the kind clarifications.
>>
>> I'll look in this things too in next days, learning is always nice.
>> Btw, about load/entry address, i have noticed a possible basic
>> difference betweeen mcf5441x and mcf547x series:
>>
>> The second one (your cpu) is v4e and probably more recent i guess, and
>> one major difference from datasheet seems to be that it is Harvard.
>> So probably, for this reason, you can address ram from 0 there.
> 
> IIRC the 5475 was the first ColdFire with MMU, it is pretty old. Pretty
> sure the 54411 came later. Not sure what the thinking was on the different
> default memory layout though.
> 

Finally, cleaning out my debug lines, i found i removed an important line.
So i am back to original "second" error we was trying to understand.


So current more clear status is:

U-Boot 2017.09-rc2-00151-g2d7cb5b426-dirty (Aug 22 2017 - 00:22:46 +0200)

CPU:   Freescale MCF54410 (Mask:9f Version:2)
        CPU CLK 240 MHz BUS CLK 120 MHz FLB CLK 60 MHz
        INP CLK 30 MHz VCO CLK 480 MHz
SPI:   ready
DRAM:  128 MiB
SF: Detected is25lp128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
SF: Detected is25lp128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
device 0 offset 0x100000, size 0x1d9728
SF: 1939240 bytes @ 0x100000 Read: OK
## Booting kernel from Legacy Image at 40001000 ...
    Image Name:   mainline kernel
    Created:      2017-08-22   0:07:25 UTC
    Image Type:   M68K Linux Kernel Image (uncompressed)
    Data Size:    1939176 Bytes = 1.8 MiB
    Load Address: 40001000
    Entry Point:  40001000
    Verifying Checksum ... OK
    Loading Kernel Image ... OK
Linux version 4.12.0stmark2-001-11691-g571d81b2b55f-dirty (angelo@jerusalem) (gcc version 4.9.0 (crosstools-sysam-2016.04.16)) #182 Tue Aug 22 02:07:24 CEST 2017
------------[ cut here ]------------
WARNING: CPU: 0 PID: 0 at mm/page_alloc.c:6219 free_area_init_node+0x2f4/0x2fa
CPU: 0 PID: 0 Comm: swapper Not tainted 4.12.0stmark2-001-11691-g571d81b2b55f-dirty #182
Stack from 4017deec:

        
  4017deec
  4017b3dd
  40007972
  00000000
  00000000
  47d9f62c
  00020000
  00000000

        
  00000000
  4017df9c
  40007a14
  4016dd8e
  0000184b
  4019caca
  00000009
  00000000

        
  00000000
  4019caca
  4016dd8e
  0000184b
  48000000
  40204000
  47d9f62c
  40001000

        
  00000000
  47d9ef1c
  40001480
  4013010c
  4012cd16
  4017dfa8
  4019ecc0
  00012000

        
  00002000
  4019ccb4
  00000000
  4017df9c
  00020000
  00000000
  4019a3f2
  4017df9c

        
  00000001
  401da8c0
  401da774
  4019ebc8
  00004000
  00000000
  00000000
  4017dfc8

Call Trace:
  [<40007972>] __warn+0xa4/0xc0
  [<40007a14>] warn_slowpath_null+0x1a/0x22
  [<4019caca>] free_area_init_node+0x2f4/0x2fa
  [<4019caca>] free_area_init_node+0x2f4/0x2fa
  [<40001000>] kernel_pg_dir+0x0/0x1000
  [<40001480>] kernel_pg_dir+0x480/0x1000
  [<4013010c>] memset+0x0/0x80
  [<4012cd16>] strlen+0x0/0x14
  [<4019ecc0>] __alloc_bootmem+0x16/0x3c
  [<4019ccb4>] free_area_init+0x20/0x26
  [<4019a3f2>] paging_init+0xee/0xfa
  [<4019ebc8>] free_bootmem_node+0x0/0x34
  [<40199fbc>] setup_arch+0xcc/0x16e
  [<40024eb2>] printk+0x0/0x18
  [<4019ecaa>] __alloc_bootmem+0x0/0x3c
  [<40198550>] start_kernel+0x68/0x3ae
  [<40001000>] kernel_pg_dir+0x0/0x1000
  [<400020f2>] _exit+0x0/0x6

---[ end trace 0000000000000000 ]---
On node 0 totalpages: 16384
free_area_init_node: node 0, pgdat 401da8c0, node_mem_map a8c0401d
   DMA zone: 72 pages used for memmap
   DMA zone: 0 pages reserved
   DMA zone: 16384 pages, LIFO batch:3
/page_alloc.c(1171): page=a8c0401d pfn=131072




> Regards
> Greg
> 
> 

Reagrds,
Angelo

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

[Greg Ungerer]

Hi Angelo,

On 22/08/17 10:35, Angelo Dureghello wrote:
> On 21/08/2017 09:15, Greg Ungerer wrote:
>> On 20/08/17 23:26, Angelo Dureghello wrote:
>>> On 20/08/2017 14:44, Greg Ungerer wrote:
>>>> On 18/08/17 01:02, Angelo Dureghello wrote:
>>>>> On 14/08/2017 06:16, Greg Ungerer wrote:
>>>>>> On 12/08/17 21:17, Angelo Dureghello wrote:
>>>>>>> On 10/08/2017 09:06, Greg Ungerer wrote:
>>>>>>>> On 10/08/17 01:32, Angelo Dureghello wrote:
>>>>>>>> [snip]
>>>>>>>>> sure, on this board  http://sysam.it/cff_stmark2.html
>>>>>>>>> there are 128MB of ddr2.
>>>>>>>>>
>>>>>>>>> External SDRAM is accessible, at least without any mmc support enabled,
>>>>>>>>> from 0x40000000.
>>>>>>>>>
>>>>>>>>> I have following test config:
>>>>>>>>>
>>>>>>>>>      GNU nano 2.8.6 File: arch/m68k/configs/stmark2_defconfig
>>>>>>>>>
>>>>>>>>> CONFIG_LOCALVERSION="stmark2-001"
>>>>>>>> [snip]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I tried still yesterday a bit, but seems there is no much support for
>>>>>>>>> earlyprintk / low level debug for this architecture.
>>>>>>>>>
>>>>>>>>> In case i can try with a gpio toggling routine, at least to find
>>>>>>>>> where kernel stops.
>>>>>>>>
>>>>>>>> The attached patch, is a quick and dirty early console output method.
>>>>>>>> It works for me on the m5475, should work for you "as is" on the 5441x too.
>>>>>>>>
>>>>>>>> It is kind of an early printk. Of course it still needs the early
>>>>>>>> kernel boot to have succeeded before you will get anything much coming out.
>>>>>>>> But it is worth trying.
>>>>>>>
>>>>>>> Ok many thanks. Btw i used a __square(); function written in asm, so i am
>>>>>>> sure i see the gpio toggling in very early stages.
>>>>>>>
>>>>>>>>
>>>>>>>> I am wondering if the non-0 base RAM may be a problem. I have only run
>>>>>>>> the MMU enabled code on platforms with 0 based RAM so far. But lets see if
>>>>>>>> the early console trace attached gives us anything before digging into that.
>>>>>>>>
>>>>>>>
>>>>>>> This MCU has sdram area physically mapped at 0x4000 0000 so U-Boot, to be
>>>>>>> able to execute the kernel must load it to that location/area anyway.
>>>>>>>
>>>>>>> But i have seen that it is not a problem, after MMU is enabled in head.S
>>>>>>> the jump
>>>>>>>                   movel   #_vstart,%a0      /* jump to "virtual" space */
>>>>>>>           jmp     %a0@
>>>>>>>
>>>>>>> works fine. Since that range is not hitting anything that is maintained
>>>>>>> physical, it can be translated into virtual without any issue.
>>>>>>
>>>>>> Yeah, it is not so much the initial start up that I think will
>>>>>> be the problem. More the setup of the MMU mapping tables later
>>>>>> in boot.
>>>>>>
>>>>>>
>>>>>>> After some hard debug, i see the execution stops at:
>>>>>>>
>>>>>>> asmlinkage __visible void __init start_kernel(void)
>>>>>>>      ...
>>>>>>>      setup_arch(&command_line);      setup_mm.c
>>>>>>>         ...
>>>>>>>         paging_init();               mm/mcfmmu.c
>>>>>>>            ...
>>>>>>>            empty_zero_page = (void *) alloc_bootmem_pages(PAGE_SIZE);
>>>>>>>            ^line 47 mcfmmu.c
>>>>>>>
>>>>>>> Inside alloc_bootmem_pages(), execution seems to end up finally to
>>>>>>> mm/bootmem.c and likely to alloc_bootmem_bdata().
>>>>>>> In case i can still proceed to find the exact place where execution stops,
>>>>>>> but i suspect in the while(1), line 545.
>>>>>>>
>>>>>>> As a curious thing, i find in a different cf CPU code "m54xx.c"
>>>>>>> the following:
>>>>>>>
>>>>>>> void __init config_BSP(char *commandp, int size)
>>>>>>> {
>>>>>>> #ifdef CONFIG_MMU
>>>>>>>       cf_bootmem_alloc();
>>>>>>>       mmu_context_init();
>>>>>>> #endif
>>>>>>> Do also m5441x.c maybe need this calls ?
>>>>>>
>>>>>> Yes, you will need this. So that code above is only getting run when
>>>>>> configured for a 547x CPU family. Attached is a rework of that code
>>>>>> so that it will be run for all ColdFire MMU varients. Can you try
>>>>>> that out?
>>>>>>
>>>>>>
>>>>>>> Would be very nice to have MMU working. Strangely, i don't see any
>>>>>>> board_config with it enabled. Was it ever tested on some Coldfire ?
>>>>>>
>>>>>> Oh, yeah, I run this on a real M5475 EVB board for every kernel
>>>>>> mainline release, with and without MMU enabled. See the
>>>>>> arch/m68k/configs/m5475evb_defconfig, it will default to having
>>>>>> the MMU enabled.
>>>>>>
>>>>>> I have todays linux-4.13-rc5 running on it here now:
>>>>>>
>>>>>> # cat /proc/version
>>>>>> Linux version 4.13.0-rc5-00001-gb014090-dirty (gerg@goober) (gcc version 5.4.0 (GCC)) #1 Mon Aug 14 10:14:12 AEST 2017
>>>>>>
>>>>>> # cat /proc/cpuinfo
>>>>>> CPU:            ColdFire
>>>>>> MMU:            ColdFire
>>>>>> FPU:            ColdFire
>>>>>> Clocking:       264.1MHz
>>>>>> BogoMips:       264.19
>>>>>> Calibration:    1320960 loops
>>>>>> #
>>>>>>
>>>>>> Regards
>>>>>> Greg
>>>>>
>>>>> Ok, i applied your patch, and still the kernel is hanging silently,
>>>>> so i started up a new debug session again.
>>>>>
>>>>> What is actually happening (after your patch has been applied) is:
>>>>>
>>>>> setup_arch()                arch/m68k/kernel/setup_mm.c
>>>>>    paging_init()
>>>>> memmap_init()               mm/page_alloc.c
>>>>> memmap_init_zone()
>>>>>    __init_single_page()
>>>>>        set_page_links()       include/linux/mm.h
>>>>>           set_page_zone()
>>>>>             kernel hangs silently on this line
>>>>>             page->flags &= ~(ZONES_MASK << ZONES_PGSHIFT);
>>>>>
>>>>>>
>>>>>
>>
>> Can you run your current code with the console debug code I sent
>> a little while back?
>>
>> I ask because I suspect it should give something based on your debug
>> above. I played around a little trying to fake out my configuration
>> to make it look like the RAM was non-zero based. I couldn't get a fail,
>> but I would like to add some more debug to see what is going on with
>> the page pointers from your debug.
>>
>> Can you apply the attached patch and get any extra debug?
>>
>>
>>>>> I am wondering how mmu works, so at the moment mmu is enabled,
>>>>> in head.S, i would expect that code compiled for 0x40001000 would
>>>>> not run, since jumps would be translated to some different physical
>>>>> addresses, but execution sill works.
>>>>> At the same, after enabling mmu i would expect .data vars to be
>>>>> invalid, since their address would be translated to a different
>>>>> location, while not, the init values of .data variables are still
>>>>> valid. In case, i am interested to understand this points.
>>>>
>>>> On the ColdFire the kernel relies on all RAM and IO peripheral
>>>> addresses) to "hit" the ACR registers - and essentially be passed
>>>> through as an identity physical = virtual mapping. If you look at
>>>> the operation of the memory address translation when virtual mode
>>>> is enabled (in the ColdFire MMU sections of the 5475 and 54411
>>>> reference manual) you will see that addresses are checked in order
>>>> to be for the MMUBAR, RAMBAR, ACR, then MMU.
>>>>
>>>> For example a kernel address when in supervisor mode will hit
>>>> ACR1 or ACR3 the way we set them up in arch/m68k/coldfire/head.S.
>>>> And that is why you see kernel code and data still being valid after
>>>> the MMU is enabled in virtual mode. No TLB entries required for this.
>>>>
>>>> Looking at your call sequence above I can see that the physical
>>>> RAM start address being non-zero is going to come into play. I'll
>>>> dig into this a little more tomorrow see if I can figure out what
>>>> is going on.
>>>>
>>>
>>> Thanks for the kind clarifications.
>>>
>>> I'll look in this things too in next days, learning is always nice.
>>> Btw, about load/entry address, i have noticed a possible basic
>>> difference betweeen mcf5441x and mcf547x series:
>>>
>>> The second one (your cpu) is v4e and probably more recent i guess, and
>>> one major difference from datasheet seems to be that it is Harvard.
>>> So probably, for this reason, you can address ram from 0 there.
>>
>> IIRC the 5475 was the first ColdFire with MMU, it is pretty old. Pretty
>> sure the 54411 came later. Not sure what the thinking was on the different
>> default memory layout though.
>>
> 
> Finally, cleaning out my debug lines, i found i removed an important line.
> So i am back to original "second" error we was trying to understand.
> 
> 
> So current more clear status is:
> 
> U-Boot 2017.09-rc2-00151-g2d7cb5b426-dirty (Aug 22 2017 - 00:22:46 +0200)
> 
> CPU:   Freescale MCF54410 (Mask:9f Version:2)
>        CPU CLK 240 MHz BUS CLK 120 MHz FLB CLK 60 MHz
>        INP CLK 30 MHz VCO CLK 480 MHz
> SPI:   ready
> DRAM:  128 MiB
> SF: Detected is25lp128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
> In:    serial
> Out:   serial
> Err:   serial
> Hit any key to stop autoboot:  0
> SF: Detected is25lp128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
> device 0 offset 0x100000, size 0x1d9728
> SF: 1939240 bytes @ 0x100000 Read: OK
> ## Booting kernel from Legacy Image at 40001000 ...
>    Image Name:   mainline kernel
>    Created:      2017-08-22   0:07:25 UTC
>    Image Type:   M68K Linux Kernel Image (uncompressed)
>    Data Size:    1939176 Bytes = 1.8 MiB
>    Load Address: 40001000
>    Entry Point:  40001000
>    Verifying Checksum ... OK
>    Loading Kernel Image ... OK
> Linux version 4.12.0stmark2-001-11691-g571d81b2b55f-dirty (angelo@jerusalem) (gcc version 4.9.0 (crosstools-sysam-2016.04.16)) #182 Tue Aug 22 02:07:24 CEST 2017
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 0 at mm/page_alloc.c:6219 free_area_init_node+0x2f4/0x2fa
> CPU: 0 PID: 0 Comm: swapper Not tainted 4.12.0stmark2-001-11691-g571d81b2b55f-dirty #182
> Stack from 4017deec:
> 
>         4017deec
>  4017b3dd
>  40007972
>  00000000
>  00000000
>  47d9f62c
>  00020000
>  00000000
> 
>         00000000
>  4017df9c
>  40007a14
>  4016dd8e
>  0000184b
>  4019caca
>  00000009
>  00000000
> 
>         00000000
>  4019caca
>  4016dd8e
>  0000184b
>  48000000
>  40204000
>  47d9f62c
>  40001000
> 
>         00000000
>  47d9ef1c
>  40001480
>  4013010c
>  4012cd16
>  4017dfa8
>  4019ecc0
>  00012000
> 
>         00002000
>  4019ccb4
>  00000000
>  4017df9c
>  00020000
>  00000000
>  4019a3f2
>  4017df9c
> 
>         00000001
>  401da8c0
>  401da774
>  4019ebc8
>  00004000
>  00000000
>  00000000
>  4017dfc8
> 
> Call Trace:
>  [<40007972>] __warn+0xa4/0xc0
>  [<40007a14>] warn_slowpath_null+0x1a/0x22
>  [<4019caca>] free_area_init_node+0x2f4/0x2fa
>  [<4019caca>] free_area_init_node+0x2f4/0x2fa
>  [<40001000>] kernel_pg_dir+0x0/0x1000
>  [<40001480>] kernel_pg_dir+0x480/0x1000
>  [<4013010c>] memset+0x0/0x80
>  [<4012cd16>] strlen+0x0/0x14
>  [<4019ecc0>] __alloc_bootmem+0x16/0x3c
>  [<4019ccb4>] free_area_init+0x20/0x26
>  [<4019a3f2>] paging_init+0xee/0xfa
>  [<4019ebc8>] free_bootmem_node+0x0/0x34
>  [<40199fbc>] setup_arch+0xcc/0x16e
>  [<40024eb2>] printk+0x0/0x18
>  [<4019ecaa>] __alloc_bootmem+0x0/0x3c
>  [<40198550>] start_kernel+0x68/0x3ae
>  [<40001000>] kernel_pg_dir+0x0/0x1000
>  [<400020f2>] _exit+0x0/0x6
> 
> ---[ end trace 0000000000000000 ]---
> On node 0 totalpages: 16384
> free_area_init_node: node 0, pgdat 401da8c0, node_mem_map a8c0401d
                                                            ^^^^^^^^
>   DMA zone: 72 pages used for memmap
>   DMA zone: 0 pages reserved
>   DMA zone: 16384 pages, LIFO batch:3
> /page_alloc.c(1171): page=a8c0401d pfn=131072
                            ^^^^^^^^
Ok, this is getting somewhere. Clearly that page pointer is not valid.

I'll have a dig around and see if I can figure out what might cause that.

Regards
Greg

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

[Greg Ungerer]

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

Hi Angelo,

On 22/08/17 10:35, Angelo Dureghello wrote:
> On 21/08/2017 09:15, Greg Ungerer wrote:
>> On 20/08/17 23:26, Angelo Dureghello wrote:
>>> On 20/08/2017 14:44, Greg Ungerer wrote:
>>>> On 18/08/17 01:02, Angelo Dureghello wrote:
>>>>> On 14/08/2017 06:16, Greg Ungerer wrote:
>>>>>> On 12/08/17 21:17, Angelo Dureghello wrote:
>>>>>>> On 10/08/2017 09:06, Greg Ungerer wrote:
>>>>>>>> On 10/08/17 01:32, Angelo Dureghello wrote:
>>>>>>>> [snip]
>>>>>>>>> sure, on this board  http://sysam.it/cff_stmark2.html
>>>>>>>>> there are 128MB of ddr2.
>>>>>>>>>
>>>>>>>>> External SDRAM is accessible, at least without any mmc support enabled,
>>>>>>>>> from 0x40000000.
>>>>>>>>>
>>>>>>>>> I have following test config:
>>>>>>>>>
>>>>>>>>>      GNU nano 2.8.6 File: arch/m68k/configs/stmark2_defconfig
>>>>>>>>>
>>>>>>>>> CONFIG_LOCALVERSION="stmark2-001"
>>>>>>>> [snip]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I tried still yesterday a bit, but seems there is no much support for
>>>>>>>>> earlyprintk / low level debug for this architecture.
>>>>>>>>>
>>>>>>>>> In case i can try with a gpio toggling routine, at least to find
>>>>>>>>> where kernel stops.
>>>>>>>>
>>>>>>>> The attached patch, is a quick and dirty early console output method.
>>>>>>>> It works for me on the m5475, should work for you "as is" on the 5441x too.
>>>>>>>>
>>>>>>>> It is kind of an early printk. Of course it still needs the early
>>>>>>>> kernel boot to have succeeded before you will get anything much coming out.
>>>>>>>> But it is worth trying.
>>>>>>>
>>>>>>> Ok many thanks. Btw i used a __square(); function written in asm, so i am
>>>>>>> sure i see the gpio toggling in very early stages.
>>>>>>>
>>>>>>>>
>>>>>>>> I am wondering if the non-0 base RAM may be a problem. I have only run
>>>>>>>> the MMU enabled code on platforms with 0 based RAM so far. But lets see if
>>>>>>>> the early console trace attached gives us anything before digging into that.
>>>>>>>>
>>>>>>>
>>>>>>> This MCU has sdram area physically mapped at 0x4000 0000 so U-Boot, to be
>>>>>>> able to execute the kernel must load it to that location/area anyway.
>>>>>>>
>>>>>>> But i have seen that it is not a problem, after MMU is enabled in head.S
>>>>>>> the jump
>>>>>>>                   movel   #_vstart,%a0      /* jump to "virtual" space */
>>>>>>>           jmp     %a0@
>>>>>>>
>>>>>>> works fine. Since that range is not hitting anything that is maintained
>>>>>>> physical, it can be translated into virtual without any issue.
>>>>>>
>>>>>> Yeah, it is not so much the initial start up that I think will
>>>>>> be the problem. More the setup of the MMU mapping tables later
>>>>>> in boot.
>>>>>>
>>>>>>
>>>>>>> After some hard debug, i see the execution stops at:
>>>>>>>
>>>>>>> asmlinkage __visible void __init start_kernel(void)
>>>>>>>      ...
>>>>>>>      setup_arch(&command_line);      setup_mm.c
>>>>>>>         ...
>>>>>>>         paging_init();               mm/mcfmmu.c
>>>>>>>            ...
>>>>>>>            empty_zero_page = (void *) alloc_bootmem_pages(PAGE_SIZE);
>>>>>>>            ^line 47 mcfmmu.c
>>>>>>>
>>>>>>> Inside alloc_bootmem_pages(), execution seems to end up finally to
>>>>>>> mm/bootmem.c and likely to alloc_bootmem_bdata().
>>>>>>> In case i can still proceed to find the exact place where execution stops,
>>>>>>> but i suspect in the while(1), line 545.
>>>>>>>
>>>>>>> As a curious thing, i find in a different cf CPU code "m54xx.c"
>>>>>>> the following:
>>>>>>>
>>>>>>> void __init config_BSP(char *commandp, int size)
>>>>>>> {
>>>>>>> #ifdef CONFIG_MMU
>>>>>>>       cf_bootmem_alloc();
>>>>>>>       mmu_context_init();
>>>>>>> #endif
>>>>>>> Do also m5441x.c maybe need this calls ?
>>>>>>
>>>>>> Yes, you will need this. So that code above is only getting run when
>>>>>> configured for a 547x CPU family. Attached is a rework of that code
>>>>>> so that it will be run for all ColdFire MMU varients. Can you try
>>>>>> that out?
>>>>>>
>>>>>>
>>>>>>> Would be very nice to have MMU working. Strangely, i don't see any
>>>>>>> board_config with it enabled. Was it ever tested on some Coldfire ?
>>>>>>
>>>>>> Oh, yeah, I run this on a real M5475 EVB board for every kernel
>>>>>> mainline release, with and without MMU enabled. See the
>>>>>> arch/m68k/configs/m5475evb_defconfig, it will default to having
>>>>>> the MMU enabled.
>>>>>>
>>>>>> I have todays linux-4.13-rc5 running on it here now:
>>>>>>
>>>>>> # cat /proc/version
>>>>>> Linux version 4.13.0-rc5-00001-gb014090-dirty (gerg@goober) (gcc version 5.4.0 (GCC)) #1 Mon Aug 14 10:14:12 AEST 2017
>>>>>>
>>>>>> # cat /proc/cpuinfo
>>>>>> CPU:            ColdFire
>>>>>> MMU:            ColdFire
>>>>>> FPU:            ColdFire
>>>>>> Clocking:       264.1MHz
>>>>>> BogoMips:       264.19
>>>>>> Calibration:    1320960 loops
>>>>>> #
>>>>>>
>>>>>> Regards
>>>>>> Greg
>>>>>
>>>>> Ok, i applied your patch, and still the kernel is hanging silently,
>>>>> so i started up a new debug session again.
>>>>>
>>>>> What is actually happening (after your patch has been applied) is:
>>>>>
>>>>> setup_arch()                arch/m68k/kernel/setup_mm.c
>>>>>    paging_init()
>>>>> memmap_init()               mm/page_alloc.c
>>>>> memmap_init_zone()
>>>>>    __init_single_page()
>>>>>        set_page_links()       include/linux/mm.h
>>>>>           set_page_zone()
>>>>>             kernel hangs silently on this line
>>>>>             page->flags &= ~(ZONES_MASK << ZONES_PGSHIFT);
>>>>>
>>>>>>
>>>>>
>>
>> Can you run your current code with the console debug code I sent
>> a little while back?
>>
>> I ask because I suspect it should give something based on your debug
>> above. I played around a little trying to fake out my configuration
>> to make it look like the RAM was non-zero based. I couldn't get a fail,
>> but I would like to add some more debug to see what is going on with
>> the page pointers from your debug.
>>
>> Can you apply the attached patch and get any extra debug?
>>
>>
>>>>> I am wondering how mmu works, so at the moment mmu is enabled,
>>>>> in head.S, i would expect that code compiled for 0x40001000 would
>>>>> not run, since jumps would be translated to some different physical
>>>>> addresses, but execution sill works.
>>>>> At the same, after enabling mmu i would expect .data vars to be
>>>>> invalid, since their address would be translated to a different
>>>>> location, while not, the init values of .data variables are still
>>>>> valid. In case, i am interested to understand this points.
>>>>
>>>> On the ColdFire the kernel relies on all RAM and IO peripheral
>>>> addresses) to "hit" the ACR registers - and essentially be passed
>>>> through as an identity physical = virtual mapping. If you look at
>>>> the operation of the memory address translation when virtual mode
>>>> is enabled (in the ColdFire MMU sections of the 5475 and 54411
>>>> reference manual) you will see that addresses are checked in order
>>>> to be for the MMUBAR, RAMBAR, ACR, then MMU.
>>>>
>>>> For example a kernel address when in supervisor mode will hit
>>>> ACR1 or ACR3 the way we set them up in arch/m68k/coldfire/head.S.
>>>> And that is why you see kernel code and data still being valid after
>>>> the MMU is enabled in virtual mode. No TLB entries required for this.
>>>>
>>>> Looking at your call sequence above I can see that the physical
>>>> RAM start address being non-zero is going to come into play. I'll
>>>> dig into this a little more tomorrow see if I can figure out what
>>>> is going on.
>>>>
>>>
>>> Thanks for the kind clarifications.
>>>
>>> I'll look in this things too in next days, learning is always nice.
>>> Btw, about load/entry address, i have noticed a possible basic
>>> difference betweeen mcf5441x and mcf547x series:
>>>
>>> The second one (your cpu) is v4e and probably more recent i guess, and
>>> one major difference from datasheet seems to be that it is Harvard.
>>> So probably, for this reason, you can address ram from 0 there.
>>
>> IIRC the 5475 was the first ColdFire with MMU, it is pretty old. Pretty
>> sure the 54411 came later. Not sure what the thinking was on the different
>> default memory layout though.
>>
> 
> Finally, cleaning out my debug lines, i found i removed an important line.
> So i am back to original "second" error we was trying to understand.
> 
> 
> So current more clear status is:
> 
> U-Boot 2017.09-rc2-00151-g2d7cb5b426-dirty (Aug 22 2017 - 00:22:46 +0200)
> 
> CPU:   Freescale MCF54410 (Mask:9f Version:2)
>        CPU CLK 240 MHz BUS CLK 120 MHz FLB CLK 60 MHz
>        INP CLK 30 MHz VCO CLK 480 MHz
> SPI:   ready
> DRAM:  128 MiB
> SF: Detected is25lp128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
> In:    serial
> Out:   serial
> Err:   serial
> Hit any key to stop autoboot:  0
> SF: Detected is25lp128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
> device 0 offset 0x100000, size 0x1d9728
> SF: 1939240 bytes @ 0x100000 Read: OK
> ## Booting kernel from Legacy Image at 40001000 ...
>    Image Name:   mainline kernel
>    Created:      2017-08-22   0:07:25 UTC
>    Image Type:   M68K Linux Kernel Image (uncompressed)
>    Data Size:    1939176 Bytes = 1.8 MiB
>    Load Address: 40001000
>    Entry Point:  40001000
>    Verifying Checksum ... OK
>    Loading Kernel Image ... OK
> Linux version 4.12.0stmark2-001-11691-g571d81b2b55f-dirty (angelo@jerusalem) (gcc version 4.9.0 (crosstools-sysam-2016.04.16)) #182 Tue Aug 22 02:07:24 CEST 2017
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 0 at mm/page_alloc.c:6219 free_area_init_node+0x2f4/0x2fa
> CPU: 0 PID: 0 Comm: swapper Not tainted 4.12.0stmark2-001-11691-g571d81b2b55f-dirty #182
> Stack from 4017deec:
> 
>         4017deec
>  4017b3dd
>  40007972
>  00000000
>  00000000
>  47d9f62c
>  00020000
>  00000000
> 
>         00000000
>  4017df9c
>  40007a14
>  4016dd8e
>  0000184b
>  4019caca
>  00000009
>  00000000
> 
>         00000000
>  4019caca
>  4016dd8e
>  0000184b
>  48000000
>  40204000
>  47d9f62c
>  40001000
> 
>         00000000
>  47d9ef1c
>  40001480
>  4013010c
>  4012cd16
>  4017dfa8
>  4019ecc0
>  00012000
> 
>         00002000
>  4019ccb4
>  00000000
>  4017df9c
>  00020000
>  00000000
>  4019a3f2
>  4017df9c
> 
>         00000001
>  401da8c0
>  401da774
>  4019ebc8
>  00004000
>  00000000
>  00000000
>  4017dfc8
> 
> Call Trace:
>  [<40007972>] __warn+0xa4/0xc0
>  [<40007a14>] warn_slowpath_null+0x1a/0x22
>  [<4019caca>] free_area_init_node+0x2f4/0x2fa
>  [<4019caca>] free_area_init_node+0x2f4/0x2fa
>  [<40001000>] kernel_pg_dir+0x0/0x1000
>  [<40001480>] kernel_pg_dir+0x480/0x1000
>  [<4013010c>] memset+0x0/0x80
>  [<4012cd16>] strlen+0x0/0x14
>  [<4019ecc0>] __alloc_bootmem+0x16/0x3c
>  [<4019ccb4>] free_area_init+0x20/0x26
>  [<4019a3f2>] paging_init+0xee/0xfa
>  [<4019ebc8>] free_bootmem_node+0x0/0x34
>  [<40199fbc>] setup_arch+0xcc/0x16e
>  [<40024eb2>] printk+0x0/0x18
>  [<4019ecaa>] __alloc_bootmem+0x0/0x3c
>  [<40198550>] start_kernel+0x68/0x3ae
>  [<40001000>] kernel_pg_dir+0x0/0x1000
>  [<400020f2>] _exit+0x0/0x6
> 
> ---[ end trace 0000000000000000 ]---
> On node 0 totalpages: 16384
> free_area_init_node: node 0, pgdat 401da8c0, node_mem_map a8c0401d
>   DMA zone: 72 pages used for memmap
>   DMA zone: 0 pages reserved
>   DMA zone: 16384 pages, LIFO batch:3
> /page_alloc.c(1171): page=a8c0401d pfn=131072

Another patch attached that digs a little deeper into why that page
pointer ends up being invalid. If you could run with this and send
the output that would be great.

Regards
Greg



[-- Attachment #2: cf-page-trace.patch --]
[-- Type: text/x-patch, Size: 1023 bytes --]

diff --git a/linux/mm/page_alloc.c b/linux/mm/page_alloc.c
index a2019fc..ab95a8c 100644
--- a/linux/mm/page_alloc.c
+++ b/linux/mm/page_alloc.c
@@ -1178,6 +1178,13 @@ static void free_one_page(struct zone *zone,
 static void __meminit __init_single_page(struct page *page, unsigned long pfn,
 				unsigned long zone, int nid)
 {
+	printk("%s(%d): page=%p pfn=%ld\n", __FILE__, __LINE__, page, pfn);
+	printk("%s(%d): __va(pfn=%ld)=%p\n", __FILE__, __LINE__, pfn, __va(pfn));
+	printk("%s(%d): pfn_to_virt(pfn=%ld)=%p\n", __FILE__, __LINE__, pfn, pfn_to_virt(pfn));
+	printk("%s(%d): __virt_to_node(pfn_to_virt(pfn=%ld))=%p\n", __FILE__, __LINE__, pfn, __virt_to_node((unsigned long)pfn_to_virt(pfn)));
+	printk("%s(%d): pg_data_map[0].node_start_pfn=%ld\n", __FILE__, __LINE__, pg_data_map[0].node_start_pfn);
+	printk("%s(%d): pg_data_map[0].node_present_pages=%ld\n", __FILE__, __LINE__, pg_data_map[0].node_present_pages);
+
 	set_page_links(page, zone, nid, pfn);
 	init_page_count(page);
 	page_mapcount_reset(page);

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

[Angelo Dureghello]

Hi Greg,

sorry for the late reply,
i decided to study inside the mmu code, working on a separate branch,
and after a long hard fight i have the prompt.

So good news, seems i probably have mmu working. See below for
further details.

On 23/08/2017 09:06, Greg Ungerer wrote:
> Hi Angelo,
> 
> On 22/08/17 10:35, Angelo Dureghello wrote:
>> On 21/08/2017 09:15, Greg Ungerer wrote:
>>> On 20/08/17 23:26, Angelo Dureghello wrote:
>>>> On 20/08/2017 14:44, Greg Ungerer wrote:
>>>>> On 18/08/17 01:02, Angelo Dureghello wrote:
>>>>>> On 14/08/2017 06:16, Greg Ungerer wrote:
>>>>>>> On 12/08/17 21:17, Angelo Dureghello wrote:
>>>>>>>> On 10/08/2017 09:06, Greg Ungerer wrote:
>>>>>>>>> On 10/08/17 01:32, Angelo Dureghello wrote:
>>>>>>>>> [snip]
>>>>>>>>>> sure, on this board  http://sysam.it/cff_stmark2.html
>>>>>>>>>> there are 128MB of ddr2.
>>>>>>>>>>
>>>>>>>>>> External SDRAM is accessible, at least without any mmc support enabled,
>>>>>>>>>> from 0x40000000.
>>>>>>>>>>
>>>>>>>>>> I have following test config:
>>>>>>>>>>
>>>>>>>>>>       GNU nano 2.8.6 File: arch/m68k/configs/stmark2_defconfig
>>>>>>>>>>
>>>>>>>>>> CONFIG_LOCALVERSION="stmark2-001"
>>>>>>>>> [snip]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I tried still yesterday a bit, but seems there is no much support for
>>>>>>>>>> earlyprintk / low level debug for this architecture.
>>>>>>>>>>
>>>>>>>>>> In case i can try with a gpio toggling routine, at least to find
>>>>>>>>>> where kernel stops.
>>>>>>>>>
>>>>>>>>> The attached patch, is a quick and dirty early console output method.
>>>>>>>>> It works for me on the m5475, should work for you "as is" on the 5441x too.
>>>>>>>>>
>>>>>>>>> It is kind of an early printk. Of course it still needs the early
>>>>>>>>> kernel boot to have succeeded before you will get anything much coming out.
>>>>>>>>> But it is worth trying.
>>>>>>>>
>>>>>>>> Ok many thanks. Btw i used a __square(); function written in asm, so i am
>>>>>>>> sure i see the gpio toggling in very early stages.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I am wondering if the non-0 base RAM may be a problem. I have only run
>>>>>>>>> the MMU enabled code on platforms with 0 based RAM so far. But lets see if
>>>>>>>>> the early console trace attached gives us anything before digging into that.
>>>>>>>>>
>>>>>>>>
>>>>>>>> This MCU has sdram area physically mapped at 0x4000 0000 so U-Boot, to be
>>>>>>>> able to execute the kernel must load it to that location/area anyway.
>>>>>>>>
>>>>>>>> But i have seen that it is not a problem, after MMU is enabled in head.S
>>>>>>>> the jump
>>>>>>>>                    movel   #_vstart,%a0      /* jump to "virtual" space */
>>>>>>>>            jmp     %a0@
>>>>>>>>
>>>>>>>> works fine. Since that range is not hitting anything that is maintained
>>>>>>>> physical, it can be translated into virtual without any issue.
>>>>>>>
>>>>>>> Yeah, it is not so much the initial start up that I think will
>>>>>>> be the problem. More the setup of the MMU mapping tables later
>>>>>>> in boot.
>>>>>>>
>>>>>>>
>>>>>>>> After some hard debug, i see the execution stops at:
>>>>>>>>
>>>>>>>> asmlinkage __visible void __init start_kernel(void)
>>>>>>>>       ...
>>>>>>>>       setup_arch(&command_line);      setup_mm.c
>>>>>>>>          ...
>>>>>>>>          paging_init();               mm/mcfmmu.c
>>>>>>>>             ...
>>>>>>>>             empty_zero_page = (void *) alloc_bootmem_pages(PAGE_SIZE);
>>>>>>>>             ^line 47 mcfmmu.c
>>>>>>>>
>>>>>>>> Inside alloc_bootmem_pages(), execution seems to end up finally to
>>>>>>>> mm/bootmem.c and likely to alloc_bootmem_bdata().
>>>>>>>> In case i can still proceed to find the exact place where execution stops,
>>>>>>>> but i suspect in the while(1), line 545.
>>>>>>>>
>>>>>>>> As a curious thing, i find in a different cf CPU code "m54xx.c"
>>>>>>>> the following:
>>>>>>>>
>>>>>>>> void __init config_BSP(char *commandp, int size)
>>>>>>>> {
>>>>>>>> #ifdef CONFIG_MMU
>>>>>>>>        cf_bootmem_alloc();
>>>>>>>>        mmu_context_init();
>>>>>>>> #endif
>>>>>>>> Do also m5441x.c maybe need this calls ?
>>>>>>>
>>>>>>> Yes, you will need this. So that code above is only getting run when
>>>>>>> configured for a 547x CPU family. Attached is a rework of that code
>>>>>>> so that it will be run for all ColdFire MMU varients. Can you try
>>>>>>> that out?
>>>>>>>
>>>>>>>
>>>>>>>> Would be very nice to have MMU working. Strangely, i don't see any
>>>>>>>> board_config with it enabled. Was it ever tested on some Coldfire ?
>>>>>>>
>>>>>>> Oh, yeah, I run this on a real M5475 EVB board for every kernel
>>>>>>> mainline release, with and without MMU enabled. See the
>>>>>>> arch/m68k/configs/m5475evb_defconfig, it will default to having
>>>>>>> the MMU enabled.
>>>>>>>
>>>>>>> I have todays linux-4.13-rc5 running on it here now:
>>>>>>>
>>>>>>> # cat /proc/version
>>>>>>> Linux version 4.13.0-rc5-00001-gb014090-dirty (gerg@goober) (gcc version 5.4.0 (GCC)) #1 Mon Aug 14 10:14:12 AEST 2017
>>>>>>>
>>>>>>> # cat /proc/cpuinfo
>>>>>>> CPU:            ColdFire
>>>>>>> MMU:            ColdFire
>>>>>>> FPU:            ColdFire
>>>>>>> Clocking:       264.1MHz
>>>>>>> BogoMips:       264.19
>>>>>>> Calibration:    1320960 loops
>>>>>>> #
>>>>>>>
>>>>>>> Regards
>>>>>>> Greg
>>>>>>
>>>>>> Ok, i applied your patch, and still the kernel is hanging silently,
>>>>>> so i started up a new debug session again.
>>>>>>
>>>>>> What is actually happening (after your patch has been applied) is:
>>>>>>
>>>>>> setup_arch()                arch/m68k/kernel/setup_mm.c
>>>>>>     paging_init()
>>>>>> memmap_init()               mm/page_alloc.c
>>>>>> memmap_init_zone()
>>>>>>     __init_single_page()
>>>>>>         set_page_links()       include/linux/mm.h
>>>>>>            set_page_zone()
>>>>>>              kernel hangs silently on this line
>>>>>>              page->flags &= ~(ZONES_MASK << ZONES_PGSHIFT);
>>>>>>
>>>>>>>
>>>>>>
>>>
>>> Can you run your current code with the console debug code I sent
>>> a little while back?
>>>
>>> I ask because I suspect it should give something based on your debug
>>> above. I played around a little trying to fake out my configuration
>>> to make it look like the RAM was non-zero based. I couldn't get a fail,
>>> but I would like to add some more debug to see what is going on with
>>> the page pointers from your debug.
>>>
>>> Can you apply the attached patch and get any extra debug?
>>>
>>>
>>>>>> I am wondering how mmu works, so at the moment mmu is enabled,
>>>>>> in head.S, i would expect that code compiled for 0x40001000 would
>>>>>> not run, since jumps would be translated to some different physical
>>>>>> addresses, but execution sill works.
>>>>>> At the same, after enabling mmu i would expect .data vars to be
>>>>>> invalid, since their address would be translated to a different
>>>>>> location, while not, the init values of .data variables are still
>>>>>> valid. In case, i am interested to understand this points.
>>>>>
>>>>> On the ColdFire the kernel relies on all RAM and IO peripheral
>>>>> addresses) to "hit" the ACR registers - and essentially be passed
>>>>> through as an identity physical = virtual mapping. If you look at
>>>>> the operation of the memory address translation when virtual mode
>>>>> is enabled (in the ColdFire MMU sections of the 5475 and 54411
>>>>> reference manual) you will see that addresses are checked in order
>>>>> to be for the MMUBAR, RAMBAR, ACR, then MMU.
>>>>>
>>>>> For example a kernel address when in supervisor mode will hit
>>>>> ACR1 or ACR3 the way we set them up in arch/m68k/coldfire/head.S.
>>>>> And that is why you see kernel code and data still being valid after
>>>>> the MMU is enabled in virtual mode. No TLB entries required for this.
>>>>>
>>>>> Looking at your call sequence above I can see that the physical
>>>>> RAM start address being non-zero is going to come into play. I'll
>>>>> dig into this a little more tomorrow see if I can figure out what
>>>>> is going on.
>>>>>
>>>>
>>>> Thanks for the kind clarifications.
>>>>
>>>> I'll look in this things too in next days, learning is always nice.
>>>> Btw, about load/entry address, i have noticed a possible basic
>>>> difference betweeen mcf5441x and mcf547x series:
>>>>
>>>> The second one (your cpu) is v4e and probably more recent i guess, and
>>>> one major difference from datasheet seems to be that it is Harvard.
>>>> So probably, for this reason, you can address ram from 0 there.
>>>
>>> IIRC the 5475 was the first ColdFire with MMU, it is pretty old. Pretty
>>> sure the 54411 came later. Not sure what the thinking was on the different
>>> default memory layout though.
>>>
>>
>> Finally, cleaning out my debug lines, i found i removed an important line.
>> So i am back to original "second" error we was trying to understand.
>>
>>
>> So current more clear status is:
>>
>> U-Boot 2017.09-rc2-00151-g2d7cb5b426-dirty (Aug 22 2017 - 00:22:46 +0200)
>>
>> CPU:   Freescale MCF54410 (Mask:9f Version:2)
>>         CPU CLK 240 MHz BUS CLK 120 MHz FLB CLK 60 MHz
>>         INP CLK 30 MHz VCO CLK 480 MHz
>> SPI:   ready
>> DRAM:  128 MiB
>> SF: Detected is25lp128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
>> In:    serial
>> Out:   serial
>> Err:   serial
>> Hit any key to stop autoboot:  0
>> SF: Detected is25lp128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
>> device 0 offset 0x100000, size 0x1d9728
>> SF: 1939240 bytes @ 0x100000 Read: OK
>> ## Booting kernel from Legacy Image at 40001000 ...
>>     Image Name:   mainline kernel
>>     Created:      2017-08-22   0:07:25 UTC
>>     Image Type:   M68K Linux Kernel Image (uncompressed)
>>     Data Size:    1939176 Bytes = 1.8 MiB
>>     Load Address: 40001000
>>     Entry Point:  40001000
>>     Verifying Checksum ... OK
>>     Loading Kernel Image ... OK
>> Linux version 4.12.0stmark2-001-11691-g571d81b2b55f-dirty (angelo@jerusalem) (gcc version 4.9.0 (crosstools-sysam-2016.04.16)) #182 Tue Aug 22 02:07:24 CEST 2017
>> ------------[ cut here ]------------
>> WARNING: CPU: 0 PID: 0 at mm/page_alloc.c:6219 free_area_init_node+0x2f4/0x2fa
>> CPU: 0 PID: 0 Comm: swapper Not tainted 4.12.0stmark2-001-11691-g571d81b2b55f-dirty #182
>> Stack from 4017deec:
>>
>>          4017deec
>>   4017b3dd
>>   40007972
>>   00000000
>>   00000000
>>   47d9f62c
>>   00020000
>>   00000000
>>
>>          00000000
>>   4017df9c
>>   40007a14
>>   4016dd8e
>>   0000184b
>>   4019caca
>>   00000009
>>   00000000
>>
>>          00000000
>>   4019caca
>>   4016dd8e
>>   0000184b
>>   48000000
>>   40204000
>>   47d9f62c
>>   40001000
>>
>>          00000000
>>   47d9ef1c
>>   40001480
>>   4013010c
>>   4012cd16
>>   4017dfa8
>>   4019ecc0
>>   00012000
>>
>>          00002000
>>   4019ccb4
>>   00000000
>>   4017df9c
>>   00020000
>>   00000000
>>   4019a3f2
>>   4017df9c
>>
>>          00000001
>>   401da8c0
>>   401da774
>>   4019ebc8
>>   00004000
>>   00000000
>>   00000000
>>   4017dfc8
>>
>> Call Trace:
>>   [<40007972>] __warn+0xa4/0xc0
>>   [<40007a14>] warn_slowpath_null+0x1a/0x22
>>   [<4019caca>] free_area_init_node+0x2f4/0x2fa
>>   [<4019caca>] free_area_init_node+0x2f4/0x2fa
>>   [<40001000>] kernel_pg_dir+0x0/0x1000
>>   [<40001480>] kernel_pg_dir+0x480/0x1000
>>   [<4013010c>] memset+0x0/0x80
>>   [<4012cd16>] strlen+0x0/0x14
>>   [<4019ecc0>] __alloc_bootmem+0x16/0x3c
>>   [<4019ccb4>] free_area_init+0x20/0x26
>>   [<4019a3f2>] paging_init+0xee/0xfa
>>   [<4019ebc8>] free_bootmem_node+0x0/0x34
>>   [<40199fbc>] setup_arch+0xcc/0x16e
>>   [<40024eb2>] printk+0x0/0x18
>>   [<4019ecaa>] __alloc_bootmem+0x0/0x3c
>>   [<40198550>] start_kernel+0x68/0x3ae
>>   [<40001000>] kernel_pg_dir+0x0/0x1000
>>   [<400020f2>] _exit+0x0/0x6
>>
>> ---[ end trace 0000000000000000 ]---
>> On node 0 totalpages: 16384
>> free_area_init_node: node 0, pgdat 401da8c0, node_mem_map a8c0401d
>>    DMA zone: 72 pages used for memmap
>>    DMA zone: 0 pages reserved
>>    DMA zone: 16384 pages, LIFO batch:3
>> /page_alloc.c(1171): page=a8c0401d pfn=131072
> 
> Another patch attached that digs a little deeper into why that page
> pointer ends up being invalid. If you could run with this and send
> the output that would be great.
> 
First of all, this is the trace you required me:

mm/page_alloc.c(1171): page=a8d0401d pfn=131072
mm/page_alloc.c(1172): __va(pfn=131072)=00020000
mm/page_alloc.c(1173): pfn_to_virt(pfn=131072)=40000000
mm/page_alloc.c(1174): __virt_to_node(pfn_to_virt(pfn=131072))=401da8d0
mm/page_alloc.c(1175): pg_data_map[0].node_start_pfn=131072
mm/page_alloc.c(1176): pg_data_map[0].node_present_pages=16384

---------------------------------------------------------------------------------

Mainly, as you have suspected initially, the issue is related the
the _rambase that has to be 0x40000000 for mcf5441x.

Initially i tried by the m68k_fixup, setting an offset of 0x40000000,
with something like

m68k_memoffset = 0x40000000;

but kernel in itial stages seems to need to access memory with logical
addresses to be the same as physical, or it hangs at first memset.

So i just found the way to fix the issue tuning the node related pg_data
pointer table, it is:

pg_data_t *pg_data_table[65];  

This table was accessed at pg_data_table[0x200] for the first node, so the
boot was crashing for an out of bounds.
So, since the slot calculation is done by the logical address, i subtracted
there the _rambase (0x40000000) and the table is accessed properly now.

Linux version 4.12.0stmark2-001-11692-gc54cfe5cf339-dirty (angelo@jerusalem) (gcc version 5.2.0 (crosstools-sysam-2016.04.16)) #29 Sun Aug 27 02:18:49 CEST 2017
On node 0 totalpages: 16384
free_area_init_node: node 0, pgdat 401d88b0, node_mem_map 40204000
   DMA zone: 72 pages used for memmap
   DMA zone: 0 pages reserved
   DMA zone: 16384 pages, LIFO batch:3
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768

pcpu-alloc:
[0]
0

Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16312
Kernel command line: console=ttyS0,115200 root=/dev/ram0 rw rootfstype=ramfs rdinit=/bin/init devtmpfs.mount=1
PID hash table entries: 512 (order: -2, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 3, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 2, 32768 bytes)
Sorting __ex_table...
PID hash table entries: 512 (order: -2, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 3, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 2, 32768 bytes)
Sorting __ex_table...
Memory: 128288K/131072K available (1219K kernel code, 103K rwdata, 288K rodata, 264K init, 79K bss, 2784K reserved, 0K cma-reserved)
Virtual kernel memory layout:
vector  : 0x40000000 - 0x40000400   (   1 KiB)
kmap    : 0xe0000000 - 0xf0000000   ( 256 MiB)
vmalloc : 0xd0000000 - 0xe0000000   ( 256 MiB)
lowmem  : 0x40000000 - 0x48000000   ( 128 MiB)
   .init : 0x40196000 - 0x401d8000   ( 264 KiB)
   .text : 0x40001000 - 0x40131d50   (1220 KiB)
   .data : 0x40131d50 - 0x40193a00   ( 392 KiB)
   .bss  : 0x401d86e0 - 0x401ec674   (  80 KiB)
...

/ # cat /proc/meminfo
MemTotal:         128552 kB
MemFree:          124336 kB
MemAvailable:     122728 kB
Buffers:               0 kB
Cached:             1264 kB
SwapCached:            0 kB
Active:             1440 kB
Inactive:            888 kB
Active(anon):       1064 kB
Inactive(anon):      216 kB
Active(file):        376 kB
Inactive(file):      672 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:          1080 kB
Mapped:              216 kB
Shmem:               216 kB
Slab:                  0 kB
SReclaimable:          0 kB
SUnreclaim:            0 kB
KernelStack:         144 kB
PageTables:          208 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:       64272 kB
Committed_AS:       1680 kB
VmallocTotal:     262144 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB



So for now i solved in this way:

diff --git a/arch/m68k/include/asm/page_mm.h b/arch/m68k/include/asm/page_mm.h
index e7a1946455a8..4f3cb6218b8a 100644
--- a/arch/m68k/include/asm/page_mm.h
+++ b/arch/m68k/include/asm/page_mm.h
@@ -142,7 +142,9 @@ static inline __attribute_const__ int __virt_to_node_shift(void)
         return shift;
  }
  
-#define __virt_to_node(addr)   (pg_data_table[(unsigned long)(addr) >> __virt_to_node_shift()])
+#define __virt_to_node(addr) \
+       pg_data_table[((unsigned long)(addr) - _rambase) \
+       >> __virt_to_node_shift()]
  #endif
  
  #define virt_to_page(addr) ({                                          \
diff --git a/arch/m68k/mm/init.c b/arch/m68k/mm/init.c
index a6ffead9bef5..61df1a1c8986 100644
--- a/arch/m68k/mm/init.c
+++ b/arch/m68k/mm/init.c
@@ -61,15 +61,24 @@ void __init m68k_setup_node(int node)
  #ifndef CONFIG_SINGLE_MEMORY_CHUNK
         struct m68k_mem_info *info = m68k_memory + node;
         int i, end;
+       unsigned long addr_relative = info->addr - _rambase;
  
-       i = (unsigned long)phys_to_virt(info->addr) >> __virt_to_node_shift();
-       end = (unsigned long)phys_to_virt(info->addr + info->size - 1) >> __virt_to_node_shift();
+       i = (unsigned long)phys_to_virt(addr_relative) >> __virt_to_node_shift();
+       end = (unsigned long)phys_to_virt(addr_relative + info->size - 1) >> __virt_to_node_shift();
         for (; i <= end; i++) {
                 if (pg_data_table[i])
                         pr_warn("overlap at %u for chunk %u\n", i, node);
                 pg_data_table[i] = pg_data_map + node;
         }
  #endif
+       /*
+        * alloc_node_mem_map() in mm/page_alloc.c will setup
+        * node_mem_map member only if it is set to 0,
+        * otherwise it is considered already set properly
+        * before (i.e. as per ia64).
+        * So we need to zero node data here.
+        */
+       memset(NODE_DATA(node), 0, sizeof(pg_data_t));
         pg_data_map[node].bdata = bootmem_node_data + node;
         node_set_online(node);
  }
diff --git a/arch/m68k/mm/mcfmmu.c b/arch/m68k/mm/mcfmmu.c
index c7efdf8e8eae..79af9a478f35 100644
--- a/arch/m68k/mm/mcfmmu.c
+++ b/arch/m68k/mm/mcfmmu.c
@@ -176,6 +176,8 @@ void __init cf_bootmem_alloc(void)
         m68k_memory[0].addr = _rambase;
         m68k_memory[0].size = _ramend - _rambase;
  
+       m68k_memoffset = m68k_memory[0].addr - PAGE_OFFSET;
+
         /* compute total pages in system */
         num_pages = PFN_DOWN(_ramend - _rambase);
  
(m68k_memoffset = m68k_memory[0].addr - PAGE_OFFSET;) is there but not needed
i guess so i would remove it.

This is not probably the best patch, let me know how do we proceed.

> Regards
> Greg
> 
> 
Regards,
Angelo

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

[Angelo Dureghello]

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

Hi Greg and all,

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.

Mainly what is not clear is what is the "m68k_fixup" needed.
I am interested eventually to know where the idea of that fixup
come from. The fixup seems should be module-related only, but
actually is called from each __pa() and __va(), so i am bit
conufsed, it seems also a kind of fixup (assembly replacement
at runtime) that i don't find in other archs.

Let me know if you need some tests, i keep the system running
with mmu enabled.
Will move as a next task into spi flash driver likely.

Regards,
Angelo


On 27/08/2017 02:31, Angelo Dureghello wrote:
> Hi Greg,
> 
> sorry for the late reply,
> i decided to study inside the mmu code, working on a separate branch,
> and after a long hard fight i have the prompt.
> 
> So good news, seems i probably have mmu working. See below for
> further details.
> 
> On 23/08/2017 09:06, Greg Ungerer wrote:
>> Hi Angelo,
>>
>> On 22/08/17 10:35, Angelo Dureghello wrote:
>>> On 21/08/2017 09:15, Greg Ungerer wrote:
>>>> On 20/08/17 23:26, Angelo Dureghello wrote:
>>>>> On 20/08/2017 14:44, Greg Ungerer wrote:
>>>>>> On 18/08/17 01:02, Angelo Dureghello wrote:
>>>>>>> On 14/08/2017 06:16, Greg Ungerer wrote:
>>>>>>>> On 12/08/17 21:17, Angelo Dureghello wrote:
>>>>>>>>> On 10/08/2017 09:06, Greg Ungerer wrote:
>>>>>>>>>> On 10/08/17 01:32, Angelo Dureghello wrote:
>>>>>>>>>> [snip]
>>>>>>>>>>> sure, on this board  http://sysam.it/cff_stmark2.html
>>>>>>>>>>> there are 128MB of ddr2.
>>>>>>>>>>>
>>>>>>>>>>> External SDRAM is accessible, at least without any mmc support enabled,
>>>>>>>>>>> from 0x40000000.
>>>>>>>>>>>
>>>>>>>>>>> I have following test config:
>>>>>>>>>>>
>>>>>>>>>>>       GNU nano 2.8.6 File: arch/m68k/configs/stmark2_defconfig
>>>>>>>>>>>
>>>>>>>>>>> CONFIG_LOCALVERSION="stmark2-001"
>>>>>>>>>> [snip]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I tried still yesterday a bit, but seems there is no much support for
>>>>>>>>>>> earlyprintk / low level debug for this architecture.
>>>>>>>>>>>
>>>>>>>>>>> In case i can try with a gpio toggling routine, at least to find
>>>>>>>>>>> where kernel stops.
>>>>>>>>>>
>>>>>>>>>> The attached patch, is a quick and dirty early console output method.
>>>>>>>>>> It works for me on the m5475, should work for you "as is" on the 5441x too.
>>>>>>>>>>
>>>>>>>>>> It is kind of an early printk. Of course it still needs the early
>>>>>>>>>> kernel boot to have succeeded before you will get anything much coming out.
>>>>>>>>>> But it is worth trying.
>>>>>>>>>
>>>>>>>>> Ok many thanks. Btw i used a __square(); function written in asm, so i am
>>>>>>>>> sure i see the gpio toggling in very early stages.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I am wondering if the non-0 base RAM may be a problem. I have only run
>>>>>>>>>> the MMU enabled code on platforms with 0 based RAM so far. But lets see if
>>>>>>>>>> the early console trace attached gives us anything before digging into that.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This MCU has sdram area physically mapped at 0x4000 0000 so U-Boot, to be
>>>>>>>>> able to execute the kernel must load it to that location/area anyway.
>>>>>>>>>
>>>>>>>>> But i have seen that it is not a problem, after MMU is enabled in head.S
>>>>>>>>> the jump
>>>>>>>>>                    movel   #_vstart,%a0      /* jump to "virtual" space */
>>>>>>>>>            jmp     %a0@
>>>>>>>>>
>>>>>>>>> works fine. Since that range is not hitting anything that is maintained
>>>>>>>>> physical, it can be translated into virtual without any issue.
>>>>>>>>
>>>>>>>> Yeah, it is not so much the initial start up that I think will
>>>>>>>> be the problem. More the setup of the MMU mapping tables later
>>>>>>>> in boot.
>>>>>>>>
>>>>>>>>
>>>>>>>>> After some hard debug, i see the execution stops at:
>>>>>>>>>
>>>>>>>>> asmlinkage __visible void __init start_kernel(void)
>>>>>>>>>       ...
>>>>>>>>>       setup_arch(&command_line);      setup_mm.c
>>>>>>>>>          ...
>>>>>>>>>          paging_init();               mm/mcfmmu.c
>>>>>>>>>             ...
>>>>>>>>>             empty_zero_page = (void *) alloc_bootmem_pages(PAGE_SIZE);
>>>>>>>>>             ^line 47 mcfmmu.c
>>>>>>>>>
>>>>>>>>> Inside alloc_bootmem_pages(), execution seems to end up finally to
>>>>>>>>> mm/bootmem.c and likely to alloc_bootmem_bdata().
>>>>>>>>> In case i can still proceed to find the exact place where execution stops,
>>>>>>>>> but i suspect in the while(1), line 545.
>>>>>>>>>
>>>>>>>>> As a curious thing, i find in a different cf CPU code "m54xx.c"
>>>>>>>>> the following:
>>>>>>>>>
>>>>>>>>> void __init config_BSP(char *commandp, int size)
>>>>>>>>> {
>>>>>>>>> #ifdef CONFIG_MMU
>>>>>>>>>        cf_bootmem_alloc();
>>>>>>>>>        mmu_context_init();
>>>>>>>>> #endif
>>>>>>>>> Do also m5441x.c maybe need this calls ?
>>>>>>>>
>>>>>>>> Yes, you will need this. So that code above is only getting run when
>>>>>>>> configured for a 547x CPU family. Attached is a rework of that code
>>>>>>>> so that it will be run for all ColdFire MMU varients. Can you try
>>>>>>>> that out?
>>>>>>>>
>>>>>>>>
>>>>>>>>> Would be very nice to have MMU working. Strangely, i don't see any
>>>>>>>>> board_config with it enabled. Was it ever tested on some Coldfire ?
>>>>>>>>
>>>>>>>> Oh, yeah, I run this on a real M5475 EVB board for every kernel
>>>>>>>> mainline release, with and without MMU enabled. See the
>>>>>>>> arch/m68k/configs/m5475evb_defconfig, it will default to having
>>>>>>>> the MMU enabled.
>>>>>>>>
>>>>>>>> I have todays linux-4.13-rc5 running on it here now:
>>>>>>>>
>>>>>>>> # cat /proc/version
>>>>>>>> Linux version 4.13.0-rc5-00001-gb014090-dirty (gerg@goober) (gcc version 5.4.0 (GCC)) #1 Mon Aug 14 10:14:12 AEST 2017
>>>>>>>>
>>>>>>>> # cat /proc/cpuinfo
>>>>>>>> CPU:            ColdFire
>>>>>>>> MMU:            ColdFire
>>>>>>>> FPU:            ColdFire
>>>>>>>> Clocking:       264.1MHz
>>>>>>>> BogoMips:       264.19
>>>>>>>> Calibration:    1320960 loops
>>>>>>>> #
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Greg
>>>>>>>
>>>>>>> Ok, i applied your patch, and still the kernel is hanging silently,
>>>>>>> so i started up a new debug session again.
>>>>>>>
>>>>>>> What is actually happening (after your patch has been applied) is:
>>>>>>>
>>>>>>> setup_arch()                arch/m68k/kernel/setup_mm.c
>>>>>>>     paging_init()
>>>>>>> memmap_init()               mm/page_alloc.c
>>>>>>> memmap_init_zone()
>>>>>>>     __init_single_page()
>>>>>>>         set_page_links()       include/linux/mm.h
>>>>>>>            set_page_zone()
>>>>>>>              kernel hangs silently on this line
>>>>>>>              page->flags &= ~(ZONES_MASK << ZONES_PGSHIFT);
>>>>>>>
>>>>>>>>
>>>>>>>
>>>>
>>>> Can you run your current code with the console debug code I sent
>>>> a little while back?
>>>>
>>>> I ask because I suspect it should give something based on your debug
>>>> above. I played around a little trying to fake out my configuration
>>>> to make it look like the RAM was non-zero based. I couldn't get a fail,
>>>> but I would like to add some more debug to see what is going on with
>>>> the page pointers from your debug.
>>>>
>>>> Can you apply the attached patch and get any extra debug?
>>>>
>>>>
>>>>>>> I am wondering how mmu works, so at the moment mmu is enabled,
>>>>>>> in head.S, i would expect that code compiled for 0x40001000 would
>>>>>>> not run, since jumps would be translated to some different physical
>>>>>>> addresses, but execution sill works.
>>>>>>> At the same, after enabling mmu i would expect .data vars to be
>>>>>>> invalid, since their address would be translated to a different
>>>>>>> location, while not, the init values of .data variables are still
>>>>>>> valid. In case, i am interested to understand this points.
>>>>>>
>>>>>> On the ColdFire the kernel relies on all RAM and IO peripheral
>>>>>> addresses) to "hit" the ACR registers - and essentially be passed
>>>>>> through as an identity physical = virtual mapping. If you look at
>>>>>> the operation of the memory address translation when virtual mode
>>>>>> is enabled (in the ColdFire MMU sections of the 5475 and 54411
>>>>>> reference manual) you will see that addresses are checked in order
>>>>>> to be for the MMUBAR, RAMBAR, ACR, then MMU.
>>>>>>
>>>>>> For example a kernel address when in supervisor mode will hit
>>>>>> ACR1 or ACR3 the way we set them up in arch/m68k/coldfire/head.S.
>>>>>> And that is why you see kernel code and data still being valid after
>>>>>> the MMU is enabled in virtual mode. No TLB entries required for this.
>>>>>>
>>>>>> Looking at your call sequence above I can see that the physical
>>>>>> RAM start address being non-zero is going to come into play. I'll
>>>>>> dig into this a little more tomorrow see if I can figure out what
>>>>>> is going on.
>>>>>>
>>>>>
>>>>> Thanks for the kind clarifications.
>>>>>
>>>>> I'll look in this things too in next days, learning is always nice.
>>>>> Btw, about load/entry address, i have noticed a possible basic
>>>>> difference betweeen mcf5441x and mcf547x series:
>>>>>
>>>>> The second one (your cpu) is v4e and probably more recent i guess, and
>>>>> one major difference from datasheet seems to be that it is Harvard.
>>>>> So probably, for this reason, you can address ram from 0 there.
>>>>
>>>> IIRC the 5475 was the first ColdFire with MMU, it is pretty old. Pretty
>>>> sure the 54411 came later. Not sure what the thinking was on the different
>>>> default memory layout though.
>>>>
>>>
>>> Finally, cleaning out my debug lines, i found i removed an important line.
>>> So i am back to original "second" error we was trying to understand.
>>>
>>>
>>> So current more clear status is:
>>>
>>> U-Boot 2017.09-rc2-00151-g2d7cb5b426-dirty (Aug 22 2017 - 00:22:46 +0200)
>>>
>>> CPU:   Freescale MCF54410 (Mask:9f Version:2)
>>>         CPU CLK 240 MHz BUS CLK 120 MHz FLB CLK 60 MHz
>>>         INP CLK 30 MHz VCO CLK 480 MHz
>>> SPI:   ready
>>> DRAM:  128 MiB
>>> SF: Detected is25lp128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
>>> In:    serial
>>> Out:   serial
>>> Err:   serial
>>> Hit any key to stop autoboot:  0
>>> SF: Detected is25lp128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
>>> device 0 offset 0x100000, size 0x1d9728
>>> SF: 1939240 bytes @ 0x100000 Read: OK
>>> ## Booting kernel from Legacy Image at 40001000 ...
>>>     Image Name:   mainline kernel
>>>     Created:      2017-08-22   0:07:25 UTC
>>>     Image Type:   M68K Linux Kernel Image (uncompressed)
>>>     Data Size:    1939176 Bytes = 1.8 MiB
>>>     Load Address: 40001000
>>>     Entry Point:  40001000
>>>     Verifying Checksum ... OK
>>>     Loading Kernel Image ... OK
>>> Linux version 4.12.0stmark2-001-11691-g571d81b2b55f-dirty (angelo@jerusalem) (gcc version 4.9.0 (crosstools-sysam-2016.04.16)) #182 Tue Aug 22 02:07:24 CEST 2017
>>> ------------[ cut here ]------------
>>> WARNING: CPU: 0 PID: 0 at mm/page_alloc.c:6219 free_area_init_node+0x2f4/0x2fa
>>> CPU: 0 PID: 0 Comm: swapper Not tainted 4.12.0stmark2-001-11691-g571d81b2b55f-dirty #182
>>> Stack from 4017deec:
>>>
>>>          4017deec
>>>   4017b3dd
>>>   40007972
>>>   00000000
>>>   00000000
>>>   47d9f62c
>>>   00020000
>>>   00000000
>>>
>>>          00000000
>>>   4017df9c
>>>   40007a14
>>>   4016dd8e
>>>   0000184b
>>>   4019caca
>>>   00000009
>>>   00000000
>>>
>>>          00000000
>>>   4019caca
>>>   4016dd8e
>>>   0000184b
>>>   48000000
>>>   40204000
>>>   47d9f62c
>>>   40001000
>>>
>>>          00000000
>>>   47d9ef1c
>>>   40001480
>>>   4013010c
>>>   4012cd16
>>>   4017dfa8
>>>   4019ecc0
>>>   00012000
>>>
>>>          00002000
>>>   4019ccb4
>>>   00000000
>>>   4017df9c
>>>   00020000
>>>   00000000
>>>   4019a3f2
>>>   4017df9c
>>>
>>>          00000001
>>>   401da8c0
>>>   401da774
>>>   4019ebc8
>>>   00004000
>>>   00000000
>>>   00000000
>>>   4017dfc8
>>>
>>> Call Trace:
>>>   [<40007972>] __warn+0xa4/0xc0
>>>   [<40007a14>] warn_slowpath_null+0x1a/0x22
>>>   [<4019caca>] free_area_init_node+0x2f4/0x2fa
>>>   [<4019caca>] free_area_init_node+0x2f4/0x2fa
>>>   [<40001000>] kernel_pg_dir+0x0/0x1000
>>>   [<40001480>] kernel_pg_dir+0x480/0x1000
>>>   [<4013010c>] memset+0x0/0x80
>>>   [<4012cd16>] strlen+0x0/0x14
>>>   [<4019ecc0>] __alloc_bootmem+0x16/0x3c
>>>   [<4019ccb4>] free_area_init+0x20/0x26
>>>   [<4019a3f2>] paging_init+0xee/0xfa
>>>   [<4019ebc8>] free_bootmem_node+0x0/0x34
>>>   [<40199fbc>] setup_arch+0xcc/0x16e
>>>   [<40024eb2>] printk+0x0/0x18
>>>   [<4019ecaa>] __alloc_bootmem+0x0/0x3c
>>>   [<40198550>] start_kernel+0x68/0x3ae
>>>   [<40001000>] kernel_pg_dir+0x0/0x1000
>>>   [<400020f2>] _exit+0x0/0x6
>>>
>>> ---[ end trace 0000000000000000 ]---
>>> On node 0 totalpages: 16384
>>> free_area_init_node: node 0, pgdat 401da8c0, node_mem_map a8c0401d
>>>    DMA zone: 72 pages used for memmap
>>>    DMA zone: 0 pages reserved
>>>    DMA zone: 16384 pages, LIFO batch:3
>>> /page_alloc.c(1171): page=a8c0401d pfn=131072
>>
>> Another patch attached that digs a little deeper into why that page
>> pointer ends up being invalid. If you could run with this and send
>> the output that would be great.
>>
> First of all, this is the trace you required me:
> 
> mm/page_alloc.c(1171): page=a8d0401d pfn=131072
> mm/page_alloc.c(1172): __va(pfn=131072)=00020000
> mm/page_alloc.c(1173): pfn_to_virt(pfn=131072)=40000000
> mm/page_alloc.c(1174): __virt_to_node(pfn_to_virt(pfn=131072))=401da8d0
> mm/page_alloc.c(1175): pg_data_map[0].node_start_pfn=131072
> mm/page_alloc.c(1176): pg_data_map[0].node_present_pages=16384
> 
> ---------------------------------------------------------------------------------
> 
> Mainly, as you have suspected initially, the issue is related the
> the _rambase that has to be 0x40000000 for mcf5441x.
> 
> Initially i tried by the m68k_fixup, setting an offset of 0x40000000,
> with something like
> 
> m68k_memoffset = 0x40000000;
> 
> but kernel in itial stages seems to need to access memory with logical
> addresses to be the same as physical, or it hangs at first memset.
> 
> So i just found the way to fix the issue tuning the node related pg_data
> pointer table, it is:
> 
> pg_data_t *pg_data_table[65];
> This table was accessed at pg_data_table[0x200] for the first node, so the
> boot was crashing for an out of bounds.
> So, since the slot calculation is done by the logical address, i subtracted
> there the _rambase (0x40000000) and the table is accessed properly now.
> 
> Linux version 4.12.0stmark2-001-11692-gc54cfe5cf339-dirty (angelo@jerusalem) (gcc version 5.2.0 (crosstools-sysam-2016.04.16)) #29 Sun Aug 27 02:18:49 CEST 2017
> On node 0 totalpages: 16384
> free_area_init_node: node 0, pgdat 401d88b0, node_mem_map 40204000
>    DMA zone: 72 pages used for memmap
>    DMA zone: 0 pages reserved
>    DMA zone: 16384 pages, LIFO batch:3
> pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
> 
> pcpu-alloc:
> [0]
> 0
> 
> Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16312
> Kernel command line: console=ttyS0,115200 root=/dev/ram0 rw rootfstype=ramfs rdinit=/bin/init devtmpfs.mount=1
> PID hash table entries: 512 (order: -2, 2048 bytes)
> Dentry cache hash table entries: 16384 (order: 3, 65536 bytes)
> Inode-cache hash table entries: 8192 (order: 2, 32768 bytes)
> Sorting __ex_table...
> PID hash table entries: 512 (order: -2, 2048 bytes)
> Dentry cache hash table entries: 16384 (order: 3, 65536 bytes)
> Inode-cache hash table entries: 8192 (order: 2, 32768 bytes)
> Sorting __ex_table...
> Memory: 128288K/131072K available (1219K kernel code, 103K rwdata, 288K rodata, 264K init, 79K bss, 2784K reserved, 0K cma-reserved)
> Virtual kernel memory layout:
> vector  : 0x40000000 - 0x40000400   (   1 KiB)
> kmap    : 0xe0000000 - 0xf0000000   ( 256 MiB)
> vmalloc : 0xd0000000 - 0xe0000000   ( 256 MiB)
> lowmem  : 0x40000000 - 0x48000000   ( 128 MiB)
>    .init : 0x40196000 - 0x401d8000   ( 264 KiB)
>    .text : 0x40001000 - 0x40131d50   (1220 KiB)
>    .data : 0x40131d50 - 0x40193a00   ( 392 KiB)
>    .bss  : 0x401d86e0 - 0x401ec674   (  80 KiB)
> ...
> 
> / # cat /proc/meminfo
> MemTotal:         128552 kB
> MemFree:          124336 kB
> MemAvailable:     122728 kB
> Buffers:               0 kB
> Cached:             1264 kB
> SwapCached:            0 kB
> Active:             1440 kB
> Inactive:            888 kB
> Active(anon):       1064 kB
> Inactive(anon):      216 kB
> Active(file):        376 kB
> Inactive(file):      672 kB
> Unevictable:           0 kB
> Mlocked:               0 kB
> SwapTotal:             0 kB
> SwapFree:              0 kB
> Dirty:                 0 kB
> Writeback:             0 kB
> AnonPages:          1080 kB
> Mapped:              216 kB
> Shmem:               216 kB
> Slab:                  0 kB
> SReclaimable:          0 kB
> SUnreclaim:            0 kB
> KernelStack:         144 kB
> PageTables:          208 kB
> NFS_Unstable:          0 kB
> Bounce:                0 kB
> WritebackTmp:          0 kB
> CommitLimit:       64272 kB
> Committed_AS:       1680 kB
> VmallocTotal:     262144 kB
> VmallocUsed:           0 kB
> VmallocChunk:          0 kB
> 
> 
> 
> So for now i solved in this way:
> 
> diff --git a/arch/m68k/include/asm/page_mm.h b/arch/m68k/include/asm/page_mm.h
> index e7a1946455a8..4f3cb6218b8a 100644
> --- a/arch/m68k/include/asm/page_mm.h
> +++ b/arch/m68k/include/asm/page_mm.h
> @@ -142,7 +142,9 @@ static inline __attribute_const__ int __virt_to_node_shift(void)
>          return shift;
>   }
> 
> -#define __virt_to_node(addr)   (pg_data_table[(unsigned long)(addr) >> __virt_to_node_shift()])
> +#define __virt_to_node(addr) \
> +       pg_data_table[((unsigned long)(addr) - _rambase) \
> +       >> __virt_to_node_shift()]
>   #endif
> 
>   #define virt_to_page(addr) ({                                          \
> diff --git a/arch/m68k/mm/init.c b/arch/m68k/mm/init.c
> index a6ffead9bef5..61df1a1c8986 100644
> --- a/arch/m68k/mm/init.c
> +++ b/arch/m68k/mm/init.c
> @@ -61,15 +61,24 @@ void __init m68k_setup_node(int node)
>   #ifndef CONFIG_SINGLE_MEMORY_CHUNK
>          struct m68k_mem_info *info = m68k_memory + node;
>          int i, end;
> +       unsigned long addr_relative = info->addr - _rambase;
> 
> -       i = (unsigned long)phys_to_virt(info->addr) >> __virt_to_node_shift();
> -       end = (unsigned long)phys_to_virt(info->addr + info->size - 1) >> __virt_to_node_shift();
> +       i = (unsigned long)phys_to_virt(addr_relative) >> __virt_to_node_shift();
> +       end = (unsigned long)phys_to_virt(addr_relative + info->size - 1) >> __virt_to_node_shift();
>          for (; i <= end; i++) {
>                  if (pg_data_table[i])
>                          pr_warn("overlap at %u for chunk %u\n", i, node);
>                  pg_data_table[i] = pg_data_map + node;
>          }
>   #endif
> +       /*
> +        * alloc_node_mem_map() in mm/page_alloc.c will setup
> +        * node_mem_map member only if it is set to 0,
> +        * otherwise it is considered already set properly
> +        * before (i.e. as per ia64).
> +        * So we need to zero node data here.
> +        */
> +       memset(NODE_DATA(node), 0, sizeof(pg_data_t));
>          pg_data_map[node].bdata = bootmem_node_data + node;
>          node_set_online(node);
>   }
> diff --git a/arch/m68k/mm/mcfmmu.c b/arch/m68k/mm/mcfmmu.c
> index c7efdf8e8eae..79af9a478f35 100644
> --- a/arch/m68k/mm/mcfmmu.c
> +++ b/arch/m68k/mm/mcfmmu.c
> @@ -176,6 +176,8 @@ void __init cf_bootmem_alloc(void)
>          m68k_memory[0].addr = _rambase;
>          m68k_memory[0].size = _ramend - _rambase;
> 
> +       m68k_memoffset = m68k_memory[0].addr - PAGE_OFFSET;
> +
>          /* compute total pages in system */
>          num_pages = PFN_DOWN(_ramend - _rambase);
> 
> (m68k_memoffset = m68k_memory[0].addr - PAGE_OFFSET;) is there but not needed
> i guess so i would remove it.
> 
> This is not probably the best patch, let me know how do we proceed.
> 
>> Regards
>> Greg
>>
>>
> Regards,
> Angelo

[-- Attachment #2: 0001-Patch-to-enable-mmu-from-Greg.patch --]
[-- Type: text/x-patch, Size: 4883 bytes --]

>From 9f0e06f9566de4d91a234753cd30160ce02fc8a8 Mon Sep 17 00:00:00 2001
From: Angelo Dureghello <angelo@sysam.it>
Date: Thu, 24 Aug 2017 00:01:06 +0200
Subject: [PATCH 1/2] Patch to enable mmu, from Greg.

Signed-off-by: Angelo Dureghello <angelo@sysam.it>
---
 arch/m68k/Kconfig.cpu               |  2 +-
 arch/m68k/coldfire/m54xx.c          |  4 ----
 arch/m68k/configs/stmark2_defconfig |  5 +++--
 arch/m68k/include/asm/mmu_context.h |  1 -
 arch/m68k/kernel/setup_mm.c         |  1 +
 arch/m68k/mm/mcfmmu.c               | 35 ++++++++++++++++++-----------------
 6 files changed, 23 insertions(+), 25 deletions(-)

diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu
index d2219f30b78f..4dc51c090a45 100644
--- a/arch/m68k/Kconfig.cpu
+++ b/arch/m68k/Kconfig.cpu
@@ -283,7 +283,7 @@ config M548x
 
 config M5441x
 	bool "MCF5441x"
-	depends on !MMU
+	select MMU_COLDFIRE if MMU
 	select GENERIC_CLOCKEVENTS
 	select HAVE_CACHE_CB
 	help
diff --git a/arch/m68k/coldfire/m54xx.c b/arch/m68k/coldfire/m54xx.c
index c552851ec617..704efeaeab2d 100644
--- a/arch/m68k/coldfire/m54xx.c
+++ b/arch/m68k/coldfire/m54xx.c
@@ -95,10 +95,6 @@ static void mcf54xx_reset(void)
 
 void __init config_BSP(char *commandp, int size)
 {
-#ifdef CONFIG_MMU
-	cf_bootmem_alloc();
-	mmu_context_init();
-#endif
 	mach_reset = mcf54xx_reset;
 	mach_sched_init = hw_timer_init;
 	m54xx_uarts_init();
diff --git a/arch/m68k/configs/stmark2_defconfig b/arch/m68k/configs/stmark2_defconfig
index ea78b8f6a68e..b886f303cc3f 100644
--- a/arch/m68k/configs/stmark2_defconfig
+++ b/arch/m68k/configs/stmark2_defconfig
@@ -21,7 +21,7 @@ CONFIG_EMBEDDED=y
 # CONFIG_LBDAF is not set
 # CONFIG_BLK_DEV_BSG is not set
 CONFIG_BLK_CMDLINE_PARSER=y
-# CONFIG_MMU is not set
+CONFIG_COLDFIRE=y
 CONFIG_M5441x=y
 CONFIG_CLOCK_FREQ=240000000
 CONFIG_STMARK2=y
@@ -30,6 +30,8 @@ CONFIG_RAMSIZE=0x8000000
 CONFIG_VECTORBASE=0x40000000
 CONFIG_KERNELBASE=0x40001000
 CONFIG_BINFMT_FLAT=y
+CONFIG_BINFMT_ZFLAT=y
+CONFIG_BINFMT_SHARED_FLAT=y
 CONFIG_BINFMT_MISC=y
 # CONFIG_UEVENT_HELPER is not set
 CONFIG_DEVTMPFS=y
@@ -53,7 +55,6 @@ CONFIG_MTD_COMPLEX_MAPPINGS=y
 CONFIG_MTD_PHYSMAP=y
 CONFIG_MTD_PLATRAM=y
 CONFIG_MTD_SPI_NOR=y
-# CONFIG_INPUT_MOUSEDEV is not set
 # CONFIG_INPUT_KEYBOARD is not set
 # CONFIG_INPUT_MOUSE is not set
 CONFIG_SERIO_LIBPS2=y
diff --git a/arch/m68k/include/asm/mmu_context.h b/arch/m68k/include/asm/mmu_context.h
index 4a6ae6dffa34..00c28b1dc47b 100644
--- a/arch/m68k/include/asm/mmu_context.h
+++ b/arch/m68k/include/asm/mmu_context.h
@@ -91,7 +91,6 @@ static inline void activate_mm(struct mm_struct *active_mm,
 
 #define deactivate_mm(tsk, mm) do { } while (0)
 
-extern void mmu_context_init(void);
 #define prepare_arch_switch(next) load_ksp_mmu(next)
 
 static inline void load_ksp_mmu(struct task_struct *task)
diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c
index 7a2c21212820..5632c48b9f3b 100644
--- a/arch/m68k/kernel/setup_mm.c
+++ b/arch/m68k/kernel/setup_mm.c
@@ -343,6 +343,7 @@ void __init setup_arch(char **cmdline_p)
 #ifdef CONFIG_COLDFIRE
 	case MACH_M54XX:
 	case MACH_M5441X:
+		cf_bootmem_alloc();
 		config_BSP(NULL, 0);
 		break;
 #endif
diff --git a/arch/m68k/mm/mcfmmu.c b/arch/m68k/mm/mcfmmu.c
index 87131cd3bc8f..c7efdf8e8eae 100644
--- a/arch/m68k/mm/mcfmmu.c
+++ b/arch/m68k/mm/mcfmmu.c
@@ -150,6 +150,23 @@ int cf_tlb_miss(struct pt_regs *regs, int write, int dtlb, int extension_word)
 	return 0;
 }
 
+/*
+ * Initialize the context management stuff.
+ * The following was taken from arch/ppc/mmu_context.c
+ */
+static void __init mmu_context_init(void)
+{
+	/*
+	 * Some processors have too few contexts to reserve one for
+	 * init_mm, and require using context 0 for a normal task.
+	 * Other processors reserve the use of context zero for the kernel.
+	 * This code assumes FIRST_CONTEXT < 32.
+	 */
+	context_map[0] = (1 << FIRST_CONTEXT) - 1;
+	next_mmu_context = FIRST_CONTEXT;
+	atomic_set(&nr_free_contexts, LAST_CONTEXT - FIRST_CONTEXT + 1);
+}
+
 void __init cf_bootmem_alloc(void)
 {
 	unsigned long start_pfn;
@@ -177,23 +194,7 @@ void __init cf_bootmem_alloc(void)
 	memstart += init_bootmem_node(NODE_DATA(0), start_pfn,
 		min_low_pfn, max_low_pfn);
 	free_bootmem_node(NODE_DATA(0), memstart, _ramend - memstart);
-}
-
-/*
- * Initialize the context management stuff.
- * The following was taken from arch/ppc/mmu_context.c
- */
-void __init mmu_context_init(void)
-{
-	/*
-	 * Some processors have too few contexts to reserve one for
-	 * init_mm, and require using context 0 for a normal task.
-	 * Other processors reserve the use of context zero for the kernel.
-	 * This code assumes FIRST_CONTEXT < 32.
-	 */
-	context_map[0] = (1 << FIRST_CONTEXT) - 1;
-	next_mmu_context = FIRST_CONTEXT;
-	atomic_set(&nr_free_contexts, LAST_CONTEXT - FIRST_CONTEXT + 1);
+	mmu_context_init();
 }
 
 /*
-- 
2.14.1


[-- Attachment #3: 0002-m68k-fix-mmu-for-coldfire-mcf5441x.patch --]
[-- Type: text/x-patch, Size: 2270 bytes --]

>From 96e88773601fff1edd61cec88095c60252be1343 Mon Sep 17 00:00:00 2001
From: Angelo Dureghello <angelo@sysam.it>
Date: Sun, 27 Aug 2017 02:42:42 +0200
Subject: [PATCH 2/2] m68k: fix mmu for coldfire mcf5441x

This patch fixes mmu not working for CPU's that has the base of the
physical memory mapped at a non-zero address.

Signed-off-by: Angelo Dureghello <angelo@sysam.it>
---
 arch/m68k/include/asm/page_mm.h |  4 +++-
 arch/m68k/mm/init.c             | 14 ++++++++++++--
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/arch/m68k/include/asm/page_mm.h b/arch/m68k/include/asm/page_mm.h
index e7a1946455a8..6c3b8c5181f9 100644
--- a/arch/m68k/include/asm/page_mm.h
+++ b/arch/m68k/include/asm/page_mm.h
@@ -142,7 +142,9 @@ static inline __attribute_const__ int __virt_to_node_shift(void)
 	return shift;
 }
 
-#define __virt_to_node(addr)	(pg_data_table[(unsigned long)(addr) >> __virt_to_node_shift()])
+#define __virt_to_node(addr) \
+	pg_data_table[((unsigned long)(addr) - PAGE_OFFSET) \
+	>> __virt_to_node_shift()]
 #endif
 
 #define virt_to_page(addr) ({						\
diff --git a/arch/m68k/mm/init.c b/arch/m68k/mm/init.c
index a6ffead9bef5..17254e6c3f9a 100644
--- a/arch/m68k/mm/init.c
+++ b/arch/m68k/mm/init.c
@@ -62,14 +62,24 @@ void __init m68k_setup_node(int node)
 	struct m68k_mem_info *info = m68k_memory + node;
 	int i, end;
 
-	i = (unsigned long)phys_to_virt(info->addr) >> __virt_to_node_shift();
-	end = (unsigned long)phys_to_virt(info->addr + info->size - 1) >> __virt_to_node_shift();
+	i = (unsigned long)phys_to_virt(info->addr - PAGE_OFFSET)
+		>> __virt_to_node_shift();
+	end = ((unsigned long)phys_to_virt(info->addr - PAGE_OFFSET)
+		+ info->size - 1) >> __virt_to_node_shift();
 	for (; i <= end; i++) {
 		if (pg_data_table[i])
 			pr_warn("overlap at %u for chunk %u\n", i, node);
 		pg_data_table[i] = pg_data_map + node;
 	}
 #endif
+	/*
+	 * alloc_node_mem_map() in mm/page_alloc.c will setup
+	 * node_mem_map member only if it is set to 0,
+	 * otherwise it is considered already set properly
+	 * before (i.e. as per ia64).
+	 * So we need to zero node data here.
+	 */
+	memset(NODE_DATA(node), 0, sizeof(pg_data_t));
 	pg_data_map[node].bdata = bootmem_node_data + node;
 	node_set_online(node);
 }
-- 
2.14.1

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

[Geert Uytterhoeven]

Hi Angelo,

On Fri, Sep 1, 2017 at 12:38 AM, Angelo Dureghello <angelo@sysam.it> wrote:
> Hi Greg and all,
>
> 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

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
        default "0"
        help
          Define the address that RAM starts at. On many platforms this is
@@ -334,6 +335,7 @@ config RAMBASE

 config RAMSIZE
        hex "Size of RAM (in bytes), or 0 for automatic"
+       depends on MMU
        default "0x400000"
        help
          Define the size of the system RAM. If you select 0 then the

depending on whether anything else in the Coldfire code needs RAMBASE.

> Mainly what is not clear is what is the "m68k_fixup" needed.
> I am interested eventually to know where the idea of that fixup
> come from. The fixup seems should be module-related only, but
> actually is called from each __pa() and __va(), so i am bit
> conufsed, it seems also a kind of fixup (assembly replacement
> at runtime) that i don't find in other archs.

commit fbe9c9612930e0604dc99ef2da7e063fa3278817
Author: Roman Zippel <zippel@linux-m68k.org>
Date:   Thu May 31 00:40:50 2007 -0700

    m68k: runtime patching infrastructure

    Add the basic infrastructure to allow runtime patching of kernel and modules
    to optimize a few functions with parameters, which are only calculated once
    during bootup and are otherwise constant.  Use this for the
conversion between
    virtual and physical addresses.

So it's a micro-optimization for virt/phys conversions, to avoid the extra
load of the offset to add/subtract.

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

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

[Greg Ungerer]

Hi Angelo, Geert,

On 01/09/17 17:49, Geert Uytterhoeven wrote:
> Hi Angelo,
> 
> On Fri, Sep 1, 2017 at 12:38 AM, Angelo Dureghello <angelo@sysam.it> wrote:
>> Hi Greg and all,
>>
>> 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
> 
> 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?

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.

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?

Regards
Greg




>          default "0"
>          help
>            Define the address that RAM starts at. On many platforms this is
> @@ -334,6 +335,7 @@ config RAMBASE
> 
>   config RAMSIZE
>          hex "Size of RAM (in bytes), or 0 for automatic"
> +       depends on MMU
>          default "0x400000"
>          help
>            Define the size of the system RAM. If you select 0 then the
> 
> depending on whether anything else in the Coldfire code needs RAMBASE.
> 
>> Mainly what is not clear is what is the "m68k_fixup" needed.
>> I am interested eventually to know where the idea of that fixup
>> come from. The fixup seems should be module-related only, but
>> actually is called from each __pa() and __va(), so i am bit
>> conufsed, it seems also a kind of fixup (assembly replacement
>> at runtime) that i don't find in other archs.
> 
> commit fbe9c9612930e0604dc99ef2da7e063fa3278817
> Author: Roman Zippel <zippel@linux-m68k.org>
> Date:   Thu May 31 00:40:50 2007 -0700
> 
>      m68k: runtime patching infrastructure
> 
>      Add the basic infrastructure to allow runtime patching of kernel and modules
>      to optimize a few functions with parameters, which are only calculated once
>      during bootup and are otherwise constant.  Use this for the
> conversion between
>      virtual and physical addresses.
> 
> So it's a micro-optimization for virt/phys conversions, to avoid the extra
> load of the offset to add/subtract.
> 
> 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
> 

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

[Geert Uytterhoeven]

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
>>
>> 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

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

[Angelo Dureghello]

Hi Greg and Geert,

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.

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.


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)





>>> 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

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

[Greg Ungerer]

[-- 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 */

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

[Angelo Dureghello]

Hi Greg,


On 04/09/2017 08:08, Greg Ungerer wrote:
> 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.
> 
> 
Great catch, the patch works,
i maintaind btw the

memset(NODE_DATA(node), 0, sizeof(pg_data_t));

inside void __init m68k_setup_node(int node) since otherwise
there was that warning we've seen initially.

About the "cd" issue, it seems to be a hush issue, maybe
becouse hush is built as nommu. Re-executing hush, i can now cd
to a subfolder, but i get then a SEGV on "cd ..".
	

This the boot log:

## Booting kernel from Legacy Image at 40001000 ...
    Image Name:   mainline kernel
    Created:      2017-09-04  14:19:47 UTC
    Image Type:   M68K Linux Kernel Image (uncompressed)
    Data Size:    1930976 Bytes = 1.8 MiB
    Load Address: 40001000
    Entry Point:  40001000
    Verifying Checksum ... OK
    Loading Kernel Image ... OK
[    0.000000] Linux version 4.13.0-rc7stmark2-001-00039-g96e88773601f-dirty (angelo@jerusalem) (gcc version 5.2.0 (crosstools-sysam-2016.04.16)) #56 Mon Sep 4 16:19:46 CEST 2017
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16312
[    0.000000] Kernel command line: console=ttyS0,115200 root=/dev/ram0 rw rootfstype=ramfs rdinit=/bin/init devtmpfs.mount=1
[    0.000000] PID hash table entries: 512 (order: -2, 2048 bytes)
[    0.000000] Dentry cache hash table entries: 16384 (order: 3, 65536 bytes)
[    0.000000] Inode-cache hash table entries: 8192 (order: 2, 32768 bytes)
[    0.000000] Sorting __ex_table...
[    0.000000] Memory: 128288K/131072K available (1219K kernel code, 103K rwdata, 288K rodata, 264K init, 79K bss, 2784K reserved, 0K cma-reserved)
[    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 - 0x40131cb0   (1220 KiB)
[    0.000000]       .data : 0x40131cb0 - 0x40193900   ( 392 KiB)
[    0.000000]       .bss  : 0x401d86e0 - 0x401ec680   (  80 KiB)
[    0.000000] SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=8
[    0.000000] NR_IRQS: 256
[    0.000000] clocksource: pit: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1019338904850 ns
[    0.000000] Console: colour dummy device 80x25
[    0.070000] Calibrating delay loop... 238.38 BogoMIPS (lpj=1191936)
[    0.070000] pid_max: default: 32768 minimum: 301
[    0.070000] Mount-cache hash table entries: 2048 (order: 0, 8192 bytes)
[    0.070000] Mountpoint-cache hash table entries: 2048 (order: 0, 8192 bytes)
[    0.080000] devtmpfs: initialized
[    0.090000] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.090000] futex hash table entries: 256 (order: -2, 3072 bytes)
[    0.110000] clocksource: Switched to clocksource pit
[    0.110000] FS-Cache: Loaded
[    0.380000] workingset: timestamp_bits=27 max_order=14 bucket_order=0
[    0.430000] io scheduler noop registered
[    0.430000] io scheduler deadline registered
[    0.430000] io scheduler cfq registered (default)
[    0.430000] io scheduler mq-deadline registered
[    0.430000] io scheduler kyber registered
[    0.920000] ColdFire internal UART serial driver
[    0.920000] mcfuart.0: ttyS0 at MMIO 0xfc060000 (irq = 90, base_baud = 7500000) is a ColdFire UART
[    1.110000] console [ttyS0] enabled
[    1.110000] mcfuart.0: ttyS1 at MMIO 0xfc064000 (irq = 91, base_baud = 7500000) is a ColdFire UART
[    1.120000] mcfuart.0: ttyS2 at MMIO 0xfc068000 (irq = 92, base_baud = 7500000) is a ColdFire UART
[    1.130000] mcfuart.0: ttyS3 at MMIO 0xfc06c000 (irq = 93, base_baud = 7500000) is a ColdFire UART
[    1.150000] random: get_random_bytes called from init_oops_id+0x26/0x46 with crng_init=0
[    1.160000] Freeing unused kernel memory: 264K
[    1.170000] This architecture does not have kernel memory protection.
[    1.410000] random: fast init done

/ #


> 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
>>
> 

Regards,
Angelo

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

[Greg Ungerer]

Hi Angelo,

On 05/09/17 00:42, Angelo Dureghello wrote:
> On 04/09/2017 08:08, Greg Ungerer wrote:
>> 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.
>>
>>
> Great catch, the patch works,

Thats great, thanks for trying that out.


> i maintaind btw the
> 
> memset(NODE_DATA(node), 0, sizeof(pg_data_t));
> 
> inside void __init m68k_setup_node(int node) since otherwise
> there was that warning we've seen initially.

Ok, I am not quite sure why you would still need that though.
Do you mean the warning about overlaping chunks?  Can you send
the exact warning output again running this now?

>From the code I would have expected that array area to be in the
kernel bss and be zeroed out at system startup. (For what it is
worth I don't see that warning on my non-zero based test 5475 test
config).


> About the "cd" issue, it seems to be a hush issue, maybe
> becouse hush is built as nommu. Re-executing hush, i can now cd
> to a subfolder, but i get then a SEGV on "cd ..".

Yeah, maybe that is related to flat format binaries. Normally I
run a uClibc ELF based user space with MMU enabled. I'll try with
a FLAT format user space and see if I get any problems.

Regards
Greg


 
> This the boot log:
> 
> ## Booting kernel from Legacy Image at 40001000 ...
>    Image Name:   mainline kernel
>    Created:      2017-09-04  14:19:47 UTC
>    Image Type:   M68K Linux Kernel Image (uncompressed)
>    Data Size:    1930976 Bytes = 1.8 MiB
>    Load Address: 40001000
>    Entry Point:  40001000
>    Verifying Checksum ... OK
>    Loading Kernel Image ... OK
> [    0.000000] Linux version 4.13.0-rc7stmark2-001-00039-g96e88773601f-dirty (angelo@jerusalem) (gcc version 5.2.0 (crosstools-sysam-2016.04.16)) #56 Mon Sep 4 16:19:46 CEST 2017
> [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16312
> [    0.000000] Kernel command line: console=ttyS0,115200 root=/dev/ram0 rw rootfstype=ramfs rdinit=/bin/init devtmpfs.mount=1
> [    0.000000] PID hash table entries: 512 (order: -2, 2048 bytes)
> [    0.000000] Dentry cache hash table entries: 16384 (order: 3, 65536 bytes)
> [    0.000000] Inode-cache hash table entries: 8192 (order: 2, 32768 bytes)
> [    0.000000] Sorting __ex_table...
> [    0.000000] Memory: 128288K/131072K available (1219K kernel code, 103K rwdata, 288K rodata, 264K init, 79K bss, 2784K reserved, 0K cma-reserved)
> [    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 - 0x40131cb0   (1220 KiB)
> [    0.000000]       .data : 0x40131cb0 - 0x40193900   ( 392 KiB)
> [    0.000000]       .bss  : 0x401d86e0 - 0x401ec680   (  80 KiB)
> [    0.000000] SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=8
> [    0.000000] NR_IRQS: 256
> [    0.000000] clocksource: pit: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1019338904850 ns
> [    0.000000] Console: colour dummy device 80x25
> [    0.070000] Calibrating delay loop... 238.38 BogoMIPS (lpj=1191936)
> [    0.070000] pid_max: default: 32768 minimum: 301
> [    0.070000] Mount-cache hash table entries: 2048 (order: 0, 8192 bytes)
> [    0.070000] Mountpoint-cache hash table entries: 2048 (order: 0, 8192 bytes)
> [    0.080000] devtmpfs: initialized
> [    0.090000] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
> [    0.090000] futex hash table entries: 256 (order: -2, 3072 bytes)
> [    0.110000] clocksource: Switched to clocksource pit
> [    0.110000] FS-Cache: Loaded
> [    0.380000] workingset: timestamp_bits=27 max_order=14 bucket_order=0
> [    0.430000] io scheduler noop registered
> [    0.430000] io scheduler deadline registered
> [    0.430000] io scheduler cfq registered (default)
> [    0.430000] io scheduler mq-deadline registered
> [    0.430000] io scheduler kyber registered
> [    0.920000] ColdFire internal UART serial driver
> [    0.920000] mcfuart.0: ttyS0 at MMIO 0xfc060000 (irq = 90, base_baud = 7500000) is a ColdFire UART
> [    1.110000] console [ttyS0] enabled
> [    1.110000] mcfuart.0: ttyS1 at MMIO 0xfc064000 (irq = 91, base_baud = 7500000) is a ColdFire UART
> [    1.120000] mcfuart.0: ttyS2 at MMIO 0xfc068000 (irq = 92, base_baud = 7500000) is a ColdFire UART
> [    1.130000] mcfuart.0: ttyS3 at MMIO 0xfc06c000 (irq = 93, base_baud = 7500000) is a ColdFire UART
> [    1.150000] random: get_random_bytes called from init_oops_id+0x26/0x46 with crng_init=0
> [    1.160000] Freeing unused kernel memory: 264K
> [    1.170000] This architecture does not have kernel memory protection.
> [    1.410000] random: fast init done
> 
> / #
> 
> 
>> 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
>>>
>>
> 
> Regards,
> Angelo
> 

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

[Angelo Dureghello]

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

Hi Greg,

On 07/09/2017 04:01, Greg Ungerer wrote:
> Hi Angelo,
> 
> On 05/09/17 00:42, Angelo Dureghello wrote:
>> On 04/09/2017 08:08, Greg Ungerer wrote:
>>> 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.
>>>
>>>
>> Great catch, the patch works,
> 
> Thats great, thanks for trying that out.
> 
> 
>> i maintaind btw the
>>
>> memset(NODE_DATA(node), 0, sizeof(pg_data_t));
>>
>> inside void __init m68k_setup_node(int node) since otherwise
>> there was that warning we've seen initially.
> 
> Ok, I am not quite sure why you would still need that though.
> Do you mean the warning about overlaping chunks?  Can you send
> the exact warning output again running this now?
> 
>  From the code I would have expected that array area to be in the
> kernel bss and be zeroed out at system startup. (For what it is
> worth I don't see that warning on my non-zero based test 5475 test
> config).
> 

Sure, my mistake, i just maintained that line and didn't try to
remove it after your final 1-line patch.

Just re-tested now, without that memset, all works fine as you was
expecting, no warnings.
I attach the 2 progressive patches, the first you sent me initially,
and this last one, that actually is just 1 line patch.

> 
>> About the "cd" issue, it seems to be a hush issue, maybe
>> becouse hush is built as nommu. Re-executing hush, i can now cd
>> to a subfolder, but i get then a SEGV on "cd ..".
> 
> Yeah, maybe that is related to flat format binaries. Normally I
> run a uClibc ELF based user space with MMU enabled. I'll try with
> a FLAT format user space and see if I get any problems.
> 
> Regards
> Greg
> 
> 
>   
>> This the boot log:
>>
>> ## Booting kernel from Legacy Image at 40001000 ...
>>     Image Name:   mainline kernel
>>     Created:      2017-09-04  14:19:47 UTC
>>     Image Type:   M68K Linux Kernel Image (uncompressed)
>>     Data Size:    1930976 Bytes = 1.8 MiB
>>     Load Address: 40001000
>>     Entry Point:  40001000
>>     Verifying Checksum ... OK
>>     Loading Kernel Image ... OK
>> [    0.000000] Linux version 4.13.0-rc7stmark2-001-00039-g96e88773601f-dirty (angelo@jerusalem) (gcc version 5.2.0 (crosstools-sysam-2016.04.16)) #56 Mon Sep 4 16:19:46 CEST 2017
>> [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16312
>> [    0.000000] Kernel command line: console=ttyS0,115200 root=/dev/ram0 rw rootfstype=ramfs rdinit=/bin/init devtmpfs.mount=1
>> [    0.000000] PID hash table entries: 512 (order: -2, 2048 bytes)
>> [    0.000000] Dentry cache hash table entries: 16384 (order: 3, 65536 bytes)
>> [    0.000000] Inode-cache hash table entries: 8192 (order: 2, 32768 bytes)
>> [    0.000000] Sorting __ex_table...
>> [    0.000000] Memory: 128288K/131072K available (1219K kernel code, 103K rwdata, 288K rodata, 264K init, 79K bss, 2784K reserved, 0K cma-reserved)
>> [    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 - 0x40131cb0   (1220 KiB)
>> [    0.000000]       .data : 0x40131cb0 - 0x40193900   ( 392 KiB)
>> [    0.000000]       .bss  : 0x401d86e0 - 0x401ec680   (  80 KiB)
>> [    0.000000] SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=8
>> [    0.000000] NR_IRQS: 256
>> [    0.000000] clocksource: pit: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1019338904850 ns
>> [    0.000000] Console: colour dummy device 80x25
>> [    0.070000] Calibrating delay loop... 238.38 BogoMIPS (lpj=1191936)
>> [    0.070000] pid_max: default: 32768 minimum: 301
>> [    0.070000] Mount-cache hash table entries: 2048 (order: 0, 8192 bytes)
>> [    0.070000] Mountpoint-cache hash table entries: 2048 (order: 0, 8192 bytes)
>> [    0.080000] devtmpfs: initialized
>> [    0.090000] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
>> [    0.090000] futex hash table entries: 256 (order: -2, 3072 bytes)
>> [    0.110000] clocksource: Switched to clocksource pit
>> [    0.110000] FS-Cache: Loaded
>> [    0.380000] workingset: timestamp_bits=27 max_order=14 bucket_order=0
>> [    0.430000] io scheduler noop registered
>> [    0.430000] io scheduler deadline registered
>> [    0.430000] io scheduler cfq registered (default)
>> [    0.430000] io scheduler mq-deadline registered
>> [    0.430000] io scheduler kyber registered
>> [    0.920000] ColdFire internal UART serial driver
>> [    0.920000] mcfuart.0: ttyS0 at MMIO 0xfc060000 (irq = 90, base_baud = 7500000) is a ColdFire UART
>> [    1.110000] console [ttyS0] enabled
>> [    1.110000] mcfuart.0: ttyS1 at MMIO 0xfc064000 (irq = 91, base_baud = 7500000) is a ColdFire UART
>> [    1.120000] mcfuart.0: ttyS2 at MMIO 0xfc068000 (irq = 92, base_baud = 7500000) is a ColdFire UART
>> [    1.130000] mcfuart.0: ttyS3 at MMIO 0xfc06c000 (irq = 93, base_baud = 7500000) is a ColdFire UART
>> [    1.150000] random: get_random_bytes called from init_oops_id+0x26/0x46 with crng_init=0
>> [    1.160000] Freeing unused kernel memory: 264K
>> [    1.170000] This architecture does not have kernel memory protection.
>> [    1.410000] random: fast init done
>>
>> / #
>>
>>
>>> 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
>>>>
>>>
>>
>> Regards,
>> Angelo
>>
> 

Best regards,
Angelo Dureghello

[-- Attachment #2: 0001-Patch-to-enable-mmu-from-Greg.patch --]
[-- Type: text/x-patch, Size: 4883 bytes --]

>From 9f0e06f9566de4d91a234753cd30160ce02fc8a8 Mon Sep 17 00:00:00 2001
From: Angelo Dureghello <angelo@sysam.it>
Date: Thu, 24 Aug 2017 00:01:06 +0200
Subject: [PATCH 1/2] Patch to enable mmu, from Greg.

Signed-off-by: Angelo Dureghello <angelo@sysam.it>
---
 arch/m68k/Kconfig.cpu               |  2 +-
 arch/m68k/coldfire/m54xx.c          |  4 ----
 arch/m68k/configs/stmark2_defconfig |  5 +++--
 arch/m68k/include/asm/mmu_context.h |  1 -
 arch/m68k/kernel/setup_mm.c         |  1 +
 arch/m68k/mm/mcfmmu.c               | 35 ++++++++++++++++++-----------------
 6 files changed, 23 insertions(+), 25 deletions(-)

diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu
index d2219f30b78f..4dc51c090a45 100644
--- a/arch/m68k/Kconfig.cpu
+++ b/arch/m68k/Kconfig.cpu
@@ -283,7 +283,7 @@ config M548x
 
 config M5441x
 	bool "MCF5441x"
-	depends on !MMU
+	select MMU_COLDFIRE if MMU
 	select GENERIC_CLOCKEVENTS
 	select HAVE_CACHE_CB
 	help
diff --git a/arch/m68k/coldfire/m54xx.c b/arch/m68k/coldfire/m54xx.c
index c552851ec617..704efeaeab2d 100644
--- a/arch/m68k/coldfire/m54xx.c
+++ b/arch/m68k/coldfire/m54xx.c
@@ -95,10 +95,6 @@ static void mcf54xx_reset(void)
 
 void __init config_BSP(char *commandp, int size)
 {
-#ifdef CONFIG_MMU
-	cf_bootmem_alloc();
-	mmu_context_init();
-#endif
 	mach_reset = mcf54xx_reset;
 	mach_sched_init = hw_timer_init;
 	m54xx_uarts_init();
diff --git a/arch/m68k/configs/stmark2_defconfig b/arch/m68k/configs/stmark2_defconfig
index ea78b8f6a68e..b886f303cc3f 100644
--- a/arch/m68k/configs/stmark2_defconfig
+++ b/arch/m68k/configs/stmark2_defconfig
@@ -21,7 +21,7 @@ CONFIG_EMBEDDED=y
 # CONFIG_LBDAF is not set
 # CONFIG_BLK_DEV_BSG is not set
 CONFIG_BLK_CMDLINE_PARSER=y
-# CONFIG_MMU is not set
+CONFIG_COLDFIRE=y
 CONFIG_M5441x=y
 CONFIG_CLOCK_FREQ=240000000
 CONFIG_STMARK2=y
@@ -30,6 +30,8 @@ CONFIG_RAMSIZE=0x8000000
 CONFIG_VECTORBASE=0x40000000
 CONFIG_KERNELBASE=0x40001000
 CONFIG_BINFMT_FLAT=y
+CONFIG_BINFMT_ZFLAT=y
+CONFIG_BINFMT_SHARED_FLAT=y
 CONFIG_BINFMT_MISC=y
 # CONFIG_UEVENT_HELPER is not set
 CONFIG_DEVTMPFS=y
@@ -53,7 +55,6 @@ CONFIG_MTD_COMPLEX_MAPPINGS=y
 CONFIG_MTD_PHYSMAP=y
 CONFIG_MTD_PLATRAM=y
 CONFIG_MTD_SPI_NOR=y
-# CONFIG_INPUT_MOUSEDEV is not set
 # CONFIG_INPUT_KEYBOARD is not set
 # CONFIG_INPUT_MOUSE is not set
 CONFIG_SERIO_LIBPS2=y
diff --git a/arch/m68k/include/asm/mmu_context.h b/arch/m68k/include/asm/mmu_context.h
index 4a6ae6dffa34..00c28b1dc47b 100644
--- a/arch/m68k/include/asm/mmu_context.h
+++ b/arch/m68k/include/asm/mmu_context.h
@@ -91,7 +91,6 @@ static inline void activate_mm(struct mm_struct *active_mm,
 
 #define deactivate_mm(tsk, mm) do { } while (0)
 
-extern void mmu_context_init(void);
 #define prepare_arch_switch(next) load_ksp_mmu(next)
 
 static inline void load_ksp_mmu(struct task_struct *task)
diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c
index 7a2c21212820..5632c48b9f3b 100644
--- a/arch/m68k/kernel/setup_mm.c
+++ b/arch/m68k/kernel/setup_mm.c
@@ -343,6 +343,7 @@ void __init setup_arch(char **cmdline_p)
 #ifdef CONFIG_COLDFIRE
 	case MACH_M54XX:
 	case MACH_M5441X:
+		cf_bootmem_alloc();
 		config_BSP(NULL, 0);
 		break;
 #endif
diff --git a/arch/m68k/mm/mcfmmu.c b/arch/m68k/mm/mcfmmu.c
index 87131cd3bc8f..c7efdf8e8eae 100644
--- a/arch/m68k/mm/mcfmmu.c
+++ b/arch/m68k/mm/mcfmmu.c
@@ -150,6 +150,23 @@ int cf_tlb_miss(struct pt_regs *regs, int write, int dtlb, int extension_word)
 	return 0;
 }
 
+/*
+ * Initialize the context management stuff.
+ * The following was taken from arch/ppc/mmu_context.c
+ */
+static void __init mmu_context_init(void)
+{
+	/*
+	 * Some processors have too few contexts to reserve one for
+	 * init_mm, and require using context 0 for a normal task.
+	 * Other processors reserve the use of context zero for the kernel.
+	 * This code assumes FIRST_CONTEXT < 32.
+	 */
+	context_map[0] = (1 << FIRST_CONTEXT) - 1;
+	next_mmu_context = FIRST_CONTEXT;
+	atomic_set(&nr_free_contexts, LAST_CONTEXT - FIRST_CONTEXT + 1);
+}
+
 void __init cf_bootmem_alloc(void)
 {
 	unsigned long start_pfn;
@@ -177,23 +194,7 @@ void __init cf_bootmem_alloc(void)
 	memstart += init_bootmem_node(NODE_DATA(0), start_pfn,
 		min_low_pfn, max_low_pfn);
 	free_bootmem_node(NODE_DATA(0), memstart, _ramend - memstart);
-}
-
-/*
- * Initialize the context management stuff.
- * The following was taken from arch/ppc/mmu_context.c
- */
-void __init mmu_context_init(void)
-{
-	/*
-	 * Some processors have too few contexts to reserve one for
-	 * init_mm, and require using context 0 for a normal task.
-	 * Other processors reserve the use of context zero for the kernel.
-	 * This code assumes FIRST_CONTEXT < 32.
-	 */
-	context_map[0] = (1 << FIRST_CONTEXT) - 1;
-	next_mmu_context = FIRST_CONTEXT;
-	atomic_set(&nr_free_contexts, LAST_CONTEXT - FIRST_CONTEXT + 1);
+	mmu_context_init();
 }
 
 /*
-- 
2.14.1


[-- Attachment #3: 0002-m68k-fix-mmu-for-coldfire-mcf5441x.patch --]
[-- Type: text/x-patch, Size: 951 bytes --]

>From 9f6deae2b7c4291e792e2b341da461091613b790 Mon Sep 17 00:00:00 2001
From: Angelo Dureghello <angelo@sysam.it>
Date: Sun, 27 Aug 2017 02:42:42 +0200
Subject: [PATCH 2/2] m68k: fix mmu for coldfire mcf5441x

This patch fixes mmu not working for CPU's that has the base of the
physical memory mapped at a non-zero address.

Signed-off-by: Angelo Dureghello <angelo@sysam.it>
---
 arch/m68k/mm/mcfmmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/m68k/mm/mcfmmu.c b/arch/m68k/mm/mcfmmu.c
index c7efdf8e8eae..a79198a7fcab 100644
--- a/arch/m68k/mm/mcfmmu.c
+++ b/arch/m68k/mm/mcfmmu.c
@@ -186,7 +186,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 */
-- 
2.14.1

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

[Greg Ungerer]

Hi Angelo,

On 08/09/17 06:23, Angelo Dureghello wrote:
> On 07/09/2017 04:01, Greg Ungerer wrote:
>> On 05/09/17 00:42, Angelo Dureghello wrote:
>>> On 04/09/2017 08:08, Greg Ungerer wrote:
>>>> 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.
>>>>
>>>>
>>> Great catch, the patch works,
>>
>> Thats great, thanks for trying that out.
>>
>>
>>> i maintaind btw the
>>>
>>> memset(NODE_DATA(node), 0, sizeof(pg_data_t));
>>>
>>> inside void __init m68k_setup_node(int node) since otherwise
>>> there was that warning we've seen initially.
>>
>> Ok, I am not quite sure why you would still need that though.
>> Do you mean the warning about overlaping chunks?  Can you send
>> the exact warning output again running this now?
>>
>>  From the code I would have expected that array area to be in the
>> kernel bss and be zeroed out at system startup. (For what it is
>> worth I don't see that warning on my non-zero based test 5475 test
>> config).
>>
> 
> Sure, my mistake, i just maintained that line and didn't try to
> remove it after your final 1-line patch.
> 
> Just re-tested now, without that memset, all works fine as you was
> expecting, no warnings.
> I attach the 2 progressive patches, the first you sent me initially,
> and this last one, that actually is just 1 line patch.

Great, thanks for your efforts working through this.
I'll send out the patches again as a series for final review.

Regards
Greg



>>> About the "cd" issue, it seems to be a hush issue, maybe
>>> becouse hush is built as nommu. Re-executing hush, i can now cd
>>> to a subfolder, but i get then a SEGV on "cd ..".
>>
>> Yeah, maybe that is related to flat format binaries. Normally I
>> run a uClibc ELF based user space with MMU enabled. I'll try with
>> a FLAT format user space and see if I get any problems.
>>
>> Regards
>> Greg
>>
>>
>>  
>>> This the boot log:
>>>
>>> ## Booting kernel from Legacy Image at 40001000 ...
>>>     Image Name:   mainline kernel
>>>     Created:      2017-09-04  14:19:47 UTC
>>>     Image Type:   M68K Linux Kernel Image (uncompressed)
>>>     Data Size:    1930976 Bytes = 1.8 MiB
>>>     Load Address: 40001000
>>>     Entry Point:  40001000
>>>     Verifying Checksum ... OK
>>>     Loading Kernel Image ... OK
>>> [    0.000000] Linux version 4.13.0-rc7stmark2-001-00039-g96e88773601f-dirty (angelo@jerusalem) (gcc version 5.2.0 (crosstools-sysam-2016.04.16)) #56 Mon Sep 4 16:19:46 CEST 2017
>>> [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16312
>>> [    0.000000] Kernel command line: console=ttyS0,115200 root=/dev/ram0 rw rootfstype=ramfs rdinit=/bin/init devtmpfs.mount=1
>>> [    0.000000] PID hash table entries: 512 (order: -2, 2048 bytes)
>>> [    0.000000] Dentry cache hash table entries: 16384 (order: 3, 65536 bytes)
>>> [    0.000000] Inode-cache hash table entries: 8192 (order: 2, 32768 bytes)
>>> [    0.000000] Sorting __ex_table...
>>> [    0.000000] Memory: 128288K/131072K available (1219K kernel code, 103K rwdata, 288K rodata, 264K init, 79K bss, 2784K reserved, 0K cma-reserved)
>>> [    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 - 0x40131cb0   (1220 KiB)
>>> [    0.000000]       .data : 0x40131cb0 - 0x40193900   ( 392 KiB)
>>> [    0.000000]       .bss  : 0x401d86e0 - 0x401ec680   (  80 KiB)
>>> [    0.000000] SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=8
>>> [    0.000000] NR_IRQS: 256
>>> [    0.000000] clocksource: pit: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1019338904850 ns
>>> [    0.000000] Console: colour dummy device 80x25
>>> [    0.070000] Calibrating delay loop... 238.38 BogoMIPS (lpj=1191936)
>>> [    0.070000] pid_max: default: 32768 minimum: 301
>>> [    0.070000] Mount-cache hash table entries: 2048 (order: 0, 8192 bytes)
>>> [    0.070000] Mountpoint-cache hash table entries: 2048 (order: 0, 8192 bytes)
>>> [    0.080000] devtmpfs: initialized
>>> [    0.090000] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
>>> [    0.090000] futex hash table entries: 256 (order: -2, 3072 bytes)
>>> [    0.110000] clocksource: Switched to clocksource pit
>>> [    0.110000] FS-Cache: Loaded
>>> [    0.380000] workingset: timestamp_bits=27 max_order=14 bucket_order=0
>>> [    0.430000] io scheduler noop registered
>>> [    0.430000] io scheduler deadline registered
>>> [    0.430000] io scheduler cfq registered (default)
>>> [    0.430000] io scheduler mq-deadline registered
>>> [    0.430000] io scheduler kyber registered
>>> [    0.920000] ColdFire internal UART serial driver
>>> [    0.920000] mcfuart.0: ttyS0 at MMIO 0xfc060000 (irq = 90, base_baud = 7500000) is a ColdFire UART
>>> [    1.110000] console [ttyS0] enabled
>>> [    1.110000] mcfuart.0: ttyS1 at MMIO 0xfc064000 (irq = 91, base_baud = 7500000) is a ColdFire UART
>>> [    1.120000] mcfuart.0: ttyS2 at MMIO 0xfc068000 (irq = 92, base_baud = 7500000) is a ColdFire UART
>>> [    1.130000] mcfuart.0: ttyS3 at MMIO 0xfc06c000 (irq = 93, base_baud = 7500000) is a ColdFire UART
>>> [    1.150000] random: get_random_bytes called from init_oops_id+0x26/0x46 with crng_init=0
>>> [    1.160000] Freeing unused kernel memory: 264K
>>> [    1.170000] This architecture does not have kernel memory protection.
>>> [    1.410000] random: fast init done
>>>
>>> / #
>>>
>>>
>>>> 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
>>>>>
>>>>
>>>
>>> Regards,
>>> Angelo
>>>
>>
> 
> Best regards,
> Angelo Dureghello