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@xxxxxxxxxxxxxx> wrote:
On 01/09/17 17:49, Geert Uytterhoeven wrote:
On Fri, Sep 1, 2017 at 12:38 AM, Angelo Dureghello <angelo@xxxxxxxx>
wrote:
did some additional study and tests.
Actually i cannot find any simpler patch, i just adjusted it a
bit. I believe this patch will work on your cpu with 0-based
memoryas well.
I attach it for your comments.
I think your issue is caused by arch/m68k/include/asm/page_offset.h:
#if defined(CONFIG_RAMBASE)
#define PAGE_OFFSET_RAW CONFIG_RAMBASE
#elif defined(CONFIG_SUN3)
#define PAGE_OFFSET_RAW 0x0E000000
#else
#define PAGE_OFFSET_RAW 0x00000000
#endif
and arch/m68k/Kconfig.machine:
if !MMU || COLDFIRE
config RAMBASE
hex "Address of the base of RAM"
default "0"
So on MC680[2346]0 with MMU (and ignoring Sun-3, which is special),
PAGE_OFFSET == PAGE_OFFSET_RAW == 0.
On Greg's zero-based Coldfire with MMU, CONFIG_RAMBASE is zero, and thus
PAGE_OFFSET is also zero.
On your board CONFIG_RAMBASE is non-zero, hence PAGE_OFFSET is also
non-zero,
and thus you have to compensate for that, cfr. your second patch.
Does it work if you force PAGE_OFFSET_RAW to zero?
If yes, we either need:
--- a/arch/m68k/include/asm/page_offset.h
+++ b/arch/m68k/include/asm/page_offset.h
@@ -1,6 +1,6 @@
/* This handles the memory map.. */
-#if defined(CONFIG_RAMBASE)
+#if !defined(CONFIG_MMU)
#define PAGE_OFFSET_RAW CONFIG_RAMBASE
#elif defined(CONFIG_SUN3)
#define PAGE_OFFSET_RAW 0x0E000000
I tested this patch, (removed mine) and kernel hangs somewhere silently at
first init, i don't have the debug enabled now, but i suspect it still
hangs at some initial "memset" since 0 area for kernel should
be allocated before access.
Isn't PAGE_OFFSET the starting area for the virtual kernel address space ?
At least so it seems to be for the famous 3G + 1G of x86.
Well, for the current working ColdFire with MMU that is the case.
The kernel virtual addresses start at 0...
This is what i see at boot with my patch of yesterday:
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0x40000000 - 0x40000400 ( 1 KiB)
[ 0.000000] kmap : 0xe0000000 - 0xf0000000 ( 256 MiB)
[ 0.000000] vmalloc : 0xd0000000 - 0xe0000000 ( 256 MiB)
[ 0.000000] lowmem : 0x40000000 - 0x48000000 ( 128 MiB)
[ 0.000000] .init : 0x40196000 - 0x401d8000 ( 264 KiB)
[ 0.000000] .text : 0x40001000 - 0x40131e70 (1220 KiB)
[ 0.000000] .data : 0x40131e70 - 0x40193900 ( 391 KiB)
[ 0.000000] .bss : 0x401d86d8 - 0x401ec680 ( 80 KiB)
For whatever it is worth this is what I see now on my debug setup:
Virtual kernel memory layout:
vector : 0x02000000 - 0x02000400 ( 1 KiB)
kmap : 0xe0000000 - 0xf0000000 ( 256 MiB)
vmalloc : 0xd0000000 - 0xe0000000 ( 256 MiB)
lowmem : 0x02000000 - 0x04000000 ( 32 MiB)
.init : 0x02288000 - 0x02296000 ( 56 KiB)
.text : 0x02020000 - 0x0221f270 (2045 KiB)
.data : 0x0221f270 - 0x02284140 ( 404 KiB)
.bss : 0x022967a0 - 0x022ae60c ( 96 KiB)
Regards
Greg
or
--- a/arch/m68k/Kconfig.machine
+++ b/arch/m68k/Kconfig.machine
@@ -325,6 +325,7 @@ comment "RAM configuration"
config RAMBASE
hex "Address of the base of RAM"
+ depends on MMU
Did you mean "depends on !MMU" here?
Sorry, yes, depends on !MMU.
depending on whether anything else in the Coldfire code needs RAMBASE.
There are a couple of places we depend on CONFIG_RAMBASE even
when running with the MMU enabled. Most importantly in setting
the cachable regions in arch/m68k/include/asm/m54xxacr.h.
So this is probably not going to work on its own.
OK, as I already feared/expected...
But the first patch above should be ok. It should certainly work on
my 0 address base 5475 ColdFire setup. Angelo can you try that one?
Right.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Regards,
Angelo
Regards,
Angelo
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
