frackers wrote:More mtd info - I dumped mtd0 to an nfs mount and ran strings on it and I find the following (with addresses):
1aa30 bootargs=console=ttyS0,115200 root=31:02 rootfstype=jffs2 init=/sbin/init mtdparts=ar9100-nor0:128k(u-boot),1024k(kernel),4096k(rootfs),64k(art)
1aac1 bootcmd=bootm 0xbf020000
1aada bootdelay=1
1aae6 baudrate=115200
1aaf6 ethaddr=00:1D:0F:11:22:33
1ab10 ipaddr=192.168.0.2
1ab23 serverip=192.168.0.5
With these odd addresses I can't see how fw_printenv and fw-setenv can work - I'd expect the nvram data to be on an erase boundary.
Anyone got any clues?
Cheers
This is my first post on this board, and I'm no expert in this topic. But it seems to me that "saveenv" doesn't work, because there is no "saveenv" partition. That is also the reason nobody can find it
You don't have to hack the machine code, as the sources for the u-boot are available at http://www.tp-link.com/support/gpl.asp . Just select TL-WR1043ND, and in the .tar.gz file you file find u-boot-ap83.tar.bz2 file.
The settings are hard coded in the code, in the event that there is no valid saveenv partition. And there is none.
The listing from the first page of this topic:
U-Boot 1.1.4 (Sep 15 2009 - 09:41:38)
AP83 (ar9100) U-boot 0.0.11
DRAM:
sri
32 MB
id read 0x100000ff
flash size 8MB, sector count = 128
Flash: 8 MB
Using default environment
In: serial
Out: serial
Err: serial
Net: ag7100_enet_initialize...
No valid address in Flash. Using fixed address
: cfg1 0xf cfg2 0x7114
eth0: 00:03:7f:09:0b:ad
eth0 up
eth0
Autobooting in 1 seconds## Booting image at bf020000 ...
Uncompressing Kernel Image ... OK
Starting kernel ...
The code that does this is in /u-boot-ap83/cpu/mips/ar7100/ag7100.c file:
/* Use fixed address if the above address is invalid */
if (mac[0] == 0xff && mac[5] == 0xff) {
mac[0] = 0x00;
mac[1] = 0x03;
mac[2] = 0x7f;
mac[3] = 0x09;
mac[4] = 0x0b;
mac[5] = 0xad;
printf("No valid address in Flash. Using fixed address\n");
} else {
printf("Fetching MAC Address from 0x%p\n", __func__, eeprom);
}
The settings of ethaddr, ipaddr, serverip are hard coded in the ap83.h file:
#define CONFIG_IPADDR 192.168.0.2
#define CONFIG_SERVERIP 192.168.0.5
#define CONFIG_ETHADDR 00:1D:0F:11:22:33 //00:00:00:00:00:00
#define CFG_FAULT_ECHO_LINK_DOWN 1
#define CONFIG_PHY_GIGE 1 /* GbE speed/duplex detect */
//#define CFG_VSC8601_PHY
//#define CFG_VITESSE_8601_7395_PHY 1
#define CFG_AG7100_NMACS 1 // 2 /* changed by lsz 14Nov08 */
#define CONFIG_AR9100 1
//#define CFG_PHY_ADDR 0x14 /* Port 4 */
#define CFG_PHY_ADDR 0 /* Port 4 */
#define CFG_GMII 0
#define CFG_MII0_RGMII 1
#define CFG_BOOTM_LEN (16 << 20) /* 16 MB */
#undef DEBUG /* del by lsz 14Nov08 */
#undef CFG_HUSH_PARSER
#undef CFG_PROMPT_HUSH_PS2 "hush>"
As you can see, the fw_env.config contains this:
# Configuration file for fw_(printenv/saveenv) utility.
# Up to two entries are valid, in this case the redundand
# environment sector is assumed present.
# MTD device name Device offset Env. size Flash sector size
/dev/mtd1 0x0000 0x4000 0x4000
/dev/mtd2 0x0000 0x4000 0x4000
It obvious that sector (erase) sizes are not 0x4000. There is some info about fw_env.config at http://elinux.org/U-boot_environment_variables_in_linux . But neither setting is correct, otherwise the u-boot wouldn't compain that there is "No valid address in Flash." It makes sense, however, to hard code these few strings, to save the limited flash space.
I want to make my customized image for a larger deployment, but tinkering with the code will surely sooner or later result in a "bricked" router. It would be better, than messing with soldering cables, to customize u-boot to listen for 5 seconds before booting the OS, whether there is an incoming TFTP. Or to enter the safe mode, if you pressed the QSS or whatever button.
The u-boot sources should make a bootable binary. Otherwise TP LINK is bound to release all the code to make it workable. It don't have the EEPROM programmer, in case there is a bad flash, so I would ask someone, if he can try to customize the u-boot sources to make it listen to incoming TFTP image. This would also reduce the number of "bricked" cases, where only serial or JTAG help. The u-boot sources are also present for in the source code TL-WR941ND V4 and TL-WR741ND V1, and the code structure is similar for them. Maybe people would be more inclined to make their own customized images and change sources, if it were easier to recover from a bad flash.
Another option is that, if we look at listing from original firmware (page 1 of this topic):
Creating 5 MTD partitions on "ar7100-nor0":
0x00000000-0x00020000 : "boot"
0x00020000-0x00120000 : "kernel"
0x00120000-0x007e0000 : "rootfs"
0x007e0000-0x007f0000 : "config"
0x007f0000-0x00800000 : "art"
mtd0 is boot, mtd1 is kernel, mtd2 is rootfs. They don't contain a valid "saveenv", do they? But it shouldn't be too hard to create a mtd1 0x4000 big partition (squeezed between u-boot and kernel), containing a valid saveenv environment
Edit: Or rather mtd2 partition between kernel and rootfs as 0x00020000 is hard coded as kernel's start address. But that I think, this can be changed in saveenv to eg. 0x00024000, so that mtd2 kernel could start from there. Anyhow, it would be better to modify u-boot code, as 0x4000 bytes would be saved.
Evaldas, I also tried to find, whether there is something in the TP-LINK sources (whole package, not only u-boot) containing either "art" or 'art' (with either single or double quotes) - I couldn't find any references to it. Without qoutes, there are just too many words like STart&PartITION to go through the search results manually (I used the built-in search, otherwise someone should search with something more powerful for single word of "art"). But it is probably referenced by its address (either flash chip size minus 0x1000 or absolute 0x007f0000). I think the partition is useless for OpenWRT as it is used only for saving the original firmware's settings to its "NVRAM". The MAC and PIN number are written in mtd0 at its end - 1fc000 and 1fe000 respectively. If overwriting the u-boot code, make sure that 1f0000-1fffff erase block is not overwritten, as it contains MAC and PIN numbers.
Nough said...
(Last edited by 0x00 on 19 Jun 2010, 19:43)