OpenWrt Forum Archive

Topic: Di-624

The content of this topic has been archived between 29 Mar 2018 and 22 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

I was wondering if anyone here knows or could help me figure out the Jtag and or serial port on this router? It is currently bricked and I would like to try and debrick it. I have some knowledge of electronics. After it is debrick it I was hoping to maybe provide info on it and test open-WRT on it. It has two places for what looks to be pin headers
one 12pin and one 14 pin. This is a Version C1. It is currently turning on all LEDS except for the power,status, and WLAN. Also if this is the wrong forum I appologize.

Hi!!,

I got exactly this same problem big_smile, i bricked my 624 D1, anyway i found a guy who flashed his 624 C3 (unsuccessfully ;-)))
http://www.elektroda.pl/rtvforum/viewto … a4f34f079d
i already sent him an email about how to do it.

here's my board with supposed connectors
front:
http://img512.imageshack.us/img512/4024/frontte8.th.jpg
back:
http://img518.imageshack.us/img518/5228/backaz2.th.jpg


Cheers,
Marcin

(Last edited by BamboOS on 1 Jun 2007, 14:16)

Hi SilverChris
Unfortunately there isn't a JTAG tool that works with AR2315/AR2316 based devices, which is what yours is. The problem is that the flash is totally different to normal parallel flash. I'd keep watching the forum in case a new tool that supports SPI flash on Atheros is contributed by someone.

Mike

SilverChris and Bamboos,

  I've got one Netgear WRT624 V3 which has, apparently, the same hardware as yours. I mean, Atheros SOC ar2316, Marvell Switch 88E6060, SPI flash 25P16 and 16 MB of SDRAM.  I tried previously to get rid of the VXWORKS using Jtag (and the openwince libraries for atheros http://forum.openwrt.org/viewtopic.php?pid=46390) but I couldn't find the correct pin out. So, I decided to get rid of the VXWORKS building a Flash programmer to initially back up my Netgear's Firmware and after that I might be able to replace and upgrade its flash memory to 4 Mbytes (25p32).  Up to now, I could upgrade it  to 4MB and load, using the backed up vxworks bootloader copied onto the new flash , a fresh Redboot bootloader, which also had been a quest to get it compiled. The Redboot recognizes the ethernet switch, flash size and characteristics. I could even transfer the Redboot's ROM version through FTP and flash it as one would normally do.
   However, I ran into another drawback because when redboot is flashed my router gets bricked. I believe, after confirming that the flash memory had been flashed properly with my newly built flasher,  that there is some difference between the binary image created ehen compared to its  ".elf" version, which runs properly when loaded through FTP. I have checked that the Elf header is stripped of when the bin or rom format is generated and some minor differences have also been found. Since I dont have a Mips disassembler, I am not able to check how the startup process is performed. Thats my next goal.
   As to your problem, I would suggest that you copy someone else's flash using a "flasher" like I built and burn your bricked router.

  Here are some photos that I have uploaded about this procedure on this post http://forum.openwrt.org/viewtopic.php?id=13455

Good luck.

(Last edited by amsjow on 21 Apr 2009, 19:33)

Hi, i've defeated di624.

sorry for a long story smile

Chapter one: full flash backup.

1. i've cheked contents of original upgrade firmware from dlink ftp site. it appeared to be of two kinds:
1 - 0x0e0000 size
2 - 0x100000 size

1st kind consists of an NML.ARJ file (yes, good oldies), zero pad, board id ("AP52-AR2316-RT       -00")
and checksum (32bit big-endian XOR with 0xaabbbbaa).

2nd kind consists of loader code, BAK.ARJ, zero pad, board id ("AP52-AR2316-RT       -00") and 1st part.

I've used IDA to disassemble loader and archive contents (BAK.MEM, NML.MEM).

Loader itself consists of two parts: first - set up sdram controller, loads the second part at the end of the ram
and executes it. second part (depending on reset button GPIO state) unarj either BAK.ARJ or NML.ARJ to
0x80000000 addess and executes it. So, it;s quite safe to upload whatever firmware with size 0xe0000, since it
wont affect loader and BAK.ARJ content. If something goes wrong - power off, press reset button, and power
on holding reset button. It will boot up from BAK.ARJ - enable LAN ports only, set default IP 192.168.0.1 and
launch web interface with single page - firmware upgrade.

