I have a Westell 7500
Unlike the 7501, the 7500 has an ADSL port and no USB port. Supposedly one of the LAN switchports can be set to a USB A port with a special cable. As someone mentioned, there is space on the circuitboard for a USB socket, but some resistors would also need to be added.
I was looking to use the router VersaPort to use port 1 (first port) as a WAN port. I was able to do that, but on factory reset, the router was locked down to direct you to Verizon's activation page, and the activation page IP is the only place it will let you go.
So I tried compiling and installing the firmware provided by Westell for this unit which bricked the unit.
Went and bought TUMPA (USB equivalent of Wiggler JTAG adapter based on FT2232 chip) hoping I could reflash firmware and access the serial console.
When connecting to the serial, I found that watchdog was tripping about every 60 seconds. I couldn't find a way to activate the switch: network is bound, but the physical ports are disabled. From my research, GPIO5 controls activating the switch, and by default it has it disabled. Only the stock bootloader would activate the switch (hit spacebar to get to it before kernel loads) but had no useful function for re-flashing or anything else.
With only 60 seconds between wdog reboots, and with most of the filesystem readonly (there has to be some place that is writable to store configuration changes) there wasn't much I could do except completely reflash through JTAG.
tjtag and tjtag-mod don't support my TUMPA (or any other that I could see) USB adapter. zJTag supports the USB much like tjtag, but can't handle the BCM4318 radio being in the JTAG chain.
Using his work and moving further, I was able to get UrJTag to properly interface with the flash on the 6358 by removing all references to EJTag in the bcm4318 definition file.
It would only work, though unstable, if I set the instruction length of the 4318to 5, even though it actually has a length of 8. I later fixed that by adding 3 bits to the instructions in the files, either padding left with zeros or 1s, depending on what was appropriate for the instruction.
I installed openwrt-96358VW2-generic-squashfs-cfemod.bin and added lines to the boot script to enable the switch.
I later upgraded to the latest openwrt firmware with the prebuilt inmage for 96358VW2 but in that instance the firmware considered GPIO5 mapped to the power LED, which is not the case here. But using the LED handler, I could write a '1' to the brightness of the power LED, and that enabled the switch:
Incidentally, I found the make files on Westell's website for the 7500 have typos.
The main make file had 8 spaces where a tab was required on two lines.
Also the make file to compile the watchdog module referenced the variable determinging how the module should be compiled as 'WATCHDOG' rather than the correct 'WDOG'. This caused it to compile as a built-in module when it really should have been an estern module in the lib. That may be why watchdog kept tripping every 60 seconds.
I also recommend using the toolchain file a90_toolchain-tar.tar and not a90-750015_toolchain-tar.tar. The latter has the toolchain folder as /opt/toolchains/westell_msw2 which is not what the make file is looking for when it sets up the path. The toolchain folder should be uclibc-crosstools_gcc-3.4.2_uclibc-20050502 instead of westell_msw2
Because UrJtag doesn't have a flash backup function, I couldn't save the CFE before overwriting it. I am looking to add a function to it, borrowing from the verify section of the function that writes to flash.
I'd really like to turn this wifi modem into a Bridge / Repeater.
I have done so with other devices using DD-WRT, but I see no options to do so with the OEM firmware.
Has anyone progress been made getting dd-wrt on the 7500/7501 or even openwrt? Is it possible to do so without the jtag/serial cable if you use the firewall or traceroute trick instead, to get telnet access?
Posted: Mon Jul 08, 2013 18:31 Post subject: Update Firmware without JTAG
You could probably install the firmware by renaming openwrt-96358VW2-generic-squashfs-cfe.bin to app.upg but do at your own risk, as the bootloader may fail to hook into the new firmware. Note though that as-is, the ethernet switch would be disabled. Wireless may work though for telnet access where then you can enable the switch through telnet.
Posted: Mon Jul 15, 2013 18:12 Post subject: Update Firmware without JTAG
Ordered and received a 7501 Saturday afternoon.
I wanted to closely examine the stock firmware before I do anything invasive. For one thing I looking for how the LEDs are controlled and where the button inputs can be retrieved from (GPIO map)
I did find that gpioctl 1 turns power LED green, 2 turns it off, 3 turns it red.
gpio by itself does not return a prompt, appears to continually run. subsequent ctrl-c returns sort of a reset message, then lighs all the LEDs (except LAN and wireless) orange.
Added header pins to board and backed up the flash.
Serial console doesn't provide a command prompt.
Added /bin/sh to custom firewall and now the serial console has a prompt.
I am examining the headers in app.up, similar location in flash backup, and openwrt-96358VW2-generic-squashfs-cfe.bin. Perhaps the bin can be patched with the proper header to get the web to install it.
I was able to generate an App.upg that the web would accept: Using hex editor, removed broadcom bin header from 0x00-0xff. That leaves just the kernel and the new filesystem.
Then use FlashImageBuild that came with the Westell source which appends a header using file build_number.cfg and version.cfg. That seems to also calculate a checksum.
The bootloader does hand off to the kernel, but then you get a kernel panic:
I had set it up where the whole bin was treated as one upgrade section, but in reality th Westell style upgrade file is two sections: first is the kernel, the 2nd is the readonly root, the 2nd section having its own header in the app.upg file.
I couldn't find where the OpenWRT build had the linux kernel by itself, better yet compressed.
Looks to me that the Verizon flash layout wastes a lot of space.
The 7501 has 8MB of flash (7500 only has 6)
The bootloader takes up (discounting the 0x1e000000 offset) 0x000000-0x020000 or 131KB.
FFS filesystem, which is writable to store config changes one would make in the web interface:
020000 - 110000 or 983K
Kernel is from 2be4c0 - 387f58 826K.
RootFS which is readonly starts at 387ffc to the end of the flash (7ffffc) supposedly, thus occupying 3.7MB
There's a gap between end of FFS to beginning of kernel:
110000-2be4bf (actually there's a few bytes of app.upg header before the actual kernel) taking up 1.7MB gap.
I hope that FFS would expand into the gap, and also continue using unused space in the rootfs. RootFS only needs 700KB to hold the files that are there.
Kinda makes you want to run far away from the Westell/Verizon layout of this router. OpenWRT has the kernel first, then the readonly squashfs, then the writable JFFS overlay. A small section is reserved for the traditional NVRAM somewhere in the middle.
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.