DD-WRT support for verizon 7501 bulit by westell

Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Broadcom SoC based Hardware
Goto page Previous  1, 2, 3 ... 53, 54, 55
Author Message
DanMan32
DD-WRT Novice


Joined: 28 Jun 2013
Posts: 14

PostPosted: Tue Jul 16, 2013 4:05    Post subject: Reply with quote
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.
Sponsor
DanMan32
DD-WRT Novice


Joined: 28 Jun 2013
Posts: 14

PostPosted: Tue Jul 16, 2013 6:07    Post subject: Reply with quote
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
DanMan32
DD-WRT Novice


Joined: 28 Jun 2013
Posts: 14

PostPosted: Tue Jul 16, 2013 19:16    Post subject: Reply with quote
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.
DanMan32
DD-WRT Novice


Joined: 28 Jun 2013
Posts: 14

PostPosted: Thu Jul 18, 2013 8:31    Post subject: Reply with quote
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.
DanMan32
DD-WRT Novice


Joined: 28 Jun 2013
Posts: 14

PostPosted: Fri Jul 26, 2013 2:18    Post subject: Reply with quote
I think the CFE6358 is encrypted or compressed, as I can't see any text visible in the binary. Can't find any source for it either, so adapting it to the flash doesn't seem likely.

Tried compiling RedBoot, using source I found based on BCM6348, making changes needed for 6358 based on correspondng files, but no go.
ajmcello
DD-WRT Novice


Joined: 02 Jul 2013
Posts: 4

PostPosted: Fri Jul 26, 2013 3:15    Post subject: Reply with quote
Wow, you've been busy. I ordered a Xilinx USB jtag, should be here any day.

I have the Westell A90-750045-07, whatever that equates to.

I also have the Netgear WNR1000 v2 that comcast gave out, but these two routers look like they may never run dd-wrt.



DanMan32 wrote:
I think the CFE6358 is encrypted or compressed, as I can't see any text visible in the binary. Can't find any source for it either, so adapting it to the flash doesn't seem likely.

Tried compiling RedBoot, using source I found based on BCM6348, making changes needed for 6358 based on correspondng files, but no go.
DanMan32
DD-WRT Novice


Joined: 28 Jun 2013
Posts: 14

PostPosted: Sun Jul 28, 2013 20:16    Post subject: Reply with quote
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.
DanMan32
DD-WRT Novice


Joined: 28 Jun 2013
Posts: 14

PostPosted: Sun Jul 28, 2013 20:37    Post subject: Reply with quote
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.
Rhandy
DD-WRT Novice


Joined: 04 Aug 2010
Posts: 19

PostPosted: Tue Aug 27, 2013 1:17    Post subject: Wireless Router Bridge Mode (Verizon Westell 7501) Reply with quote
MAKE SURE TO READ AND UNDERSTAND ALL THE INSTRUCTIONS BEFORE DOING IT.

This will make your router to connect to a Wireless network and bridge the connection to the wired clients connected to it.

Here are the instructions...

1) Factory reset the Verizon Westell 7501 Router that you want to connect as a client.

2) Go to the Router Web UI at http://192.168.200.1. Go to Firewall Settings. Select Custom, then Apply.

3) Wait a few seconds and then click Edit.

4) Delete all the code and Paste this one:

wl ap 0
wl wsec 1
wl wet 1
wl channel 1
wl scan
wl scanresults
brctl delif br0 wl0
ifconfig br2 down
killall udhcpc
cd /var/net_mgr/exec
./FirewallInit
./FirewallNone
wl join SSID key PASSWORD
route add default gw 192.168.1.1 wl0
echo "nameserver 4.2.2.1" > /var/etc/resolv.conf
echo "nameserver 4.2.2.2" >> /var/etc/resolv.conf
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables --table nat -A POSTROUTING -o wl0 -j MASQUERADE

5) Click Save, wait a few seconds then Apply.