I've patched NML.MEM to get full flash dump: it's quite easy: locate any static page contents in NML.MEM,
calculate it's address (assuming NML.MEM is started at 0x80000000), search for calculated pinter - if you
hit only one match - it's web contents table. Look around for page size. Alter pointer to be 0xbfc00000
(spi flash mirror start address) and alter page size to be 0x200000 (di624 has 2Mb flash).
Pack up NML.MEM to NML.ARJ, pad and append signature and checksum, so the resulting file will be 0xe0000
length. boot up normally and wget hacked page.

Chapter two: uart.

i built toolchain for mipsisa32 target and wrote a trivial asm code to blink status led, create firmware image
(as above) and check if it works. after a few tries it does. then i extend that code with a few instructions to
constantly write 0x55 to the serial port at 9600 (per ar531x headers). then i took audio amplifier jack in right
hand (holding fingers on outer metal ring) and hold the board ground in the left hand, with cetral terminal of
the audio jack i test the pins of supposed connectors (shown on your photos above) and finaly hear the buzzing
sound on pin 5 of front connector. this is serial tx. as you may understand i lack osciloscope. same for solder
station wires, etc.. tx output is LVTTL and inverted to rs232 levels.. i have no max ic and wont be able to
solder it event if i have it. so i do the very bad thing: cut the wire from the old COM port mouse, and connect
it directly to the board:
pc rx --->  board +3.3v (pin 1)
pc gnd ---> board tx (pin 5)
LVTTL is _INVERTED_ to the normal rs232 levels, so i had to do this weird stuff. it;s VERY dangerous:
you may burn both uarts. and whatever happen, dont connect pc tx anywhere - its -12v which may
draw enough current to burn the whole board.

Chapter three: redboot

I've packed redboot image to NML.ARJ and fix it up as described in chapter one to make original loader start it.
There was a lot of hacking of redboot startup code: major goal is to disable watchdog (enabled by
firmware loader), mix up rom/ram sections layout ld scripts:
i.e. it should have reset/trap/other handlers like in ROM model,
but memory layout should be like in RAM model
and it;s not ROMRAM model since there should be no code to copy from ROM to RAM.
I dont have diff ready, if you find it interesing - i'll provide it.
After a bit of hacking you will see redboot prompt on the serial port, but you will not be able to type anything
in, unless you are the lucky one and have rs232 to LVTTL converter. otherwise you will need to configure
redboot to accept telnet connections. (as i did)

Chapter four: linux

