@fluxsmith Is openvpn working for you?

(Last edited by gufus on 8 Nov 2014, 00:21)

Looking into it.

What's up with current u-boot binary?  Is bubt giving you errors?  The reason I ask is because kirkwood is pretty different from armada xp.

$./mkimage -A arm -d u-boot-v1.3.25.bin u-boot-v1.3.25.bin.kwb
Image Name:
Created:      Sat Nov  8 19:55:38 2014
Image Type:   ARM Linux Kernel Image (gzip compressed) #This worries me!
Data Size:    913664 Bytes = 892.25 kB = 0.87 MB
Load Address: 00000000
Entry Point:  00000000

I don't think it's right, but here's your image:
http://www.protechs-online.com/download … bin.kwb.gz

Some food for thought:

root@OpenWrt:/# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00100000 00020000 "u-boot"
mtd1: 00040000 00020000 "u_env"
mtd2: 00040000 00020000 "s_env"
mtd3: 00100000 00020000 "devinfo"
mtd4: 02800000 00020000 "kernel1"
mtd5: 02500000 00020000 "ubi"
mtd6: 02800000 00020000 "kernel2"
mtd7: 02500000 00020000 "rootfs2"
mtd8: 02600000 00020000 "syscfg"
mtd9: 00008000 00008000 "spi0.0"
root@OpenWrt:/# hexdump -C /dev/mtd0 | head -n10
00000000  8b 00 00 00 00 61 0c 00  01 01 00 90 00 90 01 00  |.....a..........|
00000010  00 00 00 00 00 00 00 00  00 02 01 00 00 00 01 da  |................|
00000020  02 01 98 80 02 00 00 00  5b 00 00 00 68 00 00 00  |........[...h...|
00000030  ff 5f 2d e9 1c 00 00 fa  00 00 a0 e3 ff 9f bd e8  |._-.............|
00000040  fe 1f 2d e9 36 0f 07 ee  fe 1f bd e8 1e ff 2f e1  |..-.6........./.|
00000050  fe 1f 2d e9 ba 0f 07 ee  3e 0f 07 ee 9a 0f 07 ee  |..-.....>.......|
00000060  fe 1f bd e8 1e ff 2f e1  fe 1f 2d e9 5f f0 7f f5  |....../...-._...|
00000070  3e 0f 07 ee 4f f0 7f f5  fe 1f bd e8 1e ff 2f e1  |>...O........./.|
00000080  10 1f 11 ee 02 1a c1 e3  00 10 81 e1 10 1f 01 ee  |................|
00000090  4f f0 7f f5 1e ff 2f e1  00 10 0f e1 01 1c c1 e3  |O...../.........|
root@OpenWrt:/# hexdump -C /dev/mtd4 | head -n10
00000000  27 05 19 56 4d e0 13 df  54 54 5a 1f 00 16 65 21  |'..VM...TTZ...e!|
00000010  00 00 80 00 00 00 80 00  1e 5c cd 8c 05 02 02 00  |.........\......|
00000020  41 52 4d 20 4f 70 65 6e  57 72 74 20 4c 69 6e 75  |ARM OpenWrt Linu|
00000030  78 2d 33 2e 31 34 2e 31  38 00 00 00 00 00 00 00  |x-3.14.18.......|
00000040  00 00 a0 e1 00 00 a0 e1  00 00 a0 e1 00 00 a0 e1  |................|
*
00000060  02 00 00 ea 18 28 6f 01  00 00 00 00 b8 2f 16 00  |.....(o....../..|
00000070  00 90 0f e1 f9 0d 00 eb  01 70 a0 e1 02 80 a0 e1  |.........p......|
00000080  00 20 0f e1 03 00 12 e3  01 00 00 1a 17 00 a0 e3  |. ..............|
00000090  56 34 12 ef 00 00 0f e1  1a 00 20 e2 1f 00 10 e3  |V4........ .....|

$hexdump -C u-boot-v1.3.25.bin | head -n10
00000000  8b 00 00 00 00 61 0c 00  01 01 00 90 00 90 01 00  |.....a..........|
00000010  00 00 00 00 00 00 00 00  00 02 01 00 00 00 01 da  |................|
00000020  02 01 98 80 02 00 00 00  5b 00 00 00 68 00 00 00  |........[...h...|
00000030  ff 5f 2d e9 1c 00 00 fa  00 00 a0 e3 ff 9f bd e8  |._-.............|
00000040  fe 1f 2d e9 36 0f 07 ee  fe 1f bd e8 1e ff 2f e1  |..-.6........./.|
00000050  fe 1f 2d e9 ba 0f 07 ee  3e 0f 07 ee 9a 0f 07 ee  |..-.....>.......|
00000060  fe 1f bd e8 1e ff 2f e1  fe 1f 2d e9 5f f0 7f f5  |....../...-._...|
00000070  3e 0f 07 ee 4f f0 7f f5  fe 1f bd e8 1e ff 2f e1  |>...O........./.|
00000080  10 1f 11 ee 02 1a c1 e3  00 10 81 e1 10 1f 01 ee  |................|
00000090  4f f0 7f f5 1e ff 2f e1  00 10 0f e1 01 1c c1 e3  |O...../.........|

$hexdump -C u-boot-v1.3.25.bin.kwb | head -n10
00000000  27 05 19 56 41 6d 6b c6  54 5e d7 aa 00 0d f1 00  |'..VAmk.T^......|
00000010  00 00 00 00 00 00 00 00  e9 b0 7d 9d 05 02 02 01  |..........}.....|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000040  8b 00 00 00 00 61 0c 00  01 01 00 90 00 90 01 00  |.....a..........|
00000050  00 00 00 00 00 00 00 00  00 02 01 00 00 00 01 da  |................|
00000060  02 01 98 80 02 00 00 00  5b 00 00 00 68 00 00 00  |........[...h...|
00000070  ff 5f 2d e9 1c 00 00 fa  00 00 a0 e3 ff 9f bd e8  |._-.............|
00000080  fe 1f 2d e9 36 0f 07 ee  fe 1f bd e8 1e ff 2f e1  |..-.6........./.|
00000090  fe 1f 2d e9 ba 0f 07 ee  3e 0f 07 ee 9a 0f 07 ee  |..-.....>.......|

Note that the header of my running uboot image looks like u-boot-v1.3.25.bin.  u-boot-v1.3.25.bin.kwb has a header similar to a kernel image.  It looks like mkimage only added 64 bytes to the whole image (I think those bytes are the magic that tells the loader "Hey, this is a kernel image"):

$wc -c u-boot-v1.3.25.bin*
 913664 u-boot-v1.3.25.bin
 913728 u-boot-v1.3.25.bin.kwb
1827392 total

(Last edited by mmilburn on 9 Nov 2014, 09:00)

wlan-v7 firmware analysis follow along [part 2/?]:

Did some more thinking about the firmware file today.  Write-up is here:
https://github.com/mmilburn/88W8764-fir … n-20141108

@mmilburn

My router's u-boot is corrupt, it doesn't load but I found a way to transfer it from a Linux machine, however, the tool needs a .kwb image, .bin errors out while transferring. Got a u-boot file for a different armada xp box (mirabox, taken from here: http://1wt.eu/articles/mirabox-vs-guruplug/ that gets transferred fine but doesn't boot (obviously). That .kwb image says it is made for Kirkwood, that's why I asked. Will try it very soon and come back with my result. Thanks a lot for now.

nitroshift

PS. On the other hand, if you could dump your router's u-boot image in .kwb format, that would be really helpful in reviving my router.

EDIT:

Tried the .kwb file made by mmilburn, errors out with "Invalid Header Checksum". I feel I'm getting closer to reviving my unit, I only need a working u-boot.kwb file for this router.

(Last edited by nitroshift on 9 Nov 2014, 13:12)

Hi guys just quickly wanted to share how to get Multi-ssid running on 1.0.5 MCWRT
it seems the Marvel driver creates sub-interfaces automatic but openwrt doesn't use them as they are non standard.
the easiest way to get the multi-ssid running is the follow

open /etc/config/wireless

duplicate the following statements in the config

config wifi-device 'wdev0'
        option type 'marvell'
        option wmm '1'
        option htbw '0'
        option disabled '0'
        option channel '6'
        option hwmode '11an'

config wifi-iface
        option device_name 'MAMBA'
        option manufacturer 'belkin.com'
        option device 'wdev0'
        option ifname 'wdev0ap0'
        option ampdutx '1'
        option amsdu '1'
        option mode 'ap'
        option wps_config 'label display push_button'
        option ssid 'piwifi-oman'
        option key 'mypassword'
        option doth '1'
        option compression '1'
        option bursting '1'
        option turbo '1'
        option ff '1'
        option wmm '1'
        option xr '1'
        option ar '1'
        option encryption 'psk2'

and replace wdev0 by wdev3 in all statements
and replace wdev0ap0 with wdev0ap1

if you want the 5ghz interface just use wdev1ap1

network restart and un luci you can now config your wdev3 interface
all real wifi related settings don't do anything, but you can change the authentication and so.
and get multi-ssid running until we get a wifi driver that follows the standards.

FYI
https://github.com/Chadster766/McWRT/issues/56

I'm starting to understand the problem now.  That URL is the key.  The writeup is excellent, but there are a few critical bits missing (like how he identified the header of the DDR initialization image).

Here's what's going on:
The uboot bin image taken from Mamba works, but it's not really a u-boot image.  This image (and consequently, what is running on every WRT1900ac) is actually the output of the 'doimage' utility described in that writeup.  This image is marvell specific binary with a DDR init module and uboot embedded inside of it.

The kwb format is neither here nor there.  What needs to be done is to:
a) study the doimage code to understand the marvell binary format (so one can correctly extract the embedded images)
b) extract the ddr init image from our uboot bin
c) extract uboot image from our uboot bin
d) patch ddr init image to output on something other than the serial interface (this is described in the writeup)
e) build a recovery image using the extracted and patched images with doimage (doimage -T uart ...)

