This is getting scary.
First I accidentally wipe the bootloader by forgetting the 0x1e prefix when writing the original kernel back to its original spot.
I get that fixed, but even after I reinstall the bootloader and original kernel, it finds the openwrt I had put in because the upgrade had put it in a higher location. I try erasing the higher location, but UrJTag seems to have issues crossing the 4MB boundary, on accoun that there's really two chips in there, each 4MB.
Also mistook the erase command, thinking it was length, but really it is by blocks.
So I got both banks erased, got the bootloader back in, now in progress putting the original kernel back in.
I'd like to see what it does without the root filesys which won't be there yet.
Got the original kernel back. Found out the last few bytes at the end of the flash is the vector to the beginning of the header where the kernel resides.
It of course complains that there's no rootfs as I haven't restored it yet.
As I mentioned, the rootfs looks to be going from 387ffc (plus header before this) to 7ffffc. I seem to have trouble flashing across 0x1e400000 boundary so I am going to try and get away with flashing only from 387f58 - 3fffff
It's been taking me forever to put the stock flash back as it was. Tried to do it in sections (bootloader, kernel, writable FFS filesystem, readonly Squash file system, fix up the boot vector at the end of the flash, etc. Turns out that UrJTag has to erase an entire flash block and leaves portions of the block erased that you are not specifically writing to. Ex if I update that vector which is only 3 bytes long, the entire block from 0x1e7fe000 on is left erased, save for the last three bytes you're updating. This block is part of the squashfs so it fails.
Anyway, it would be very difficult to be able to change over from the stock firmware to OpenWRT via the App.upg.
OpenWRT doesn't appear to be compatible with the stock bootloader in that the needed info OpenWRT needs isn't in the standard offset 0x580 that the normal 63xx CFE would have it. I thought about having app.upg replace the CFE, as it can have multiple sections to change, but there's two issues:
1. App.upg sections have headers, and the headers get placed in flash along with the intended data. However the replacememt CFE must be at offset zero, no header before it.
2. The CFE section contains "NVRAM" data starting at offset 0x580 that needs to be filled in with information specific to your board. At the very least, the mac address has to be customized. If the CFE finds the nvram data section invalid, it will prompt you for the info, but i believe it can only be accessed through the serial console.
The only way I can see being able to change over from stock firmware to OpenWRT is if a special installer program is written as app.upg, and that in turn would take over, install the CFE, install OpenWRT where they should be placed, and prompt you for the needed information, putting that into offset 0x580. This installer would have to be able to write to flash directly.
Well, tried to move on and replace the CFE, have it run its initialization procedures, then take a "snapshot" of the "NVRAM" area (offset 0x580). Problem is the CFE that hanschan had successfully used, had been used on a 7500. It doesn't seem to work on 7501, CFE doesn't support flash chip ID 257e.
So now to figure out where the flash table is in the CFE and change it so it will accept 257e.
Found where someone used this CFE for flash iD 2201, searched for 2201 and change to 257e, but that must have been code: doesn't boot CFE at all after change.
So, back to needing a CFE that works with the flash in a 7501.
A90-750045-07 is an edition of the 7500 (as opposed to the 7501). The first 4 digits after A90 specify the board model, the two digits after that is the market (ISP) the router is being used/distributed by. Westell isn't specifying what ISP 750045 is for.
So, A90-750045 should be equivalent to the Verizon Westell Versalink 7500 with model A90-750015. Last 2 digits I would believe to be the version.
I realized that OpenWRT installed on a 7500 did not recognize the 2nd 2MB flash. Not sure if that's because the Broadcom CFE bootloader didn't detect it, or the OpenWRT kernel doesn't support the 2nd flash chip.
I did manage to get OpenWRT to run on the 7501 using the Westell proprietary bootloader, the OpenWRT firmware being installed by JTAG. In order to get OpenWRT to boot, I had to hardcode the pertinent information normally contained in the CFE NVRAM data and BCM firmware tag header into the OpenWRT code. One hardcoded section was to specify the board name to the Kernel so that it would locate the proper board specific information in its table, the other was to set up the MTD flash partitions, using the CFE model. Also had to manually strip off the BCM tag header and add the Westell firmware header for A_Main using a hex editor. In this instance, the kernel did detect both flash chips without any modifications though as I mentioned, I did have to make alterations to get the MTD partitions set up.
I was able to get the LEDs and buttons mapped out on the 7501 where they are usable by OpenWRT, and to have OpenWRT enable the switch during bootup. So far though I don't have anything set up to do anything useful with the LEDs yet.
I haven't been able to get the Ethernet WAN port working yet on the 7501. An eth0 and Eth1 does show up, where Eth1 is LAN and associated with the 5325 switch chip. I suspect Eth0 is tied to the DSL components built-in to the 6358 SoC and so is not usable on the 7501. The WAN port seems to be tied to the 5325 switch, which according to Broadcom specs, is a 5 port ethernet switch but not sure if that chip is tied into the 6358 through some backend connection independent of the 5 ports, or is using one of the 5 to connect to the 6358 Eth0. Also I am not certain if there's a 5325 built-in to the 6358, with an additional one as an external chip. If so, then OpenWRT probably doesn't have any control over the external one, other than turning it on or off via GPIO5.
Westell has a strange flash layout:
0x000000 - 0x020000 Westell Bootloader
Following that is a FFS filesystem that is RW, where the config files are stored.
After that is the kernel firmare with an A_Main header, then after that is a read only filesystem for RootFS, with RootFS also having a Westell header. The last 4 bytes of the entire flash region is a vector pointing to the beginning of the header for the A_Main, which is where the bootloader boots to.
A firmware upgrade via the Westell (Verizon) web interface would install the new A_Main and RootFS data below the original ones, or possibly above if there's room. That, or new firmware is installed at the very bottom of the flash, whereas normally BCM firmware booting from CFE would be installed right after the CFE bootloader, starting with the kernel, followed by the read-only squashFS root, followed by JFFS RW overlay that is built by the kernel, using up the remainder of the flash, other than NVRAM space reserved at the bottom of the flash region. This NVRAM section is not actually used by 63xx series, but is used by earlier Broadcom SoC's. The real NVRAM for a 63xx SoC is in the middle of the CFE block.
To sum up, Westell has the RW filesystem before the kernel and RO RootFS, thus ideally having the firmware installed as low as possible in the flash so as to maximize RW space, whereas, Broadcom has its RW JFFS set up after the kernel and fixed RootFS, thus needing to install the firmware as early in the flash as possible to maximize RW filespace.
Being that I was able to get OpenWRT to boot through the Westell bootloader, even though it was installed via JTAG, it could be quite feasable to get OpenWRT installed through the Verizon web interface. Since the Verizon/Westell installer wouldn't be installing the firmware in the most ideal location, causing OpenWRT to have RW filespace being little to none. However that may get things far enough where one can then manage the flash through OpenWRT, reinstalling the firmware in its ideal location. I haven't worked it out yet to have OpenWRT updated through its web interface; currently it is expected that you install OpenWRT firmware using the CFE tools normally accessible through network interface, which isn't possible on the 7500/7501 since by default the switch managing the physical interfaces is left off, and for the 7501, the CFE can't work with the flash anyway.
DD-WRT development has chosen not to support the 63xx platform, as this platform is designed with DSL built-in, and DD-WRT doesn't want to support DSL, even though most of us don't intend to use the DSL features of the 63xx platform. OpenWRT however does support the 63xx platform, though it has no to limited support for the DSL component, relying on the VLAN supporting switch to break out a WAN port, since it seems that Eth0 is fixed at being connected to the DSL block.
The difficulty I've encountered in trying to reverse-engineer Westell board and firmware is that the Westell sourcecode contains Westell proprietary binary objectcode only for key components, such as flash management. I am not sure if that's violating any GPL licensing. It would be if the objectcode was built using any GPL licensed sourcecode, but might not be if the objectcode did not use any GPL licensed sourcecode, even though the binaries are being utilized by GPL software. Case in point, i could not locate any GPIO mappings for the LEDs or buttons when going through the sourcecode provided by Westell, but rather I was able to figure out the mappings by reading the clear text in the GPIOCTRL module via a hex editor, thus being able to figure out its commands, one of the commands providing an "event" map which linked an event function number to a GPIO pin. I could then kick off the event by number, observing which LEDs were affected. The map showed two GPIOs set up as inputs rather than outputs, but wasn't able to tell which GPIO was mapped to which button, nor if they were active high or active low. With only 2 buttons, I had a 50/50 chance in guessing which GPIO was mapped to which button, and for each one of those, a 50/50 shot in determining if they were active high or active low.
Then I could use a script in OpenWRT to detect button activity, and determine if I labelled them correctly or not. I happen to get the button to GPIO association correct the first time around, but was mistaken on the WPS button being active high, thus OpenWRT saw it normally pressed. There's a minor bug in OpenWRT though that caused the kernel to halt if it detected a button pressed when the key polling module was loaded. Since I was still working on getting a working JFFS partition, I thought the kernel halt was caused by a JFFS initialization fault, as I was getting JFFS detection errors early on in the kernel boot process. I was able to get a stable busybox prompt though when I entered OpenWRT failsafe mode. Failsafe only runs critical initialization, and does not load the JFFS partition. The idea behind not loading JFFS overlay is so that you start out with firmware defaults, since file changes from firmware would be in the JFFS overlay. You can then manually load JFFS so that you can make your changes. But first JFFS had to be initialized by the FirstBoot script, which in normal boot didn't get a chance to run since the button handler caused the system to halt.
I couldn't get JFFS to mount in failsafe, but I did figure out I could run Firstboot in failsafe, which then did properly initialize JFFS. Firstboot though takes about a full minute or two to complete, appearing hung the whole time, which is what I though happened. Once I let FirstBoot complete its thing in Failsafe mode, i no longer was getting JFFS errors during normal boot, rather was then getting messages that it was successfully initialized, but was still getting the system halt, which then had me rule out a JFFS problem causing the halt, thus leading me after some research to the button problem being the cause of halt issue all along.
I fixed the button mapping in the firmware so that neither button appears depressed by default, so now JFFS formats properly after a new firmware update install via jTAG. That button problem probablly had me waste several hours chasing a flash mapping problem that didn't exist.
FYI Netgear WNR1000 uses the Broadcom 5356 SoC, therefore I can't help much with that, since I am extensively working with the 6358 installed in the Westell routeres. Since so far only OpenWRT seems to be supported for the 63xx platform that the Westell uses, I've been focusing my work with that project platform. The only reason I've been posting here in the DD-WRT forum is because extensive work/research/information for the Westell has been posted here than any other forum.
I am seeing a BCM947xx/953xx target platform set, where the 9 prefix signifies a complete board rather than the chip itself, so it may be possible to get OpenWRT to work with the WNR1000, though no build has been made specifically for that board, so likely there will be need of significant work.
Posted: Sat Sep 21, 2013 14:59 Post subject: Connection dropping
Hi, I have been able to put my router in bridge model using setting and script but after few hours the connection does not work and requires a restart of the router. I do have the keep alive part. Any help would be appreciated