i've picked up source tarball from dlink ftp site.
when i realized it was a bad idea, it was too late.
nothing special about linux itself - its started quite smoothly.. (i've used tftp to load it via bootp - no flashing)
one thing is important - arch support code lacks memory size detection. 16m is hardcoded, although di624
has only 8m of ram, so you have to set mem=8m on the command line, otherwise you'll get accidental
crashes.

Chapter five: madwifi

I've failed to build madwifi from dlink tarball, so i picked up the latest from madwifi site.
While configured with CONFIG_AR5315, get_system_type returns "Atheros AR531X_COBRA"
instead of "Atheros AR5315" as expect by madwifi driver. i've fixed it. Then there was a real nightmare:
somehow di624 has no board config data on flash. only radio config. digging original code, i found similar
structure created on the fly, so i did the same: i've filled board configuration structure manually and
pass it to the HAL driver (radio config search algo was changed too, so it wont depend on board config address
any more). Next i spent huge amount of time before i understand that module load order is important for
madwifi: if i load scan module prior to ath_ahb, ifconfig athX up will fail for unknown reason.
after all it works well.
details on request.

Chapter six: marvell phy + eth driver

88E6060 lacks 802.1Q VLAN support, it rather generates custom 4-byte trailer (which is not supported by
ae231x eth driver). I've added "hardvare accelerated" VLAN support for marver trailers, so now
CONFIG_VENETDEV may be defined to use Di624 as a router, not only as a bridge.
details on request.

CPU revision is: 00019064
Primary instruction cache 16kB, physically tagged, 4-way, linesize 16 bytes.
Primary data cache 16kB 4-way, linesize 16 bytes.
Linux version 2.4.25-LSDK-5.0.0-RC5 (root@aargh) (gcc version 3.3.5) #113 Tue Nov 6 09:58:13 EST 2007
Determined physical RAM map:
 memory: 01000000 @ 00000000 (usable)
User-defined physical RAM map:
 memory: 00800000 @ 00000000 (usable)
Initial ramdisk at: 0x8020a000 (1171456 bytes)
On node 0 totalpages: 2048
zone(0): 2048 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: mem=8m console=ttyS0,9600 root=/dev/ram
Using 92.000 MHz high precision timer.
Calibrating delay loop... 183.50 BogoMIPS
Memory: 4676k/8192k available (1639k kernel code, 3516k reserved, 1240k data, 80k init, 0k highmem)
Dentry cache hash table entries: 1024 (order: 1, 8192 bytes)
Inode cache hash table entries: 512 (order: 0, 4096 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 2048 (order: 1, 8192 bytes)
Checking for 'wait' instruction...  unavailable.
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x1
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with no serial options enabled

ttyS00 at 0xb1100003 (irq = 37) is a 16550A
HDLC line discipline: version $Revision: #1 $, maxframe=4096
N_HDLC line discipline registered.
Generic MIPS RTC Driver v1.0
RAMDISK driver initialized: 16 RAM disks of 2048K size 1024 blocksize
wlan: 0.8.4.2 (Atheros/multi-bss)
wlan: mac acl policy registered
PPP generic driver version 2.4.2
Initializing Cryptographic API
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 512 bind 1024)
ip_conntrack version 2.1 (64 buckets, 512 max) - 352 bytes per conntrack
ip_conntrack_pptp version 1.9 loaded
ip_nat_pptp version 1.5 loaded
ip_tables: (C) 2000-2002 Netfilter core team
ipt_time loading
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NET4: Ethernet Bridge 008 for NET4.0
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
All bugs added by David S. Miller <davem@redhat.com>
RAMDISK: squashfs filesystem found at block 0
RAMDISK: Loading 1144 blocks [1 disk] into ram disk... done.
Freeing initrd memory: 1144k freed
VFS: Mounted root (squashfs filesystem) readonly.
Mounted devfs on /dev
Freeing unused kernel memory: 80k freed
Algorithmics/MIPS FPU Emulator v1.5
REDSonic turbo net initialized
Network interface reset count v1.0
wlan: 0.8.4.2 (0.9.3.3)
ath_hal: 0.9.18.0 (AR5212, AR5312, RF2316, TX_DESC_SWAP)
ath_rate_sample: 1.2 (0.9.3.3)
ath_ahb: 0.9.4.5 (0.9.3.3)
wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: turboG rates: 6Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: H/W encryption support: WEP AES AES_CCM TKIP
wifi0: mac 11.0 phy 4.8 radio 7.0
wifi0: Use hw queue 1 for WME_AC_BE traffic
wifi0: Use hw queue 0 for WME_AC_BK traffic
wifi0: Use hw queue 2 for WME_AC_VI traffic
wifi0: Use hw queue 3 for WME_AC_VO traffic
wifi0: Use hw queue 8 for CAB traffic
wifi0: Use hw queue 9 for beacons
unable to load wlan_scan_ap
wifi0: Atheros 2315 WiSoC: mem=0xb0000000, irq=3
ar231x gpio driver.
Found PHY ethmac0 port0: model 0x8 revision 0x7
Found PHY switch for enet 0 port 0 deviceID 0x60 revision 0x2
Found PHY ethmac0 port1: model 0x8 revision 0x7
Found PHY switch for enet 0 port 1 deviceID 0x60 revision 0x2
Found PHY ethmac0 port2: model 0x8 revision 0x7
Found PHY switch for enet 0 port 2 deviceID 0x60 revision 0x2
Found PHY ethmac0 port3: model 0x8 revision 0x7
Found PHY switch for enet 0 port 3 deviceID 0x60 revision 0x2
Found PHY ethmac0 port4: model 0x8 revision 0x7
Found PHY switch for enet 0 port 4 deviceID 0x60 revision 0x2
ethmac0: Phy Status=0000
ethmac0: Phy Status=0000
ethmac0: Phy Status=0040
ethmac0: Phy Status=0040
ethmac0: Phy Status=0000
device ath0 entered promiscuous mode
vlan1: dev_set_promiscuity(master, 1)
device eth0 entered promiscuous mode
device vlan1 entered promiscuous mode
br0: port 1(ath0) multicast bandwidth 900kbps
br0: port 2(vlan1) entering learning state
br0: port 1(ath0) entering learning state
ath0      Link encap:Ethernet  HWaddr 00:00:11:11:11:11  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1504785 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1451124 errors:0 dropped:6 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:124189647 (118.4 MiB)  TX bytes:1407927404 (1.3 GiB)

br0       Link encap:Ethernet  HWaddr 00:00:11:11:11:11  
          inet addr:192.168.118.1  Bcast:192.168.118.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1952566 errors:0 dropped:0 overruns:0 frame:0
          TX packets:140399 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:190911226 (182.0 MiB)  TX bytes:23747842 (22.6 MiB)

eth0      Link encap:Ethernet  HWaddr 00:62:40:16:00:01  
          UP BROADCAST RUNNING MULTICAST  MTU:1504  Metric:1
          RX packets:3749982 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3008783 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1859894781 (1.7 GiB)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback  
          LOOPBACK  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

ppp0      Link encap:Point-Point Protocol  
          inet addr:85.238.108.99  P-t-P:195.138.80.168  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:1709255 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1668188 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:1485426217 (1.3 GiB)  TX bytes:181011776 (172.6 MiB)

vlan1     Link encap:Ethernet  HWaddr 00:62:40:16:00:01  
          UP BROADCAST RUNNING MULTICAST  MTU:1504  Metric:1
          RX packets:1415516 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1329438 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:246753109 (235.3 MiB)  TX bytes:294086243 (280.4 MiB)

vlan2     Link encap:Ethernet  HWaddr 00:02:B3:BC:D6:26  
          UP BROADCAST RUNNING MULTICAST  MTU:1504  Metric:1
          RX packets:2334466 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1679346 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:1560641924 (1.4 GiB)  TX bytes:218046914 (207.9 MiB)

wifi0     Link encap:Ethernet  HWaddr 00:00:11:11:11:11  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1547789 errors:0 dropped:0 overruns:0 frame:825
          TX packets:1491473 errors:756 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:199 
          RX bytes:163167513 (155.6 MiB)  TX bytes:1447709447 (1.3 GiB)
          Interrupt:3 Memory:b0000000-b00ffffc
# iwconfig ath0
ath0      IEEE 802.11g  ESSID:"bubu"  
          Mode:Master  Frequency:2.412000 GHz  Access Point: 00:00:11:11:11:11  
          Bit Rate:0kb/s   Tx-Power:18 dBm   Sensitivity=1/1  
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality:50/70  Signal level:-46 dBm  Noise level:-96 dBm
          Rx invalid nwid:22  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

unicorn, so you are now running openwrt on your 624?
that's very interesting ...
i wonder could this be accomplished on 624+ ? (1Mb flash)

Hi Mega Therion,

yes i'm running linux on Di624.
624+ is not atheros. Its rather brecis cpu. But i can't see why not.
Perhaps there should be some other magic to do...

1Mb flash wont be a problem if you are planning to boot from the network.
My version of redboot with network support is only 70k, and i'm sure it's not the best.

It may be a problem if you whish to build the whole monster on 1Mb flash.
In my case (2Mb) it was a bit frustrating. Here's my memory layout
(it looks a bit weird, since i want to be able to reflash original fw at any time - device is not mine, actually):

00000000  original loader + BAK.ARJ (backup fw - activated by holding <reset> while powering on)
00020000  squashfs_lzma
00100000  redboot compressed in NML.ARJ
00130000  kernel.gz
001d0000  redboot config
001e0000  FIS directory
001f0000  radio config

i.e. there are only 640Kb (0xa0000) for kernel and only 900Kb (0xe0000) for rootfs.

If i had only 1Mb flash i would find 3 unused GPIOs onboard and glue-in any SD/MMC flash with the root file system.
Actually, i'm not sure i would even try to fit kernel or rootfs on this flash - i dont think it'll be very hard to add support
for a custom SD flash driver to the redboot.

unicorn, any advice where i should start(i am actually slightly confused as of what  i need to do)?
btw all di-624+ firmware updates i saw where 917504 arj packed files which unack to ~2211752 NML.MEM
so it seems that loader and backup firmware are always untouched

Theli,

a) make sure backup loader works on your hardware: power up router holding reset button.
(board should use 192.168.0.1 as LAN address and running single html page proposing to upload new firmware)

