* SPARSEMEM support for Atmel AT91SAM9G45 and M10
[not found] ` <201005261610.32937.marek.vasut@gmail.com>
@ 2010-05-27 8:15 ` Yegor Yefremov
2010-05-27 15:13 ` Marek Vasut
0 siblings, 1 reply; 3+ messages in thread
From: Yegor Yefremov @ 2010-05-27 8:15 UTC (permalink / raw)
To: linux-arm-kernel
Marek Vasut schrieb:
> Dne St 26. kv?tna 2010 15:46:21 Yegor Yefremov napsal(a):
>>> I'm resurrecting an old thread
>>>
>>> (http://lists.arm.linux.org.uk/lurker/message/20090914.072902.97115112.en
>>> .html) about using the two memory banks available
>>> on Atmel AT91SAM9G45/M10. I managed to make it work on 2.6.30 by
>>> following Russell King advice on how to configure SPARSEMEM.
>>>
>>> I submitted a working patch for 2.6.34 here:
>>> http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6143/1
>>>
>>> The problem is that I'm unsure how to get rid of the #define that
>>> forces high_memory value in mm/init.c, should I add a fixup function
>>> to board-sam9m10g45ek.c to provide meminfo information ?
>> I've already tested the patch on 2.6.33 and it is working properly.
>> Concerning high_memory value problem I think the cause is how
>> find_node_limits() in arch/arm/m/init.c is implemented. We have two memory
>> banks one starting at 0x70000000 and another at 0x200000000. The virtual
>> mapping looks like this:
>>
>> 0x70000000 -> 0xc0000000
>> 0x20000000 -> 0xc8000000
>>
>> However find_node_limits() routine is working with physical addresses so
>> the upper limit is 0x70000000 and not 0x20000000 as it should be. As a
>> result max_low is pointing to 0x70000000 and that's why only first bank
>> will be mapped correctly.
>>
>> How can find_node_limits() be changed to work with virtual addresses?
>>
>> Regards,
>> Yegor
>>
> Hey, try searching for "[PATCH 1/5] pxa/vpac270: Enable SparseMEM for 256 MB of
> RAM" ... The device has also one memory bank mapped under the primary one. Maybe
> that can help. Cheers
Marek, I've looked at patch and apart from defining HIGH_MEMORY_VIRT it does the same. Nevertheless if I don't define HIGH_MEMORY_VIRT I get the following crash (I've added debug string showing calculated high_memory. It should be 0xd0000000 and not 0xc8000000):
Linux version 2.6.33.2 (OpenRISC at VScom) (gcc version 4.3.2 (crosstool-NG-1.3.2)
) #30 Thu May 27 10:06:42 CEST 2010
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: Atmel AT91SAM9G45-EKES
Memory policy: ECC disabled, Data cache writeback
DBG: high_memory 0xc8000000
Clocks: CPU 400 MHz, master 133 MHz, main 12.000 MHz
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 62720
Kernel command line: console=ttyS0,115200 root=/dev/mtdblock2 rootwait
PID hash table entries: 1024 (order: 0, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 128MB 128MB = 256MB total
Memory: 255036KB available (3944K code, 303K data, 140K init, 0K highmem)
Hierarchical RCU implementation.
NR_IRQS:192
AT91: 160 gpio irqs in 5 banks
Console: colour dummy device 80x30
console [ttyS0] enabled
Calibrating delay loop... 199.47 BogoMIPS (lpj=997376)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency:
------------[ cut here ]------------
WARNING: at mm/vmalloc.c:107 vmap_page_range_noflush+0x128/0x1d8()
Modules linked in:
[<c0031894>] (unwind_backtrace+0x0/0xdc) from [<c0043c34>] (warn_slowpath_common+0x4c/0x80)
[<c0043c34>] (warn_slowpath_common+0x4c/0x80) from [<c008df9c>] (vmap_page_range_noflush+0x128/0x1d8)
[<c008df9c>] (vmap_page_range_noflush+0x128/0x1d8) from [<c008e074>] (map_vm_area+0x28/0x50)
[<c008e074>] (map_vm_area+0x28/0x50) from [<c008e4f8>] (vmap+0x48/0x6c)
[<c008e4f8>] (vmap+0x48/0x6c) from [<c000cf60>] (check_writebuffer_bugs+0x5c/0x134)
[<c000cf60>] (check_writebuffer_bugs+0x5c/0x134) from [<c0008b9c>] (start_kernel+0x31c/0x388)
[<c0008b9c>] (start_kernel+0x31c/0x388) from [<70008034>] (0x70008034)
---[ end trace 1b75b31a2719ed1c ]---
------------[ cut here ]------------
WARNING: at mm/vmalloc.c:107 vmap_page_range_noflush+0x128/0x1d8()
Modules linked in:
[<c0031894>] (unwind_backtrace+0x0/0xdc) from [<c0043c34>] (warn_slowpath_common+0x4c/0x80)
[<c0043c34>] (warn_slowpath_common+0x4c/0x80) from [<c008df9c>] (vmap_page_range_noflush+0x128/0x1d8)
[<c008df9c>] (vmap_page_range_noflush+0x128/0x1d8) from [<c008e074>] (map_vm_area+0x28/0x50)
[<c008e074>] (map_vm_area+0x28/0x50) from [<c008e4f8>] (vmap+0x48/0x6c)
[<c008e4f8>] (vmap+0x48/0x6c) from [<c000cf78>] (check_writebuffer_bugs+0x74/0x134)
[<c000cf78>] (check_writebuffer_bugs+0x74/0x134) from [<c0008b9c>] (start_kernel+0x31c/0x388)
[<c0008b9c>] (start_kernel+0x31c/0x388) from [<70008034>] (0x70008034)
---[ end trace 1b75b31a2719ed1d ]---
failed, unable to map memory
Any ideas?
Yegor
^ permalink raw reply [flat|nested] 3+ messages in thread
* SPARSEMEM support for Atmel AT91SAM9G45 and M10
2010-05-27 8:15 ` SPARSEMEM support for Atmel AT91SAM9G45 and M10 Yegor Yefremov
@ 2010-05-27 15:13 ` Marek Vasut
2010-05-28 7:42 ` Yegor Yefremov
0 siblings, 1 reply; 3+ messages in thread
From: Marek Vasut @ 2010-05-27 15:13 UTC (permalink / raw)
To: linux-arm-kernel
Dne ?t 27. kv?tna 2010 10:15:59 Yegor Yefremov napsal(a):
> Marek Vasut schrieb:
> > Dne St 26. kv?tna 2010 15:46:21 Yegor Yefremov napsal(a):
> >>> I'm resurrecting an old thread
> >>>
> >>> (http://lists.arm.linux.org.uk/lurker/message/20090914.072902.97115112.
> >>> en .html) about using the two memory banks available
> >>> on Atmel AT91SAM9G45/M10. I managed to make it work on 2.6.30 by
> >>> following Russell King advice on how to configure SPARSEMEM.
> >>>
> >>> I submitted a working patch for 2.6.34 here:
> >>> http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6143/1
> >>>
> >>> The problem is that I'm unsure how to get rid of the #define that
> >>> forces high_memory value in mm/init.c, should I add a fixup function
> >>> to board-sam9m10g45ek.c to provide meminfo information ?
> >>
> >> I've already tested the patch on 2.6.33 and it is working properly.
> >> Concerning high_memory value problem I think the cause is how
> >> find_node_limits() in arch/arm/m/init.c is implemented. We have two
> >> memory banks one starting at 0x70000000 and another at 0x200000000. The
> >> virtual mapping looks like this:
> >>
> >> 0x70000000 -> 0xc0000000
> >> 0x20000000 -> 0xc8000000
> >>
> >> However find_node_limits() routine is working with physical addresses so
> >> the upper limit is 0x70000000 and not 0x20000000 as it should be. As a
> >> result max_low is pointing to 0x70000000 and that's why only first bank
> >> will be mapped correctly.
> >>
> >> How can find_node_limits() be changed to work with virtual addresses?
> >>
> >> Regards,
> >> Yegor
> >
> > Hey, try searching for "[PATCH 1/5] pxa/vpac270: Enable SparseMEM for 256
> > MB of RAM" ... The device has also one memory bank mapped under the
> > primary one. Maybe that can help. Cheers
>
> Marek, I've looked at patch and apart from defining HIGH_MEMORY_VIRT it
> does the same. Nevertheless if I don't define HIGH_MEMORY_VIRT I get the
> following crash (I've added debug string showing calculated high_memory.
> It should be 0xd0000000 and not 0xc8000000):
>
> Linux version 2.6.33.2 (OpenRISC at VScom) (gcc version 4.3.2
> (crosstool-NG-1.3.2) ) #30 Thu May 27 10:06:42 CEST 2010
> CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
> CPU: VIVT data cache, VIVT instruction cache
> Machine: Atmel AT91SAM9G45-EKES
> Memory policy: ECC disabled, Data cache writeback
> DBG: high_memory 0xc8000000
> Clocks: CPU 400 MHz, master 133 MHz, main 12.000 MHz
> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 62720
> Kernel command line: console=ttyS0,115200 root=/dev/mtdblock2 rootwait
> PID hash table entries: 1024 (order: 0, 4096 bytes)
> Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
> Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
> Memory: 128MB 128MB = 256MB total
> Memory: 255036KB available (3944K code, 303K data, 140K init, 0K highmem)
> Hierarchical RCU implementation.
> NR_IRQS:192
> AT91: 160 gpio irqs in 5 banks
> Console: colour dummy device 80x30
> console [ttyS0] enabled
> Calibrating delay loop... 199.47 BogoMIPS (lpj=997376)
> Mount-cache hash table entries: 512
> CPU: Testing write buffer coherency:
> ------------[ cut here ]------------
> WARNING: at mm/vmalloc.c:107 vmap_page_range_noflush+0x128/0x1d8()
> Modules linked in:
> [<c0031894>] (unwind_backtrace+0x0/0xdc) from [<c0043c34>]
> (warn_slowpath_common+0x4c/0x80) [<c0043c34>]
> (warn_slowpath_common+0x4c/0x80) from [<c008df9c>]
> (vmap_page_range_noflush+0x128/0x1d8) [<c008df9c>]
> (vmap_page_range_noflush+0x128/0x1d8) from [<c008e074>]
> (map_vm_area+0x28/0x50) [<c008e074>] (map_vm_area+0x28/0x50) from
> [<c008e4f8>] (vmap+0x48/0x6c) [<c008e4f8>] (vmap+0x48/0x6c) from
> [<c000cf60>] (check_writebuffer_bugs+0x5c/0x134) [<c000cf60>]
> (check_writebuffer_bugs+0x5c/0x134) from [<c0008b9c>]
> (start_kernel+0x31c/0x388) [<c0008b9c>] (start_kernel+0x31c/0x388) from
> [<70008034>] (0x70008034) ---[ end trace 1b75b31a2719ed1c ]---
> ------------[ cut here ]------------
> WARNING: at mm/vmalloc.c:107 vmap_page_range_noflush+0x128/0x1d8()
> Modules linked in:
> [<c0031894>] (unwind_backtrace+0x0/0xdc) from [<c0043c34>]
> (warn_slowpath_common+0x4c/0x80) [<c0043c34>]
> (warn_slowpath_common+0x4c/0x80) from [<c008df9c>]
> (vmap_page_range_noflush+0x128/0x1d8) [<c008df9c>]
> (vmap_page_range_noflush+0x128/0x1d8) from [<c008e074>]
> (map_vm_area+0x28/0x50) [<c008e074>] (map_vm_area+0x28/0x50) from
> [<c008e4f8>] (vmap+0x48/0x6c) [<c008e4f8>] (vmap+0x48/0x6c) from
> [<c000cf78>] (check_writebuffer_bugs+0x74/0x134) [<c000cf78>]
> (check_writebuffer_bugs+0x74/0x134) from [<c0008b9c>]
> (start_kernel+0x31c/0x388) [<c0008b9c>] (start_kernel+0x31c/0x388) from
> [<70008034>] (0x70008034) ---[ end trace 1b75b31a2719ed1d ]---
> failed, unable to map memory
>
> Any ideas?
>
> Yegor
Do you have CONFIG_HIGHMEM enabled ? If so, why ?
^ permalink raw reply [flat|nested] 3+ messages in thread
* SPARSEMEM support for Atmel AT91SAM9G45 and M10
2010-05-27 15:13 ` Marek Vasut
@ 2010-05-28 7:42 ` Yegor Yefremov
0 siblings, 0 replies; 3+ messages in thread
From: Yegor Yefremov @ 2010-05-28 7:42 UTC (permalink / raw)
To: linux-arm-kernel
Marek Vasut schrieb:
> Dne ?t 27. kv?tna 2010 10:15:59 Yegor Yefremov napsal(a):
>> Marek Vasut schrieb:
>>> Dne St 26. kv?tna 2010 15:46:21 Yegor Yefremov napsal(a):
>>>>> I'm resurrecting an old thread
>>>>>
>>>>> (http://lists.arm.linux.org.uk/lurker/message/20090914.072902.97115112.
>>>>> en .html) about using the two memory banks available
>>>>> on Atmel AT91SAM9G45/M10. I managed to make it work on 2.6.30 by
>>>>> following Russell King advice on how to configure SPARSEMEM.
>>>>>
>>>>> I submitted a working patch for 2.6.34 here:
>>>>> http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6143/1
>>>>>
>>>>> The problem is that I'm unsure how to get rid of the #define that
>>>>> forces high_memory value in mm/init.c, should I add a fixup function
>>>>> to board-sam9m10g45ek.c to provide meminfo information ?
>>>> I've already tested the patch on 2.6.33 and it is working properly.
>>>> Concerning high_memory value problem I think the cause is how
>>>> find_node_limits() in arch/arm/m/init.c is implemented. We have two
>>>> memory banks one starting at 0x70000000 and another at 0x200000000. The
>>>> virtual mapping looks like this:
>>>>
>>>> 0x70000000 -> 0xc0000000
>>>> 0x20000000 -> 0xc8000000
>>>>
>>>> However find_node_limits() routine is working with physical addresses so
>>>> the upper limit is 0x70000000 and not 0x20000000 as it should be. As a
>>>> result max_low is pointing to 0x70000000 and that's why only first bank
>>>> will be mapped correctly.
>>>>
>>>> How can find_node_limits() be changed to work with virtual addresses?
>>>>
>>>> Regards,
>>>> Yegor
>>> Hey, try searching for "[PATCH 1/5] pxa/vpac270: Enable SparseMEM for 256
>>> MB of RAM" ... The device has also one memory bank mapped under the
>>> primary one. Maybe that can help. Cheers
>> Marek, I've looked at patch and apart from defining HIGH_MEMORY_VIRT it
>> does the same. Nevertheless if I don't define HIGH_MEMORY_VIRT I get the
>> following crash (I've added debug string showing calculated high_memory.
>> It should be 0xd0000000 and not 0xc8000000):
>>
>> Linux version 2.6.33.2 (OpenRISC at VScom) (gcc version 4.3.2
>> (crosstool-NG-1.3.2) ) #30 Thu May 27 10:06:42 CEST 2010
>> CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
>> CPU: VIVT data cache, VIVT instruction cache
>> Machine: Atmel AT91SAM9G45-EKES
>> Memory policy: ECC disabled, Data cache writeback
>> DBG: high_memory 0xc8000000
>> Clocks: CPU 400 MHz, master 133 MHz, main 12.000 MHz
>> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 62720
>> Kernel command line: console=ttyS0,115200 root=/dev/mtdblock2 rootwait
>> PID hash table entries: 1024 (order: 0, 4096 bytes)
>> Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
>> Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
>> Memory: 128MB 128MB = 256MB total
>> Memory: 255036KB available (3944K code, 303K data, 140K init, 0K highmem)
>> Hierarchical RCU implementation.
>> NR_IRQS:192
>> AT91: 160 gpio irqs in 5 banks
>> Console: colour dummy device 80x30
>> console [ttyS0] enabled
>> Calibrating delay loop... 199.47 BogoMIPS (lpj=997376)
>> Mount-cache hash table entries: 512
>> CPU: Testing write buffer coherency:
>> ------------[ cut here ]------------
>> WARNING: at mm/vmalloc.c:107 vmap_page_range_noflush+0x128/0x1d8()
>> Modules linked in:
>> [<c0031894>] (unwind_backtrace+0x0/0xdc) from [<c0043c34>]
>> (warn_slowpath_common+0x4c/0x80) [<c0043c34>]
>> (warn_slowpath_common+0x4c/0x80) from [<c008df9c>]
>> (vmap_page_range_noflush+0x128/0x1d8) [<c008df9c>]
>> (vmap_page_range_noflush+0x128/0x1d8) from [<c008e074>]
>> (map_vm_area+0x28/0x50) [<c008e074>] (map_vm_area+0x28/0x50) from
>> [<c008e4f8>] (vmap+0x48/0x6c) [<c008e4f8>] (vmap+0x48/0x6c) from
>> [<c000cf60>] (check_writebuffer_bugs+0x5c/0x134) [<c000cf60>]
>> (check_writebuffer_bugs+0x5c/0x134) from [<c0008b9c>]
>> (start_kernel+0x31c/0x388) [<c0008b9c>] (start_kernel+0x31c/0x388) from
>> [<70008034>] (0x70008034) ---[ end trace 1b75b31a2719ed1c ]---
>> ------------[ cut here ]------------
>> WARNING: at mm/vmalloc.c:107 vmap_page_range_noflush+0x128/0x1d8()
>> Modules linked in:
>> [<c0031894>] (unwind_backtrace+0x0/0xdc) from [<c0043c34>]
>> (warn_slowpath_common+0x4c/0x80) [<c0043c34>]
>> (warn_slowpath_common+0x4c/0x80) from [<c008df9c>]
>> (vmap_page_range_noflush+0x128/0x1d8) [<c008df9c>]
>> (vmap_page_range_noflush+0x128/0x1d8) from [<c008e074>]
>> (map_vm_area+0x28/0x50) [<c008e074>] (map_vm_area+0x28/0x50) from
>> [<c008e4f8>] (vmap+0x48/0x6c) [<c008e4f8>] (vmap+0x48/0x6c) from
>> [<c000cf78>] (check_writebuffer_bugs+0x74/0x134) [<c000cf78>]
>> (check_writebuffer_bugs+0x74/0x134) from [<c0008b9c>]
>> (start_kernel+0x31c/0x388) [<c0008b9c>] (start_kernel+0x31c/0x388) from
>> [<70008034>] (0x70008034) ---[ end trace 1b75b31a2719ed1d ]---
>> failed, unable to map memory
>>
>> Any ideas?
>>
>> Yegor
>
> Do you have CONFIG_HIGHMEM enabled ? If so, why ?
No, I don't. Could you post your bootlog and your .config?
#
# Kernel Features
#
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_HZ=100
CONFIG_AEABI=y
CONFIG_OABI_COMPAT=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
# CONFIG_HIGHMEM is not set
CONFIG_SELECT_MEMORY_MODEL=y
# CONFIG_FLATMEM_MANUAL is not set
# CONFIG_DISCONTIGMEM_MANUAL is not set
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_HAVE_MEMORY_PRESENT=y
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_SPLIT_PTLOCK_CPUS=999999
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=0
CONFIG_VIRT_TO_BUS=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
# CONFIG_LEDS is not set
CONFIG_ALIGNMENT_TRAP=y
# CONFIG_UACCESS_WITH_MEMCPY is not set
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2010-05-28 7:42 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <AANLkTin3-rqG2o0t4rbggpCE2cFAV6GWeH0v7UjC1tnQ@mail.gmail.com>
[not found] ` <4BFD262D.1010308@visionsystems.de>
[not found] ` <201005261610.32937.marek.vasut@gmail.com>
2010-05-27 8:15 ` SPARSEMEM support for Atmel AT91SAM9G45 and M10 Yegor Yefremov
2010-05-27 15:13 ` Marek Vasut
2010-05-28 7:42 ` Yegor Yefremov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).