Re: ARM Paging Problems

[Stephen Lim <lim.stephen.ryan@xxxxxxxxx>]

Hello,

No, the memory was seen as it should. The memory line you are seeing
is a kernel message, I cant quite remember if I added that in myself
for testing or if it was apart of the Kernel originally.


But in any event, my problems were answered by Russell.

Unfortunately I accidentally began a new thread as the subject line
was different.

See for the solution:

http://lists.arm.linux.org.uk/lurker/message/20090617.211614.9e9f0a05.en.html

The memory nodes and banks/segments weren't being numbered correctly.
The Node ID's for the memory layout weren't being generated correctly.

Every other 2 banks/segments were given the NodeID's of the previous two.

The problem was due to the ARM-Linux kernel code. It did not correctly
map the memory layout.

I've fixed the problem for my specific memory layout however, the more
generic solution seems to be to discontinue using discontig. memory
features and migrate to a Linux Kernel that fully supports sparsemem.

Thanks for everyones help though, it was greatly appreciated.

~ Stephen

On Fri, Jun 19, 2009 at 12:35 AM, Ramprasad B<ramprasad@xxxxxxxxxxxxx> wrote:
> Hi Stephen Lim ,
>   Have you made the changes for  CAS and RAS for the memory in the boot
> loader. I think your memory is not been seen as it has to.Please check
>  memory setting.
> Why are you seeing the memory blocks as 4Mx16,have you configured  like
> this.
> " Memory: 4MB 4MB 4MB 4MB 4MB 4MB 4MB 4MB 4MB 4MB 4MB 4MB 4MB 4MB 4MB  4MB =
> 64MB total"
>
>
> Could you check this.This may give you some info.
>
> Thanks.
> Ramprasad.
>>
>> The flash file system is free of corruption.
>>
>>
>> The mem parameter doesn't seem to help any. The kernel fully
>> recognizes the existence of 64MB's of memory without the parameter,
>> and I'm not really too concerned with reserving anything. The problem
>> was that the system worked fine when the RAM was 32MB's and the flash
>> was 16MB's.
>>
>>
>> The 64MB memory module should work - its been tested several times.
>> The flash system has to be working - otherwise the kernel *might* not
>> even be copied into RAM for execution. The JFFS can acquire the
>> directories and inodes which makes me believe the file system is
>> behaving as it should.
>>
>>
>> Hence why I'm a bit lost.
>>
>>
>> The following is the console output:
>>
>>
>> -----------------------------------------------------------------------------
>>
>> NOR flash  32MiB total, 1024B write buffer
>>
>>
>> APEX Boot Loader 1.3.2 -- Copyright (c) 2004,2005 Marc Singer
>>
>> APEX comes with ABSOLUTELY NO WARRANTY.  It is free software and you
>> are welcome to redistribute it under certain circumstances.
>> For details, refer to the file COPYING in the program source.
>>
>>  apex => mem:0xcd000000+0x3317c   (209276 bytes)
>>  env  => nor:128k+64k
>>
>> Use the command 'help help' to get started.
>>
>> # copy jffs2:/.kernel/zImage 0xc1000000
>> caching jffs2 filesystem[33030144]: 358 directory nodes 2506 inodes nodes
>> 785972 bytes transferred
>> # wait 5 Press ^C to cancel autoboot.
>> Press ^C to cancel autoboot.
>> # boot
>> Booting kernel at 0xc1000000...
>> Uncompressing Linux....................................................
>> done, booting the kernel.
>> Linux version 2.6.12-arm1 (bob@kramer) (gcc version 3.4.1) #449 Tue
>> Oct 16 15:03:02 EDT 2007
>> CPU: ARM922Tid(wb) [41029220] revision 0 (ARMv4T)
>> CPU0: D VIVT write-back cache
>> CPU0: I cache: 8192 bytes, associativity 64, 32 byte lines, 4 sets
>> CPU0: D cache: 8192 bytes, associativity 64, 32 byte lines, 4 sets
>> Machine: Logic Product Development LPD7A404-10
>> Memory policy: ECC disabled, Data cache writeback
>> Built 4 zonelists
>> Kernel command line: console=ttyAM1 root=mtd:root rootfstype=jffs2
>> mtdparts=phys_mapped_flash:0x40000(boot)ro,-(root)
>> PID hash table entries: 512 (order: 9, 8192 bytes)
>> Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
>> Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
>> Memory: 4MB 4MB 4MB 4MB 4MB 4MB 4MB 4MB 4MB 4MB 4MB 4MB 4MB 4MB 4MB
>> 4MB = 64MB total
>> Memory: 61724KB available (1403K code, 481K data, 68K init)
>> Mount-cache hash table entries: 512
>> CPU: Testing write buffer coherency: ok
>> NET: Registered protocol family 16
>> NetWinder Floating Point Emulator V0.97 (double precision)
>> JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
>> serial: LH7A40X serial driver
>> ttyAM0 at MMIO 0x80000600 (irq = 38) is a LH7A40X
>> ttyAM1 at MMIO 0x80000700 (irq = 40) is a LH7A40X
>> ttyAM2 at MMIO 0x80000800 (irq = 42) is a LH7A40X
>> io scheduler noop registered
>> io scheduler deadline registered
>> loop: loaded (max 8 devices)
>> nbd: registered device at major 43
>> physmap flash device: 4000000 at 8000000
>> +++ mtd_do_chip_probe : with [CFI]
>> phys_mapped_flash: Found 1 x16 devices at 0x0 in 16-bit bank
>>  Intel/Sharp Extended Query Table at 0x0031
>> Using buffer write method
>> cfi_cmdset_0001: Erase suspend on write enabled
>> 2 cmdlinepart partitions found on MTD device phys_mapped_flash
>> Creating 2 MTD partitions on "phys_mapped_flash":
>> 0x00000000-0x00040000 : "boot"
>> 0x00040000-0x02000000 : "root"
>> NET: Registered protocol family 2
>> IP: routing cache hash table of 512 buckets, 4Kbytes
>> TCP established hash table entries: 4096 (order: 3, 32768 bytes)
>> TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
>> TCP: Hash tables configured (established 4096 bind 4096)
>> ip_tables: (C) 2000-2002 Netfilter core team
>> arp_tables: (C) 2002 David S. Miller
>> NET: Registered protocol family 1
>> NET: Registered protocol family 17
>> NET: Registered protocol family 15
>> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0045dea8:
>> 0x1a1a instead
>> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0045deac:
>> 0x1a1a instead
>> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0045deb0:
>> 0x1a1a instead
>> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0045deb4:
>> 0x1a1a instead
>> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0045deb8:
>> 0x1a1a instead
>> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0045debc:
>> 0x1a1a instead
>> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0045dec0:
>> 0x1a1a instead
>> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0045dec4:
>> 0x1a1a instead
>> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0045dec8:
>> 0x1a1a instead
>> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0045decc:
>> 0x1a1a instead
>> Further such events for this erase block will not be printed
>> VFS: Mounted root (jffs2 filesystem).
>> Freeing init memory: 68K
>>
>>
>> ********************* CUSTOM START *********************
>>
>> Configure Core FPGA...
>> Done!
>> Init LCD.
>> binFileRead: Cannot open file "/.sw_ver".
>> Run "/sbin/init"!!!<0>Bad page state at free_hot_cold_page (in process
>> 'init', page c02192a0)
>> flags:0x00000000 mapping:00000000 mapcount:-1 count:0
>> Backtrace:
>> Trying to fix it up, but a reboot is needed
>> Inconsistency detKernel panic - not syncing: Attempted to kill init!
>> ected by ld.so: d ynamic-link.h: 122: elf_get_dynamic_info: Assertion
>> `info[20]->d_un.d_val == 17 || info[20]->d_un.d_val == 7' failed!
>>
>>
>> On Wed, Jun 17, 2009 at 10:51 AM, Pawel
>> Potera<pawel.potera@xxxxxxxxxxxxxxx> wrote:
>>
>>>
>>> setenv cmdline = "<kernel command line>"
>>>
>>> One of the parameters should be mem=64M, you may also specify the
>>> physical
>>> address at which you want it to start.  Say, you have 64M mapped at
>>> 0xc0000000, and you want to reserve the first 12M for some reason.  You
>>> could tell the kernel to use the remaining 52M with mem=52M@0xc0c00000.
>>>
>>> ATAG_MEM is not the same thing as the mem= parameter in the kernel
>>> command
>>> line.  You can specify the entire range of the physical RAM with
>>> ATAG_MEM,
>>> but limit the kernel with the mem= command line parameter to use only a
>>> portion of it at some address, like in the example above.
>>>
>>> The command line is passed to the kernel in ATAG_CMDLINE.
>>>
>>> BTW, are you able to retrieve the file system from the flash and verify
>>> its
>>> integrity (eliminate any potential corruption that could occur during
>>> flashing)?  Any chance of getting a backtrace at the point of failure or
>>> even earlier console output?
>>>
>>> Cheers
>>>
>>>
>>
>> -------------------------------------------------------------------
>> List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
>> FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
>> Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php
>>
>>
>
>

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php