b) use IDA or some other tool to disassemble the original firmware...

c) to experiment you should learn how to compose firmware images - it's quite easy:
* pack up NML.MEM to NML.ARJ
* pad it with zeroes to be exactly 0xe0000 (917504) bytes len
* add signature as in original firmware (string like "AP52-AR2316-RT       -00" - you should take it from original image) at the same offset at the end of the file.
* add checksum (32bit XOR all over the file with constant 0xabbbba) at the last 32bit word

You can use something like this to make fw image from NML.ARJ file:

#!/usr/bin/perl 

undef $/; 

$board="AP52-AR2316-RT       -00";
$buf=<>;
$buf=pack "a" . (0xe0000-0x20) . "a" . (0x20-4), $buf, $board;

$s=0xaabbbbaa; 
$s ^= $_ foreach unpack "N*", $buf; 

print $buf, pack "N", $s;

..well.. not much helping, I know. sorry. at least i'm tring not to speak with riddles

unicorn wrote:

..well.. not much helping, I know. sorry. at least i'm tring not to speak with riddles

thanks wink

Also, look here http://www.linux-mips.org/wiki/Brecis_SOC
There is a bunch of usefull links.. seems like msp2006 is supported by mips-linux.
hope msp2007 does not differ much

hm ... i had a time and opened my 624+ ... it has not brecis but .... TNETW5306PYP cpu ... so i guess it'll never run linux sad

