DD-WRT support for verizon 7501 bulit by westell

Post new topic   This topic is locked: you cannot edit posts or make replies.    DD-WRT Forum Index -> Broadcom SoC based Hardware
Goto page Previous  1, 2, 3 ... , 53, 54, 55  Next
Author Message
jjhung88
DD-WRT Novice


Joined: 11 Oct 2010
Posts: 20

PostPosted: Wed May 01, 2013 21:14    Post subject: attaching a usb webcam for live view Reply with quote
I know someone was talking about attaching a usb webcam to the verizon westell 7501 and use as a network webcam. I have several older usb webcam and I would like to try this.

Does anyone know how to go about doing this? And how do I see the live view eg.jpg frames? No need for recording.
Sponsor
DanMan32
DD-WRT Novice


Joined: 28 Jun 2013
Posts: 14

PostPosted: Mon Jul 01, 2013 21:44    Post subject: Reply with quote
Hi All,
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.

I found where Etn45p4m on Sourceforge was able to get UrJTag to get further with the Westell recognizing both chips in the JTAG chain, but not able to get the flash recognized:
http://sourceforge.net/p/urjtag/discussion/682993/thread/7fd39032

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:

echo 1 >/sys/class/leds96358VW2:green:power/brightness

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.
ajmcello
DD-WRT Novice


Joined: 02 Jul 2013
Posts: 4

PostPosted: Tue Jul 02, 2013 8:04    Post subject: Reply with quote
I have a 7500 as well, with USB port.

I was able to log in with the telnet trick.

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?

Thanks
ajmcello
DD-WRT Novice


Joined: 02 Jul 2013
Posts: 4

PostPosted: Tue Jul 02, 2013 8:05    Post subject: Reply with quote
hansc wrote:
i managed to flash openwrt to a 7500 which is similar to the 7501.

Instructions and all files needed are here:

http://hanschan.no-ip.org:8080/wiki/index.php/Openwrt_on_Westell_7500


Have you made any further progress? Is it possible to do this without a jtag / serial cable?

Thanks.
DanMan32
DD-WRT Novice


Joined: 28 Jun 2013
Posts: 14

PostPosted: Mon Jul 08, 2013 18:31    Post subject: Update Firmware without JTAG Reply with quote
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.
ajmcello
DD-WRT Novice


Joined: 02 Jul 2013
Posts: 4

PostPosted: Wed Jul 10, 2013 16:02    Post subject: Re: Update Firmware without JTAG Reply with quote
Thanks, I'm tempted to, but don't want to brick my router, lol.

I'm going to go ahead and order a JTAG cable, they are cheap, and then see how much I can mess up my Westell. Smile
ghoffman
DD-WRT User


Joined: 03 Jan 2010
Posts: 453

PostPosted: Thu Jul 11, 2013 1:11    Post subject: Reply with quote
Quote:
You could probably install the firmware by renaming openwrt-96358VW2-generic-squashfs-cfe.bin to app.upg


i did this and used the westell firmware upgrade gui. the file 'failed crc check' and therfore would not flash.

i htink the new cfe has to be flashed first, and as i recall, the mtd tools are not adequate in the westell firmware, even after gaining access though the telnet script trick.

any other appproaches ?
DanMan32
DD-WRT Novice


Joined: 28 Jun 2013
Posts: 14

PostPosted: Mon Jul 15, 2013 18:12    Post subject: Update Firmware without JTAG Reply with quote
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.
DanMan32
DD-WRT Novice


Joined: 28 Jun 2013
Posts: 14

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


Joined: 28 Jun 2013
Posts: 14

PostPosted: Mon Jul 15, 2013 23:51    Post subject: Reply with quote
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:

Code:
*******************************************************
Watchdog reset
*******************************************************
C0GDTW

  WESTELL - ROM Bootloader
  (C) Copyright 2006 WESTELL, Inc.   All Rights Reserved.

CLEARING SDRAM
...
............
PASSED

WESTELL - MAIN Bootloader
Reboot command 800000
Device 0 -- FLASH start addr BE000000 Flash end addr BE3FFFFF
Device 1 -- FLASH start addr BE400000 Flash end addr BE7FFFFF
Flash start BE000000 end BE7FFFFF size 00800000
No App Reboot Information found: 1
[    0.000000] Linux version 3.3.8 (blogic@Debian-60-squeeze-64-minimal) (gcc version 4.6.3 20120201 (prerelease) (Linaro GCC 4.6-2012.02) ) #1 Sat Mar 23 18:09:20 UTC 2013
[    0.000000] Detected Broadcom 0x6358 CPU revision a1
[    0.000000] CPU frequency is 300 MHz
[    0.000000] 32MB of RAM installed
[    0.000000] registering 40 GPIOs
[    0.000000] gpiochip_add: registered GPIOs 0 to 39 on device: bcm63xx-gpio
[    0.000000] board_bcm963xx: Boot address 0xbe000000
[    0.000000] board_bcm963xx: CFE version: unknown
[    0.000000] bcm63xx_nvram: invalid nvram checksum
[    0.000000] bootconsole [early0] enabled
[    0.000000] CPU revision is: 0002a010 (Broadcom BMIPS4350)
[    0.000000] Kernel panic - not syncing: unable to detect bcm963xx board


I'm figuring the OpenWRT is expecting the CFE to provide the board ID.

So at the moment it is bricked. Time to reload the flash.
DanMan32
DD-WRT Novice


Joined: 28 Jun 2013
Posts: 14

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


Joined: 28 Jun 2013
Posts: 14

PostPosted: Tue Jul 16, 2013 2:15    Post subject: Reply with quote
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.
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.
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.
Goto page Previous  1, 2, 3 ... , 53, 54, 55  Next Display posts from previous:    Page 54 of 55
Post new topic   This topic is locked: you cannot edit posts or make replies.    DD-WRT 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