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