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