One can build the doimage tool by grabbing u-boot code.  Just go ahead and grab a copy of uboot.  Specific version doesn't seem to matter too much, but a marvell specific branch is here http://git.denx.de/?p=u-boot/u-boot-mar … ;a=summary.  Then, look at the readup again, and follow the instructions for obtaining and applying that patch so you can get a copy of the doimage code.  After doing that, go into the uboot checkout, run make menuconfig and make sure the "sandbox" arch is selected.  Save changes.  Run make tools.  Doimage should be built now.  At this point, you'll have to read through the doimage code to understand the format of our uboot image.  Once you can confirm the init images contained within our uboot image, extract them and use doimage to build your recovery image.  It should be noted that the ddr init will probably have to be patched to not output to the serial console, unfortunately, I do not know where the output should go.

I was able to find the start of the ddr image last night, unfortunately, I did not have a good enough understanding of the code to find the start and end positions of each init image.

Also, I have no reason to believe that Marvell would see this, but I just want to vent some frustrations in a public place.

WTF IS UP WITH YOUR CODE MARVELL?  The only exception seems to be the linux kernel (because they won't let you commit trash).  All the code of yours that I seem to find are:
1. crazy hackjobs
2. have 20kb of nonsensical license headers (either default to the most permissive one, or select the one that applies to the project)
3. contained within gigantic, braindead patches that seem to be inevitably rejected (with good reason) and are scattered across the internet.

Where is your GPL page?  You could keep all your crazy patches there.  I'm really starting to believe you're maintaining GPL compliance in the most antagonistic way possible.

Thank goodness for the free electrons people.

Looks like you could get the ddr image from here: https://patchwork.ozlabs.org/project/ub … egate=1696

Assuming you have a cross-compiler setup.  Given the information detailed in that patchset, mainline uboot may not be too far away from fully supporting this device.

Thanks @mmilburn

I have read EVERYTHING you wrote above but unfortunately I'm not proficient in Linux almost at all. That's why I came to ask you for help. Could you or Chadster build a u-boot.kwb that I can transfer to the router and boot it up? On the other hand I was thinking to get in touch with Linksys / Belkin and ask them nicely to send me the file I need. Unfortunately it's too early to phone them up but I will definitely try this option too and come back with their reply.

nitroshift

Thanks I added this to the OpenWRT McWRT Wiki.

Belkin declined to send me a working copy of u-boot.

nitroshift

I will build an image.  It will take me some time.

@mmilburn

I really appreciate your work and time to help me. Once I have the file I will write a how-to and ask Chadster to make me a contributor so others can benefit too.

nitroshift

Quick questions,

Can we use uhttpd (http://wiki.openwrt.org/doc/howto/http.uhttpd)? Benefits?

Will McWRT focus on Luci2 (http://wiki.openwrt.org/doc/techref/luci2)?

Finally would incorporating systemd be possible or beneficial?

Thanks,

lifehacksback

1.  I think we're already using uhttpd?  I don't have a way to confirm at the moment, I broke my dyn dns.

2.  No one has voiced a desire to work on that, you're welcome to look into it.

3.  I would be hesitant to use anything other than OpenWRT's default system architecture simply because I have a strong suspicion that we'd never be allowed to push the changes back into the mainline.

OpenWRT architecture overview:
http://wiki.openwrt.org/doc/techref/pro … chitecture

Someone has done it, but it looks like some core OpenWRT systems (like overlayfs) don't work from the get go.
https://forum.openwrt.org/viewtopic.php?id=49599

Is there some reason why you'd like to run systemd?

(Last edited by mmilburn on 11 Nov 2014, 00:39)

Yes! Apparently uhttpd is a dependency for LuCi.

I'll try my best to look into it

I see. Maybe (later on) I'll try to fork McWRT and try to integrate systemd and test performance.

Speed mainly and the nice structure it has. I want to learn system administration and mastering one of these would be nice, and since systemd is so popular i was wondering if we could at lease try to see if porting it would work! idk just something im curious about.

---------------------------------------------------------------------------------------------------------------------------------------------------

Reading the port-in-progress here is the code to integrate systemd (https://github.com/aport/openwrt-systemd) into Openwrt. I dont know why I have such facination for systemd but i want to at lease want to toy around with this idea.

Anyone can help me set up a build environment on ubuntu to build an image? (PS if you need someone to make an image just ask me I have 2 quad core computer that I can leave on for lon periods of time [one has ssds to speed up the process])

Thanks Again,
lifehacksback

(Last edited by lifehacksback on 11 Nov 2014, 03:23)

General OpenWRT build info:
http://wiki.openwrt.org/doc/howto/buildroot.exigence

All the pre-reqs (I think it has some stuff in there that is no longer required, but whatever):
http://wiki.openwrt.org/doc/howto/build … tallations

More specific build info:
https://github.com/Chadster766/McWRT/wiki/Building

@mmilburn

Here's the output of cat /proc/mtd:

mtd0: 00100000 00020000 "uboot"
mtd1: 00040000 00020000 "u_env"
mtd2: 00040000 00020000 "s_env"
mtd3: 00100000 00020000 "devinfo"
mtd4: 02800000 00020000 "kernel"
mtd5: 02500000 00020000 "rootfs"
mtd6: 02800000 00020000 "alt_kernel"
mtd7: 02500000 00020000 "alt_rootfs"
mtd8: 05000000 00020000 "ubifs"
mtd9: 02600000 00020000 "syscfg"

Maybe it helps figuring out the offset and size of mtd0.

nitroshift

Had another talk with Linksys Customer Support and the lady I talked to said that she will make everything possible to send me today the u-boot.kwb file needed. Will come back with the result.

nitroshift

Chad,

have you had any help on this? I too have been able to build the Chaos Calmer image but it does not generate a flashable factory image, just sysupgrades.

Do you frequent the Openwrt irc channel? Perhaps one of the developers might be able to weigh in on this.

What is the exact ddr image from that link?

nitroshift

I also just bought for 1 Euro (~1.25 USD) a USB to TTL adapter from here: http://www.ebay.com/itm/111454965049?_t … EBIDX%3AIT

(Last edited by nitroshift on 12 Nov 2014, 10:10)

Just an update

1) I got a rig set up with Ubuntu Gnome 14.10 (I wanted to test the early iterations of systemd and I like ubuntu [long story]) I followed the guide in the github repo and installed everything along with cloning the source. While building there were a bunch of [Y/n/?] or [N/y/?] or [Y/m/?] i just allowed the "default" but since I wasnt sure what I was doing I stopped the build. What are those thing? and why werent they set in the makeconfig screen?

2) Still waiting for the TTY to USB adapter... man i should have just bought one from amazon lol.

3) What version of the kernel will CC use? I wanted to see if maybe file systems could be build so the router could detect my external HDD that may be formatted in btrfs or xfs.

Edit:
Reading through the wiki i see that btrfs is supported. Did they backport btrfs or is it an old iteration?

-lifehacksback

(Last edited by lifehacksback on 12 Nov 2014, 10:51)

Update:

Linksys declined again to send me u-boot.kwb... Waiting for @mmilburn to revive my unit and the RMA to get a new one.

nitroshift

In that patchset, there is C code for the ddr driver (this becomes the image).  I did some more looking into it last night, and decided against using it right now.  My reasoning is as follows:
1)  Gotta do a little messing around to build said DDR image
2)  DDR image is not guaranteed to be the same version, or necessarily compatible with the u-boot binary you will need
3)  For lack of a concise way to express it, I still have to extract the "core" u-boot binary from our u-boot image.  Given the structure of the file, I need to know the offset and length of each previous image embedded in our u-boot to find the start of the next image (so I'll have to find the start and length of the DDR image embedded in our u-boot anyway).  At the moment, I'm screwing up my math somehow.  I know where the DDR image starts, and the address at which it gives me the length of the image, I'm just somehow computing the jump to the end of the image incorrectly.

relevant code bits from doimage_armada_xp/boostrap_os.h:

typedef struct BHR_t
{
//      type            name                byte order
        MV_U8           blockID;                //0
        MV_U8           rsvd1;                  //1
        MV_U16          nandPageSize;           //2-3
        MV_U32          blockSize;              //4-7
        MV_U8           version;                //8
        MV_U8           hdrSizeMsb;             //9
        MV_U16          hdrSizeLsb;             //10-11
        MV_U32          sourceAddr;             //12-15
        MV_U32          destinationAddr;        //16-19
        MV_U32          executionAddr;          //20-23
        MV_U8           rsvd3;                  //24
        MV_U8           nandBlockSize;          //25
        MV_U8           nandTechnology;         //26
        MV_U8           rsvd4;                  //27
        MV_U16          rsvd2;                  //28-29
        MV_U8           ext;                    //30
        MV_U8           checkSum;               //31

} BHR_t, * pBHR_t;

#define MAIN_HDR_GET_LEN(pHdr)  \
        (((MV_U32)((pHdr)->hdrSizeMsb) << 16) | ((MV_U32)((pHdr)->hdrSizeLsb)))

#define EXT_HDR_TYP_SECURITY    0x01
#define EXT_HDR_TYP_BINARY      0x02
#define EXT_HDR_TYP_REGISTER    0x03

typedef struct headExtBHR_t /* Common extention header head */
{
//  type        name        byte order
        MV_U8           type;
        MV_U8           lenMsb;
        MV_U16          lenLsb;

} headExtBHR_t;

#define EXT_HDR_SET_LEN(pHead, len)     \
        do {\
                (pHead)->lenMsb = ((len) & 0x00FF0000) >> 16;\
                (pHead)->lenLsb =  (len) & 0x0000FFFF;\
        } while(0)

#define EXT_HDR_GET_LEN(pHead)  \
        (((MV_U32)((pHead)->lenMsb) << 16) | ((pHead)->lenLsb))

typedef struct tailExtBHR_t /* Common extention header tail */
{
// type        name        byte order
        MV_U8           nextHdr;
        MV_U8           delay;
        MV_U16          rsvd2;

} tailExtBHR_t;

...

/* Boot Type - block ID */
#define IBR_HDR_I2C_ID          0x4D
#define IBR_HDR_SPI_ID          0x5A
#define IBR_HDR_NAND_ID         0x8B
#define IBR_HDR_SATA_ID         0x78
#define IBR_HDR_PEX_ID          0x9C
#define IBR_HDR_UART_ID         0x69
#define IBR_DEF_ATTRIB          0x00

begining of u-boot-v1.3.25.bin:
(opened with vim u-boot-v1.3.25.bin then :%!xxd)

0000000: 8b00 0000 0061 0c00 0101 0090 0090 0100  .....a..........
0000010: 0000 0000 0000 0000 0002 0100 0000 01da  ................
0000020: 0201 9880 0200 0000 5b00 0000 6800 0000  ........[...h...
0000030: ff5f 2de9 1c00 00fa 0000 a0e3 ff9f bde8  ._-.............
0000040: fe1f 2de9 360f 07ee fe1f bde8 1eff 2fe1  ..-.6........./.

To help you make a little sense of the hex:
For your rescue u-boot image, we'll need that first byte to be a 0x69 instead of a 0x8b (IBR_HDR_UART_ID instead of IBR_HDR_NAND_ID), that part is easy though, we just pass -T uart to doimage.  Our first extension header "headExtBHR_t" starts at address 0x20.  First byte reads 0x02 so it's a EXT_HDR_TYP_BINARY, the second byte is 0x01 which is our "lenMsb", the next two bytes are the "lenLsb".  My hangup is that I'm putting lenMsb and lenLsb together incorrectly, and the resulting address doesn't have the start of the next image (I'm jumping to 0x19098 + 0x24, the next "headExtBHR_t" should be in that region).  I have a feeling I'm making some simple mistake.
Feel free to check my work.  Oh, and the start of the DDR image: 0200 0000 5b00 0000 matches what's here: http://1wt.eu/articles/mirabox-vs-guruplug/

(Last edited by mmilburn on 12 Nov 2014, 22:29)