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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxx> wrote:
On 01/09/17 17:49, Geert Uytterhoeven wrote:
On Fri, Sep 1, 2017 at 12:38 AM, Angelo Dureghello <angelo@xxxxxxxx>
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@xxxxxxxxxxxxxx

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Regards,
Angelo



Regards,
Angelo



Best regards,
Angelo Dureghello
From 9f0e06f9566de4d91a234753cd30160ce02fc8a8 Mon Sep 17 00:00:00 2001
From: Angelo Dureghello <angelo@xxxxxxxx>
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@xxxxxxxx>
---
 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

From 9f6deae2b7c4291e792e2b341da461091613b790 Mon Sep 17 00:00:00 2001
From: Angelo Dureghello <angelo@xxxxxxxx>
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@xxxxxxxx>
---
 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


[Index of Archives]     [Video for Linux]     [Yosemite News]     [Linux S/390]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux