On 04/27/2010 11:08 AM, Jan Nikitenko wrote:
I guess the last hope for the router is the pin9 trick - read a lot
about it, checked even datasheets, did not find somebody's explanation,
why it should even work though, so never tried it - shorting an address
line of flash chip - what it might cause, if it looks like CFE is not
started as there is nothing on serial console?
Or is CFE started only partially, and logs are visible on serial console
only if sdram controller is set up properly?
Answering to myself - here are my results with the pin9 trick - it worked, at
least partially - cfe was visible on serial console, tried to boot the kernel,
was possible to enter recovery/tftp mode to flash another fw.
But there was only 64MB ram enabled and even though sdram_init and sdram_config
could be changed in nvram ok, CFE did not use any value set there, so 128MB
could not be enabled (no, I did not forget to use nvram commit command) - tried
to change it from old firmware flashed for that purpose, verified that the
values are stored there, reflashed even the whole nvram area, nothing helped.
Even setting it directly from CFE did not help (here I did not forget to use
nvram commit either).
See below for full details of the whole procedure since beginning (there is a
positive ending):
- connected serial console, powered on, nothing happens as described earlier due
to incorrent nvram settings of sdram_init from backfire's first boot
- powered off, shorted pin9 of flash chip to ground
- powered on, here is what happened on the serial console:
�..����
CFE version 1.0.37 for BCM947XX (32bit,SP,LE)
Build Date: �| 10.� 12 22:21:19 CST 2006 (r...@localhost.localdomain)
Copyright (C) 2000,2001,2002,2003 Broadcom Corporation.
Initializing Arena
Initializing Devices.
et0: Broadcom BCM47xx 10/100 Mbps Ethernet Controller 3.90.7.0
rndis0: Broadcom USB RNDIS Network Adapter (P-t-P)
CPU type 0x29006: 200MHz
Total memory: 67108864 KBytes
Total memory used by CFE: 0x80800000 - 0x8089AF40 (634688)
Initialized Data: 0x808313D0 - 0x80833790 (9152)
BSS Area: 0x80833790 - 0x80834F40 (6064)
Local Heap: 0x80834F40 - 0x80898F40 (409600)
Stack Area: 0x80898F40 - 0x8089AF40 (8192)
Text (code) segment: 0x80800000 - 0x808313D0 (201680)
Boot area (physical): 0x0089B000 - 0x008DB000
Relocation Factor: I:00000000 - D:00000000
Committing NVRAM...don�
- you can see here, that CFE detected bad nvram and reset it's content while A21
(pin9) of flash chip was still shorted to ground
- powered off, unshorted pin9, powered on, next boot failed on corrupted
squashfs, that's ok, it's great that CFE works now:
CFE version 1.0.37 for BCM947XX (32bit,SP,LE)
Build Date: �| 10.� 12 22:21:19 CST 2006 (r...@localhost.localdomain)
Copyright (C) 2000,2001,2002,2003 Broadcom Corporation.
Initializing Arena
Initializing Devices.
et0: Broadcom BCM47xx 10/100 Mbps Ethernet Controller 3.90.7.0
rndis0: Broadcom USB RNDIS Network Adapter (P-t-P)
CPU type 0x29006: 264MHz
Total memory: 67108864 KBytes
Total memory used by CFE: 0x80800000 - 0x8089AF40 (634688)
Initialized Data: 0x808313D0 - 0x80833790 (9152)
BSS Area: 0x80833790 - 0x80834F40 (6064)
Local Heap: 0x80834F40 - 0x80898F40 (409600)
Stack Area: 0x80898F40 - 0x8089AF40 (8192)
Text (code) segment: 0x80800000 - 0x808313D0 (201680)
Boot area (physical): 0x0089B000 - 0x008DB000
Relocation Factor: I:00000000 - D:00000000
Device eth0: hwaddr 00-1B-FC-06-48-02, ipaddr 192.168.1.1, mask 255.255.255.0
gateway not set, nameserver not set
Null Rescue Flag.
Loader:raw Filesys:raw Dev:flash0.os File: Options:(null)
Loading: .. 4092 bytes read
Entry at 0x80001000
Closing network.
Starting program at 0x80001000
Linux version 2.6.32.10 (u...@notas) (gcc version 4.3.3 (GCC) ) #1 Sun Apr 25
18:06:37 CEST 2010
CPU revision is: 00029006 (Broadcom BCM3302)
... <cut> ...
802.1Q VLAN Support v1.8 Ben Greear <gree...@candelatech.com>
All bugs added by David S. Miller <da...@redhat.com>
SQUASHFS error: squashfs_read_data failed to read block 0x2de4b9
SQUASHFS error: Unable to read metadata cache entry [2de4b9]
SQUASHFS error: Unable to read inode 0xea71ca2
------------[ cut here ]------------
WARNING: at fs/inode.c:712 unlock_new_inode+0x34/0x5c()
Modules linked in:
Call Trace:
[<8000a190>] dump_stack+0x8/0x34
[<8002427c>] warn_slowpath_common+0x70/0xb0
[<800aaa34>] unlock_new_inode+0x34/0x5c
[<800acc6c>] iget_failed+0x1c/0x30
[<800ecbfc>] squashfs_fill_super+0x4dc/0x5ac
[<80097e14>] get_sb_bdev+0x138/0x1b0
[<800ec654>] squashfs_get_sb+0x20/0x2c
[<800968b0>] vfs_kern_mount+0x6c/0x100
[<800969a8>] do_kern_mount+0x54/0x128
[<800b1764>] do_mount+0x664/0x71c
[<800b18b4>] sys_mount+0x98/0xe8
[<802a9d08>] mount_block_root+0x144/0x318
[<802aa120>] prepare_namespace+0x1c8/0x1fc
[<802a9388>] kernel_init+0x124/0x148
[<8000faac>] kernel_thread_helper+0x10/0x18
---[ end trace 16056bcc77298867 ]---
VFS: Cannot open root device "mtdblock2" or unknown-block(31,2)
Please append a correct "root=" boot option; here are the available partitions:
1f00 256 mtdblock0 (driver?)
1f01 7872 mtdblock1 (driver?)
1f02 6961 mtdblock2 (driver?)
1f03 3968 mtdblock3 (driver?)
1f04 64 mtdblock4 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,2)
��
- you can see that only 64MB ram is enabled (something like that was expected as
defaults of nvram should have been used)
- now entered recovery mode with black button pressed while powering it on,
flashed Oleg's WL500gp-1.9.2.7-10.trx fw known to work with 128MB as used it
during upgrade to 128MB ram
...<cut>...
Failed.: Timeout occured
Reading :: TFTP Server.
TFTP_BLKLEN!!
Done. 3796992 bytes read
Download of 0x39f000 bytes completed
Write kernel and filesystem binary to FLASH (0xbfc40000)
flash device 'flash1.trx'
Programming...
done. 3796992 bytes written
.
- powered off and on, booted ok, still 64MB ram as expected, as sdram
configuration in nvram was not touched yet
- now did a backup of nvram content to see to what it was reset during pin9
trick:
...<cut>...
Creating 5 MTD partitions on "Physically mapped flash":
0x00000000-0x00040000 : "boot"
0x00040000-0x007f0000 : "linux"
0x000e4000-0x007f0000 : "rootfs"
0x007f0000-0x00800000 : "nvram"
0x003e0000-0x007f0000 : "flashfs"
...<cut>...
/ # dd if=/dev/mtd/3 of=/tmp/mtd3-nvram-after-pin9trick.img
128+0 records in
128+0 records out
/ # scp /tmp/mtd3-nvram-after-pin9trick.img u...@192.168.1.200:
...<cut>...
- examined the content on desktop:
$ strings mtd3-nvram-after-pin9trick.img | grep sdram
sdram_config=0x0062
sdram_refresh=0x0000
sdram_ncdl=0x00000503
sdram_init=0x0019
- we can see, that nvram flash partition still has incorrect sdram_init settings
from backfire nvram init script, the value 0x19 that caused CFE not to run
- it's strange, that we have still bugus nvram content, but CFE now runs after
the pin9 trick - guess that the shorted A21 line during reset of nvram from CFE
caused reset of different flash area, but why CFE still not gets the values from
nvram area if the content is still there?
- decided to flash original content of nvram that was there from production (I
did a backup before experimenting with original fw replacements):
/ # scp u...@192.168.1.200:asus-orig-mtd3.img /tmp
...<cut>...
/ # mtd
/bin/sh: mtd: not found
/ # erase --help
--help: No such file or directory
/ # erase
usage: erase [device]
/ # erase /dev/mtd/3
/ # dd if=/tmp/asus-orig-mtd3.img of=/dev/mtd/3
128+0 records in
128+0 records out
/ # dd if=/dev/mtd/3 of=/tmp/mtd3-new.img
128+0 records in
128+0 records out
/ # scp /tmp/mtd3-new.img u...@192.168.1.200:
...<cut>...
- verified, that it flashed ok by comparison of read back content with the
original, rebooted:
CFE version 1.0.37 for BCM947XX (32bit,SP,LE)
Build Date: �| 10.� 12 22:21:19 CST 2006 (r...@localhost.localdomain)
Copyright (C) 2000,2001,2002,2003 Broadcom Corporation.
Initializing Arena
Initializing Devices.
et0: Broadcom BCM47xx 10/100 Mbps Ethernet Controller 3.90.7.0
rndis0: Broadcom USB RNDIS Network Adapter (P-t-P)
CPU type 0x29006: 264MHz
Total memory: 67108864 KBytes
...<cut>...
- now being sure, that nvram should have valid content, since it was reflashed
with asus original, changed sdram settings to enable 128MB:
/ # nvram set sdram_init=0x0011
/ # nvram set sdram_config=0x0062
/ # nvram commit
/ # reboot
/ # Restarting system.
Please stand by while rebooting the system...
CFE version 1.0.37 for BCM947XX (32bit,SP,LE)
Build Date: �| 10.� 12 22:21:19 CST 2006 (r...@localhost.localdomain)
Copyright (C) 2000,2001,2002,2003 Broadcom Corporation.
Initializing Arena
Initializing Devices.
et0: Broadcom BCM47xx 10/100 Mbps Ethernet Controller 3.90.7.0
rndis0: Broadcom USB RNDIS Network Adapter (P-t-P)
CPU type 0x29006: 264MHz
Total memory: 67108864 KBytes
...<cut>...
- hmm, still 64MB, that is really strange, the same in loaded linux, but sdram
config seems to be correct:
/ # free
total used free shared buffers
Mem: 62580 11040 51540 0 1536
Swap: 0 0 0
Total: 62580 11040 51540
/ # nvram get sdram_init
0x0011
/ # nvram get sdram_config
0x0062
- tried to enable only one of ram chips, as described in ram upgrade guide:
/ # nvram set sdram_init=0x000b
/ # nvram set sdram_config=0x0032
/ # nvram commit
/ # reboot
- no effect at all, still 64MB, even after power cycle:
CPU type 0x29006: 264MHz
Total memory: 67108864 KBytes
- set it back to 128MB configuration (sdram_init=0x0011, sdram_config=0x0062),
no effect, even after this:
/ # nvram set sdram_ncdl=0x0000
/ # nvram commit
/ # reboot
- started to play with nvram command directly from CFE:
CFE> nvram show
default_primary_pool_name=
os_ram_addr=80001000
boardrev=0x10
...<cut>...
pmon_ver=CFE 3.91.7.0
...<cut>...
boardtype=0x042f
...<cut>...
sdram_config=0x0062
...<cut>...
sdram_init=0x0009
...<cut>...
CFE> nvram set sdram_init=0x0011
*** command status = 0
CFE> nvram set sdram_config=0x0062
*** command status = 0
CFE> nvram commit
*** command status = 0
- rebooted, but still 64MB visible:
CPU type 0x29006: 264MHz
Total memory: 67108864 KBytes
...<cut>...
CFE> nvram get sdram_init
0x0009
*** command status = 0
- hmm, cfe still uses 0x0009 sdram_init value, strange, because in booted fw, it
has 0x0011 value:
/ # nvram get sdram_init
0x0011
- and in CFE again after reboot:
CFE> nvram get sdram_init
0x0009
*** command status = 0
- copied cfe boot loader image from router to desktop to compare it with backup
from original asus firmware
/ # dd if=/dev/mtd/0 of=/tmp/mtd0.img
512+0 records in
512+0 records out
/ # scp /tmp/mtd0.img u...@192.168.1.200:
- read out cfe image was binary identical to the backup, so the problem couldn't
be there
- to sumarize, we have valid CFE, valid NVRAM content with sdram_init set to
0x0011, but cfe still uses 0x0009 value for unknown reason, so we result with
64MB only memory; now I started to get insane, as there was no explanation for
such behavior
- decided to flash backup of original asus fw using tftp recovery mode:
Reading :: TFTP Server.
TFTP_BLKLEN!!
Done. 8060928 bytes read
Download of 0x7b0000 bytes completed
Write kernel and filesystem binary to FLASH (0xbfc40000)
flash device 'flash1.trx'
Programming...
done. 8060928 bytes written
- it did not boot up, linux kernel loaded, initialization started, but it
rebooted before kernel initialization completed, probably due to missing support
of 128MB (or 64MB) of ram, so there was endless loop of reboots like this:
CFE version 1.0.37 for BCM947XX (32bit,SP,LE)
Build Date: �| 10.� 12 22:21:19 CST 2006 (r...@localhost.localdomain)
Copyright (C) 2000,2001,2002,2003 Broadcom Corporation.
Initializing Arena
Initializing Devices.
et0: Broadcom BCM47xx 10/100 Mbps Ethernet Controller 3.90.7.0
rndis0: Broadcom USB RNDIS Network Adapter (P-t-P)
CPU type 0x29006: 264MHz
Total memory: 67108864 KBytes
Total memory used by CFE: 0x80800000 - 0x8089AF40 (634688)
Initialized Data: 0x808313D0 - 0x80833790 (9152)
BSS Area: 0x80833790 - 0x80834F40 (6064)
Local Heap: 0x80834F40 - 0x80898F40 (409600)
Stack Area: 0x80898F40 - 0x8089AF40 (8192)
Text (code) segment: 0x80800000 - 0x808313D0 (201680)
Boot area (physical): 0x0089B000 - 0x008DB000
Relocation Factor: I:00000000 - D:00000000
Device eth0: hwaddr 00-1B-FC-06-48-02, ipaddr 192.168.1.1, mask 255.255.255.0
gateway not set, nameserver not set
Null Rescue Flag.
Loader:raw Filesys:raw Dev:flash0.os File: Options:(null)
Loading: ...... 1753088 bytes read
Entry at 0x80001000
Closing network.
Starting program at 0x80001000
CPU revision is: 00029006
Primary instruction cache 16kb, linesize 16 bytes (2 ways)
Primary data cache 16kb, linesize 16 bytes (2 ways)
Linux version 2.4.20 (r...@localhost.localdomain) (gcc version 3.2.3 with
Broadcom modifications) #437 Tue Dec 12 11:57:20 CST 2006
Setting the PFC to its default value
Determined physical RAM map:
memory: 04000000 @ 00000000 (usable)
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/mtdblock2 noinitrd console=ttyS0,115200
CPU: BCM4704 rev 9 at 264 MHz
Calibrating delay loop... 263.78 BogoMIPS
Memory: 62876k/65536k available (1509k kernel code, 2660k reserved, 116k data,
64k init, 0k highmem)
Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
Mount-cache hash table entries: 1024 (order: 1, 8192 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
Checking for 'wait' instruction... unavailable.
POSIX conformance testing by UNIFIX
PCI: Fixing up bus 0
PCI: Fixing up bridge
CFE version 1.0.37 for BCM947XX (32bit,SP,LE)
Build Date: �| 10.� 12 22:21:19 CST 2006 (r...@localhost.localdomain)
Copyright (C) 2000,2001,2002,2003 Broadcom Corporation.
- entered CFE to try nvram setup for sdram:
CPU type 0x29006: 264MHz
Total memory: 67108864 KBytes
...<cut>...
CFE> ^C
CFE> nvram get sdram_init
0x0009
*** command status = 0
CFE> nvram get sdram_config
0x0062
*** command status = 0
CFE> nvram set sdram_init=0x000b
*** command status = 0
CFE> nvram set sdram_config=0x0032
*** command status = 0
CFE> nvram commit
*** command status = 0
- rebooted and noticed big difference, finally - there was 32MB ram enabled as
CFE used the new configuration
CPU type 0x29006: 264MHz
Total memory: 33554432 KBytes
...<cut>...
CFE> ^C
CFE> nvram get sdram_init
0x000b
*** command status = 0
CFE> nvram get sdram_config
0x0032
*** command status = 0
- so tried to set it to 128MB:
CFE> nvram set sdram_init=0x0011
*** command status = 0
CFE> nvram set sdram_config=0x0062
*** command status = 0
CFE> nvram commit
*** command status = 0
- FINALY:
CPU type 0x29006: 264MHz
Total memory: 134217728 KBytes
...<cut>...
CFE> nvram get sdram_init
0x0011
*** command status = 0
CFE> nvram get sdram_config
0x0062
*** command status = 0
- flashed again oleg's fw with support of 128MB
Reading :: TFTP Server.
TFTP_BLKLEN!!
Done. 3796992 bytes read
Download of 0x39f000 bytes completed
Write kernel and filesystem binary to FLASH (0xbfc40000)
flash device 'flash1.trx'
Programming...
done. 3796992 bytes written
...<cut>...
/ # free
total used free shared buffers
Mem: 127408 11340 116068 0 1536
Swap: 0 0 0
Total: 127408 11340 116068
So I guess that to recover from pin9trick flash state, it's needed to flash all
sectors of the flash to reinit it from bad state caused by A21 shortage to
ground during nvram reset done by CFE. It's not sufficient to reflash/setup just
the nvram part of the flash (or flash small fw) - it started to take values from
nvram only after flashing of 8,060,928 bytes, that is complete flash except CFE
at beginning and nvram at the end.
Hopefully this description helps someone.
Concerning the nvram init script of backfire openwrt - I do not understand, why
the 0x0009 value is ORed there - if it was just set, the router would still boot
even though full 128MB ram would not be enabled.
In my opinion, fw should not change such critical settings - if someone likes to
enable more ram than it was from factory, he should do it manually knowing that
the ram is there.
Best regards,
Jan
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