(Last edited by theli on 16 Dec 2007, 15:50)

Theli,

Why not, if it runs the same firmware that was designed for 624+ which originally have brecis cpu?

unicorn wrote:

Theli,

Why not, if it runs the same firmware that was designed for 624+ which originally have brecis cpu?

no, there are different firmwares for different hardware revisions
and i haven't found any references to running code on this CPU's using freely availible tools

Hi unicorn

Thanks for your work.
Is it possible to have your custom redboot and your compiled openwrt for the DI-624?
I have a DI-624 Rev. C with serial and jtag

Thank you

(Last edited by ramponis on 23 Oct 2008, 10:38)

Hi ramponis,

Look for ecos (redboot) patches at http://oldwiki.openwrt.org/WingedUnicorn.html

I'm not using openwrt as it is. I've just extended mips kernel 2.4.25, madwifi (see patches at the same url),
and build busybox and several usefull tools like tcpdump and such.

Regards

(url fixed)

(Last edited by unicorn on 21 May 2009, 19:14)

So, it looks like the DI 624 Rev C can be upgraded, but is there any hope for a rev A?  I am sure not, but I have an extra one and would love to put it to work as a bridge if possible. 

Thanks.
Chris

Sorry, chrisbac. I have no information regarding rev. A.
As you can see, dlink devices differ considerably from revision to revision even though they are all Di624.
Perhaps you may use the same approach I've described above to exploit your own device.
The rule of thumb: if it has at least 4Mb RAM and MIPS-based cpu with MMU feature, it will run Linux,
although you may need to port some drivers or even write them from scratch.

unicorn,

I have compiled the linux sources from dlinks site and it produced a .img. with 1843232 bytes, how is It possible to get a .bin with just 917504 bytes from this .img, so I can flash the di624 with from the web gui.

(Last edited by hugo.freire on 8 Feb 2009, 01:16)

Hi hugo.freire,

It is not necessary to build the whole thing in one image (dlink scripts try to include rootfs in kernel image).
If I remember correct, I've built only redboot as dlink firmware upgrade image (i.e. w/o kernel and rootfs).
Latter, I've separately flashed bziped kernel and squashfsed image of root filesystem using redboot console (via telnet).
(Check my posts from 2007-12-10 08:11:37 and 2007-12-09 01:59:00)

In the flash layout (which i I was using) there were 640kB for kernel and 900kB for rootfs squashfs.
But you can use any FIS partition layout you like as long as
1) first 0x20000 bytes (original zero-phase and backup loader) remain untouched
and
2) NML.ARJ with redboot is started at 0x100000.