6) Go to the Router Advanced Settings and Activate the Public LAN WITHOUT the DHCP and make sure that the Modem IP is "192.168.1.2" and the Subnet Mask "255.255.255.0". Click Apply.

7) Wait while the Router restarts.

8) Go again to Advanced Settings and deactivate the Private LAN and its DHCP and make sure that the Modem IP is "192.168.1.2" and the Subnet Mask "255.255.255.0". Click Apply.

9) Turn the Router OFF, wait a few seconds and then turn it ON again.

10) Enjoy!


Notes:

* wl sec 1 means WEP security. You should change the number depending on the network security type you're connecting to.

* wl channel 1 is the channel of the wireless network. Change it if the channel is different.

* SSID and PASSWORD is the wireless network you want to contect to.

* 192.168.1.1 is the default gateway of router you're connecting to. Change it if is different.


If something goes wrong, don't worry. Just factory reset the router and try again.
xman25us
DD-WRT Novice


Joined: 21 Sep 2013
Posts: 1

PostPosted: Sat Sep 21, 2013 14:59    Post subject: Connection dropping Reply with quote
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

My scipt is:

#! /bin/sh
/&/& /sbin/telnetd

### Settings ###
ssid='---'
psk='---'
channel='11'
ip='192.168.1.50'
gateway='192.168.1.1'
dns1='4.2.2.1'
dns2='4.2.2.2'

### Firewall ###
ifconfig eth1.2 192.168.200.1
brctl addif br5 eth1.3
cd /var/net_mgr/exec
./FirewallInit
./FirewallNone

### Catch Multiple Executions ###
if [ -f /tmp/started ]; then exit 0; fi
touch /tmp/started

### Housekeeping ###
killall udhcpc
killall pppoe-relay
brctl delif br0 wl0
brctl delif br0 eth1.3
brctl delif br0 usb0
brctl delif br2 wl0.1
ifconfig br0 down
ifconfig br1 down
ifconfig br2 down
ifconfig br3 down
ifconfig br4 down
ifconfig usb0 down
ifconfig wl0.1 down
echo "nameserver ${dns1}" > /var/etc/resolv.conf
echo "nameserver ${dns2}" >> /var/etc/resolv.conf

### Wireless Client ###
wl ap 0
wl wet 1
wl channel $channel
wl scan
wl scanresults
ifconfig wl0 $ip
killall nas
nas -P /var/nas.sta.pid -H 34954 -i wl0 -S -m 4 -k $psk -s $ssid -w 2 -g 3600 > /dev/null 2>&1 &

### Set up bridge ###
while [ $(ping -c 1 $gateway | grep -c "1 packets received") -eq 0 ]; do echo 1 > /dev/zero; done
brctl addif br5 wl0
ifconfig wl0 0.0.0.0 up
ifconfig eth1.3 0.0.0.0 up
ifconfig br5 $ip up
route add default gw $gateway br5

### Keep Alive ###
while [ $(ping -c 1 $gateway | grep -c "1 packets received") -eq 0 ]; do echo 1 > /dev/zero; done
foo='$('
echo "while [ 1 ]; do
if [ ${foo}ping -c 1 ${gateway} | grep -c '1 packets received') -eq 0 ]; then
brctl delif br5 wl0
ifconfig br5 0.0.0.0
ifconfig wl0 ${ip}
while [ ${foo}ping -c 1 ${gateway} | grep -c '1 packets received') -eq 0 ]; do echo 1 > /dev/zero; done
ifconfig wl0 0.0.0.0
brctl addif br5 wl0
ifconfig br5 ${ip}
route add default gw ${gateway} br5
while [ ${foo}ping -c 1 ${gateway} | grep -c '1 packets received') -eq 0 ]; do echo 1 > /dev/zero; done
fi
ping -q -c 2 ${ip} > /dev/zero #one second pause
done" > /tmp/keepalive.sh
sh /tmp/keepalive.sh &
Goto page Previous  1, 2, 3 ... 53, 54, 55 Display posts from previous:    Page 55 of 55
Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Broadcom SoC based Hardware All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum