* Re:[PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled @ 2017-07-14 23:21 Angelo Dureghello 2017-07-14 23:47 ` [PATCH] " Angelo Dureghello 0 siblings, 1 reply; 30+ messages in thread From: Angelo Dureghello @ 2017-07-14 23:21 UTC (permalink / raw) To: Linux/m68k 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] ^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled 2017-07-14 23:21 Re:[PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled Angelo Dureghello @ 2017-07-14 23:47 ` Angelo Dureghello 2017-08-09 13:04 ` Greg Ungerer 0 siblings, 1 reply; 30+ messages in thread From: Angelo Dureghello @ 2017-07-14 23:47 UTC (permalink / raw) To: Linux/m68k 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled 2017-07-14 23:47 ` [PATCH] " Angelo Dureghello @ 2017-08-09 13:04 ` Greg Ungerer 2017-08-09 15:32 ` Angelo Dureghello 0 siblings, 1 reply; 30+ messages in thread From: Greg Ungerer @ 2017-08-09 13:04 UTC (permalink / raw) To: Angelo Dureghello, Linux/m68k 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled 2017-08-09 13:04 ` Greg Ungerer @ 2017-08-09 15:32 ` Angelo Dureghello 2017-08-10 7:06 ` Greg Ungerer 0 siblings, 1 reply; 30+ messages in thread From: Angelo Dureghello @ 2017-08-09 15:32 UTC (permalink / raw) To: Linux/m68k; +Cc: Greg Ungerer 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled 2017-08-09 15:32 ` Angelo Dureghello @ 2017-08-10 7:06 ` Greg Ungerer 2017-08-12 11:17 ` Angelo Dureghello 2017-08-13 1:15 ` Angelo Dureghello 0 siblings, 2 replies; 30+ messages in thread From: Greg Ungerer @ 2017-08-10 7:06 UTC (permalink / raw) To: Angelo Dureghello, Linux/m68k [-- 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--; ^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled 2017-08-10 7:06 ` Greg Ungerer @ 2017-08-12 11:17 ` Angelo Dureghello 2017-08-14 4:16 ` Greg Ungerer 2017-08-13 1:15 ` Angelo Dureghello 1 sibling, 1 reply; 30+ messages in thread From: Angelo Dureghello @ 2017-08-12 11:17 UTC (permalink / raw) To: Greg Ungerer, Linux/m68k 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 > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled 2017-08-12 11:17 ` Angelo Dureghello @ 2017-08-14 4:16 ` Greg Ungerer 2017-08-17 15:02 ` Angelo Dureghello 0 siblings, 1 reply; 30+ messages in thread From: Greg Ungerer @ 2017-08-14 4:16 UTC (permalink / raw) To: Angelo Dureghello, Linux/m68k [-- 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(); } /* ^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled 2017-08-14 4:16 ` Greg Ungerer @ 2017-08-17 15:02 ` Angelo Dureghello 2017-08-20 12:44 ` Greg Ungerer 0 siblings, 1 reply; 30+ messages in thread From: Angelo Dureghello @ 2017-08-17 15:02 UTC (permalink / raw) To: Greg Ungerer, Linux/m68k 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled 2017-08-17 15:02 ` Angelo Dureghello @ 2017-08-20 12:44 ` Greg Ungerer 2017-08-20 13:26 ` Angelo Dureghello 0 siblings, 1 reply; 30+ messages in thread From: Greg Ungerer @ 2017-08-20 12:44 UTC (permalink / raw) To: Angelo Dureghello, Linux/m68k 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled 2017-08-20 12:44 ` Greg Ungerer @ 2017-08-20 13:26 ` Angelo Dureghello 2017-08-21 7:15 ` Greg Ungerer 0 siblings, 1 reply; 30+ messages in thread From: Angelo Dureghello @ 2017-08-20 13:26 UTC (permalink / raw) To: Greg Ungerer, Linux/m68k 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 > > > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled 2017-08-20 13:26 ` Angelo Dureghello @ 2017-08-21 7:15 ` Greg Ungerer 2017-08-21 14:58 ` Angelo Dureghello 2017-08-22 0:35 ` Angelo Dureghello 0 siblings, 2 replies; 30+ messages in thread From: Greg Ungerer @ 2017-08-21 7:15 UTC (permalink / raw) To: Angelo Dureghello, Linux/m68k [-- 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); ^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled 2017-08-21 7:15 ` Greg Ungerer @ 2017-08-21 14:58 ` Angelo Dureghello 2017-08-21 20:11 ` Geert Uytterhoeven 2017-08-22 0:35 ` Angelo Dureghello 1 sibling, 1 reply; 30+ messages in thread From: Angelo Dureghello @ 2017-08-21 14:58 UTC (permalink / raw) To: Greg Ungerer, Linux/m68k [-- 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); ^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled 2017-08-21 14:58 ` Angelo Dureghello @ 2017-08-21 20:11 ` Geert Uytterhoeven 2017-08-22 0:15 ` Angelo Dureghello 0 siblings, 1 reply; 30+ messages in thread From: Geert Uytterhoeven @ 2017-08-21 20:11 UTC (permalink / raw) To: Angelo Dureghello; +Cc: Greg Ungerer, Linux/m68k 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled 2017-08-21 20:11 ` Geert Uytterhoeven @ 2017-08-22 0:15 ` Angelo Dureghello 0 siblings, 0 replies; 30+ messages in thread From: Angelo Dureghello @ 2017-08-22 0:15 UTC (permalink / raw) Cc: Geert Uytterhoeven, Linux/m68k 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 > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled 2017-08-21 7:15 ` Greg Ungerer 2017-08-21 14:58 ` Angelo Dureghello @ 2017-08-22 0:35 ` Angelo Dureghello 2017-08-22 1:08 ` Greg Ungerer 2017-08-23 7:06 ` Greg Ungerer 1 sibling, 2 replies; 30+ messages in thread From: Angelo Dureghello @ 2017-08-22 0:35 UTC (permalink / raw) To: Greg Ungerer, Linux/m68k 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled 2017-08-22 0:35 ` Angelo Dureghello @ 2017-08-22 1:08 ` Greg Ungerer 2017-08-23 7:06 ` Greg Ungerer 1 sibling, 0 replies; 30+ messages in thread From: Greg Ungerer @ 2017-08-22 1:08 UTC (permalink / raw) To: Angelo Dureghello, Linux/m68k 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled 2017-08-22 0:35 ` Angelo Dureghello 2017-08-22 1:08 ` Greg Ungerer @ 2017-08-23 7:06 ` Greg Ungerer 2017-08-27 0:31 ` Angelo Dureghello 1 sibling, 1 reply; 30+ messages in thread From: Greg Ungerer @ 2017-08-23 7:06 UTC (permalink / raw) To: Angelo Dureghello, Linux/m68k [-- 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); ^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled 2017-08-23 7:06 ` Greg Ungerer @ 2017-08-27 0:31 ` Angelo Dureghello 2017-08-31 22:38 ` Angelo Dureghello 0 siblings, 1 reply; 30+ messages in thread From: Angelo Dureghello @ 2017-08-27 0:31 UTC (permalink / raw) To: Greg Ungerer, Linux/m68k 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 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled 2017-08-27 0:31 ` Angelo Dureghello @ 2017-08-31 22:38 ` Angelo Dureghello 2017-09-01 7:49 ` Geert Uytterhoeven 0 siblings, 1 reply; 30+ messages in thread From: Angelo Dureghello @ 2017-08-31 22:38 UTC (permalink / raw) To: Greg Ungerer, Linux/m68k [-- 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 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled 2017-08-31 22:38 ` Angelo Dureghello @ 2017-09-01 7:49 ` Geert Uytterhoeven 2017-09-01 13:21 ` Greg Ungerer 0 siblings, 1 reply; 30+ messages in thread From: Geert Uytterhoeven @ 2017-09-01 7:49 UTC (permalink / raw) To: Angelo Dureghello; +Cc: Greg Ungerer, Linux/m68k 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled 2017-09-01 7:49 ` Geert Uytterhoeven @ 2017-09-01 13:21 ` Greg Ungerer 2017-09-01 13:30 ` Geert Uytterhoeven 0 siblings, 1 reply; 30+ messages in thread From: Greg Ungerer @ 2017-09-01 13:21 UTC (permalink / raw) To: Geert Uytterhoeven, Angelo Dureghello; +Cc: Linux/m68k 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 > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled 2017-09-01 13:21 ` Greg Ungerer @ 2017-09-01 13:30 ` Geert Uytterhoeven 2017-09-01 22:08 ` Angelo Dureghello 0 siblings, 1 reply; 30+ messages in thread From: Geert Uytterhoeven @ 2017-09-01 13:30 UTC (permalink / raw) To: Greg Ungerer; +Cc: Angelo Dureghello, Linux/m68k 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled 2017-09-01 13:30 ` Geert Uytterhoeven @ 2017-09-01 22:08 ` Angelo Dureghello 2017-09-04 6:08 ` Greg Ungerer 0 siblings, 1 reply; 30+ messages in thread From: Angelo Dureghello @ 2017-09-01 22:08 UTC (permalink / raw) To: Geert Uytterhoeven, Greg Ungerer; +Cc: Linux/m68k 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled 2017-09-01 22:08 ` Angelo Dureghello @ 2017-09-04 6:08 ` Greg Ungerer 2017-09-04 14:42 ` Angelo Dureghello 0 siblings, 1 reply; 30+ messages in thread From: Greg Ungerer @ 2017-09-04 6:08 UTC (permalink / raw) To: Angelo Dureghello, Geert Uytterhoeven; +Cc: Linux/m68k [-- 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 */ ^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled 2017-09-04 6:08 ` Greg Ungerer @ 2017-09-04 14:42 ` Angelo Dureghello 2017-09-07 2:01 ` Greg Ungerer 0 siblings, 1 reply; 30+ messages in thread From: Angelo Dureghello @ 2017-09-04 14:42 UTC (permalink / raw) To: Greg Ungerer, Geert Uytterhoeven; +Cc: Linux/m68k 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled 2017-09-04 14:42 ` Angelo Dureghello @ 2017-09-07 2:01 ` Greg Ungerer 2017-09-07 20:23 ` Angelo Dureghello 0 siblings, 1 reply; 30+ messages in thread From: Greg Ungerer @ 2017-09-07 2:01 UTC (permalink / raw) To: Angelo Dureghello, Geert Uytterhoeven; +Cc: Linux/m68k 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 > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled 2017-09-07 2:01 ` Greg Ungerer @ 2017-09-07 20:23 ` Angelo Dureghello 2017-09-08 0:48 ` Greg Ungerer 0 siblings, 1 reply; 30+ messages in thread From: Angelo Dureghello @ 2017-09-07 20:23 UTC (permalink / raw) To: Greg Ungerer, Geert Uytterhoeven; +Cc: Linux/m68k [-- 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 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled 2017-09-07 20:23 ` Angelo Dureghello @ 2017-09-08 0:48 ` Greg Ungerer 0 siblings, 0 replies; 30+ messages in thread From: Greg Ungerer @ 2017-09-08 0:48 UTC (permalink / raw) To: Angelo Dureghello, Geert Uytterhoeven; +Cc: Linux/m68k 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled 2017-08-10 7:06 ` Greg Ungerer 2017-08-12 11:17 ` Angelo Dureghello @ 2017-08-13 1:15 ` Angelo Dureghello 1 sibling, 0 replies; 30+ messages in thread From: Angelo Dureghello @ 2017-08-13 1:15 UTC (permalink / raw) To: Greg Ungerer, Linux/m68k 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 > ^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled @ 2017-01-11 11:35 Greg Ungerer 0 siblings, 0 replies; 30+ messages in thread From: Greg Ungerer @ 2017-01-11 11:35 UTC (permalink / raw) To: linux-m68k; +Cc: Greg Ungerer 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 ^ permalink raw reply related [flat|nested] 30+ messages in thread
end of thread, other threads:[~2017-09-08 0:48 UTC | newest] Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-07-14 23:21 Re:[PATCH] m68k: allow ColdFire m5441x parts to run with MMU enabled Angelo Dureghello 2017-07-14 23:47 ` [PATCH] " Angelo Dureghello 2017-08-09 13:04 ` Greg Ungerer 2017-08-09 15:32 ` Angelo Dureghello 2017-08-10 7:06 ` Greg Ungerer 2017-08-12 11:17 ` Angelo Dureghello 2017-08-14 4:16 ` Greg Ungerer 2017-08-17 15:02 ` Angelo Dureghello 2017-08-20 12:44 ` Greg Ungerer 2017-08-20 13:26 ` Angelo Dureghello 2017-08-21 7:15 ` Greg Ungerer 2017-08-21 14:58 ` Angelo Dureghello 2017-08-21 20:11 ` Geert Uytterhoeven 2017-08-22 0:15 ` Angelo Dureghello 2017-08-22 0:35 ` Angelo Dureghello 2017-08-22 1:08 ` Greg Ungerer 2017-08-23 7:06 ` Greg Ungerer 2017-08-27 0:31 ` Angelo Dureghello 2017-08-31 22:38 ` Angelo Dureghello 2017-09-01 7:49 ` Geert Uytterhoeven 2017-09-01 13:21 ` Greg Ungerer 2017-09-01 13:30 ` Geert Uytterhoeven 2017-09-01 22:08 ` Angelo Dureghello 2017-09-04 6:08 ` Greg Ungerer 2017-09-04 14:42 ` Angelo Dureghello 2017-09-07 2:01 ` Greg Ungerer 2017-09-07 20:23 ` Angelo Dureghello 2017-09-08 0:48 ` Greg Ungerer 2017-08-13 1:15 ` Angelo Dureghello -- strict thread matches above, loose matches on Subject: below -- 2017-01-11 11:35 Greg Ungerer
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.