Re: ARM Paging Problems

Stephen Lim <[email protected]>
Newsgroups gmane.linux.ports.arm.general
Message-ID <[email protected]>
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<[email protected]> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.