It was a bit frustrating to build 640kB kernel with all required features.
Moreover i had to throw away all http features from userland to fit the image in 900kB.
In fact, I did not run original dlink userland. I've just crosscompilled moderate number of plain BusyBox tools and other stuff like tcpdump.

Currently I found it is more convenient to boot this device from the network. I.e. the only software I'm running right now from flash is redboot. Kernel is loaded via tftp
and rootfs is mounted as NFS.

Regards,
unicorn

Hi surrealiz3,

Can you please, elaborate what are you succeeded with?
Did you managed to grab whole flash?
As I noticed by quick googling, usr8054 has TI chip..
It's not Atheros, so I hope you understand that none addresses or sizes described by me is applicable in your case as is.
You should use IDA or some other tool to disassemble original firmware (loader is not very big and hairy, objdump from binutils will be enough).
If your device support DLink images, and that files follow the same idea of "BAK and NML" images, start from disassembling of BAK.MEM image.
That will give you basic knowledge about flash start address/size and location in RAM where the main image (NML.MEM) is unpacked.

To run your own code _instead of original firmware_ you will need to replace NML.MEM with file produced by your cross compiler.
I.e. you should pack your "a.out" in NML.ARJ with arj tool and build firmware image which will be recognized as "DLink firmware'.
You may use perl script posted above as example, but you should replace hw-dependant "signature" and possibly image sizes
with one in your original firmware file. Be careful selecting firmware size: it should be "small" one, i.e. the one, w/o BAK.ARJ.
Otherwise backup loader will be erased and you will no longer be able to reflash your brick. (unless you have JTAG or other hw approach)

About status led blinking. It is likely that this led is connected to some GPIO port on your processor, but there is no way to guess how to use it.
You should either have processor specification, or you should disassemble original firmware and find how it is done there.
In first case you should find out which processor pin is connected to the led. This is quite simple if you have multimeter... unless processor is in BGA case
(pins are under the case and not accessible). Latter approach will work even w/o cpu specs and multimeter, but require much more time and decent knowledge of
target assembler. Also, good reverse engineering tool like IDA will be very helpful.


Regards,
Viktor

I have a di624 rev c

I wanted to flash it with white Russian. On my other router I found the firm wear section in the router and just uploaded the firm wear. Was not very hard at all.

However in trying to find instructions on upgrading the firm wear on my d-link di-624 I found this post.

Quite frankly trying to read the post above made my eyes bleed. I think I will have to see the doctor seriously. I understood a few terms like jtag etc.

Is there a way that mere mortals like myself could actually upgrade my firm wear.  Something simple like

1. download this.
2. go to the firm wear section
3. load firm-wear
4. restart router.

I am looking for the noob version, I am a computer tech but I don'w write software just troubleshoot and repair broken computers and printers.
Anything like this? There is no way I would attempt the above.

I wish I understood the above stuff, I don't- it hurt just to read it.

catshazam,

first of all, above instructions were intended for WRT geeks mostly, hoping they will add support for this router some day based on my investigation.
I'm not WRT developer, nor dlink firmware author. I just prefer spending my free time digging some piece of hw, instead of watching TV.
As far as I understand, there is no much interest in this particular device to add WRT support for.
For instance, it has only 2MB flash, which is not enough to store decent 'universal' linux distribution.
Currently, I'm running custom kernel release on Di624 with own limited set of tools and busybox utilities, which exactly suits my needs. It is not even WRT-based.
As I see it, you have two choices (well, three actually):
1) take your time and understand instructions listed above (you wont need WRT after that);
2) make official request for WRT support for this device (referring to this thread which proves that this is possible);
3) forget about it.

Regards

I downgraded my firmware in the di 624 and it quit dropping internet, well mostly. It was terrible with the new firmware.

I was thinking I would just get a new router. I saw there were several people selling t Mobil routers on ebay with the newest open source firmware, a new heat sink and a bridge. The t Mobil routers have 32 mb in them. I dont know if I need all that but it sounds nifty.

If i switch to a supported router like this I can get on with other things.


If you have a router to recommend Or a firmware please let me know.



I also have a hawking HBB1 on the way that may help lag. They seem to organize qos. I think that's about all it does.

I use the internet to stream movies for my kiddos home school and surf the web. We also play halo against each other cause nothing helps a family like blowing each other up from time to time.