OpenWrt Forum Archive

Topic: Modifying the uboot environemt from OpenWrt

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

I think this could be due to the OLD version of U-Boot TP-Link is using.

Orca wrote:

http://wiki.openwrt.org/doc/techref/boo … om.openwrt

Can somebody help to finish this?

I don't know how to configure  uboot-envtools.
/etc/fw_env.config

I think you need to read the wiki ... sorry, I couldn't resist smile  This fine page from Wolfgang http://www.denx.de/wiki/view/DULG/HowCa … lesInLinux

You only need to mess with fw_env.config if you are trying to mess with u-boot environment variables from Linux.

Do you have a need to do this vs using the serial console?

Regards,

Brian

I don't have a serial console. If only.

Also, I do not require this. It's simply something I wanted to have.

I always wanted to open my Router, and solder a serial header to the PCB and do stuff, but I never had to, because OpenWrt simply fucking works for me.
I am so bored. I envy the people who have trouble and have to solder stuff and so on.

The same happend to me with Windows XP. I installed it once "myway" and since then it simply works. Boring. The people with the Virus-Scanners and the Flashplugin have all the fun, install their stuff every three month and me? So unfair.

If you don't have a serial console then I would advise that you don't mess with trying to change u-boot env. vars from Linux or you will step on yourself.

Besides, to set the fw_env up you need to know how big and where the u-boot env. section is.  If you have the u-boot source it is easy to determine and you simply fill out fw_env with the offsets required to mimic what u-boot is doing.  All this is doing is creating an overlay of the MTD env partition. 

The difference between changing env. in u-boot vs linux (unless something has changed recently) is with u-boot you can change a bunch of variables at a time and then do saveenv and only one write to flash happens.  When you do it from Linux, if you change one thing, the entire environment variable section is re-written to flash.

Regards,

Brian

Orca wrote:

...

Also, I do not require this. It's simply something I wanted to have.

If you want to learn u-boot, I suggest you get something more friendly like a BeagleBoard.  Set it up to boot from SDCard and when you hose it up you just put it in your PC and fix it.

Regards,

Brian

Did you find out where U-Boot stores the environment variables?

No, I checked the sources from TP-link but found nothing. Then I stumbled upon something, and it occured to me, the tp-link uboot fork is very old. And back then, they did this different then described in the article, because I based my description on current code. And then I tried different values and it didn't help.

http://wiki.openwrt.org/doc/techref/boo … g_env_size

I've used the fw_printenv method since back in 1.1.6 (2005 or 2006 vintage if I can remember right) with a 2.6.18 kernel.  I haven't tried it with any of my new board that are running U-Boot 2010.06 but I probably will in the next few weeks when I get the "boot count" feature going on our board.

Regards,

Brian

Orca wrote:

No, I checked the sources from TP-link but found nothing. Then I stumbled upon something, and it occured to me, the tp-link uboot fork is very old. And back then, they did this different then described in the article, because I based my description on current code. And then I tried different values and it didn't help.

http://wiki.openwrt.org/doc/techref/boo … g_env_size

Can you not reverse engineer it?  U-boot typically has been around 160-170KB so it is usually in the first one or two flash sectors and the env. is usually the very next sector after u-boot.

Can you open up the unit and find the flash and get the part number off of it.  Then look up the datasheet to see how big a flash it is and what the sector sizes are.  You could probably figure it out that way unless they are trying to do security through obscurity.

Can you do cat /proc/mtd?

Can you do a dmesg and see any bootargs?  Knowing the MTD of the rootfs could be a clue.  The kernel usually has a MTD map that also knows where u-boot and the u-boot env is.  In new kernels this map is in the "board" file but in older versions it was hard coded somewhere under drivers/mtd.

Regards,

Brian

Orca wrote:

No, I checked the sources from TP-link but found nothing.

Can you copy and compare /dev/mtd0 before and after modifying any environment variable from serial console?

This is my device: http://wiki.openwrt.org/toh/tp-link/tl-wr1043nd  I could do a http://wiki.openwrt.org/doc/howto/generic.backup and look with a hex-editor in the dump.

But this is not very elegant, is it?

I encountered bootloaders you can connect to via telnet or ftp and do pretty much everything without the need of a serial cable! Then there is the uboot of the dockstar, which's ENV could easily be changed from Linux (I use Debian on it). Maybe I should just accept, that this is not possible with the uboot implementation of the WR1043ND.

I got everything running, I really do not require this, I was just curious.

You can do u-boot console over network too.  Support for it has to be turned on and the PC has some setup but it is possible to do it although you don't see it very often.

Comes in handy when you have a unit in a place that isn't exactly easy to get to (on a tower).

hutchman wrote:

You can do u-boot console over network too.  Support for it has to be turned on and the PC has some setup but it is possible to do it although you don't see it very often.

Comes in handy when you have a unit in a place that isn't exactly easy to get to (on a tower).

Exactly, and thus I would have expected that! But found only descriptions for procedures over UART :-(

"Wouldn't it be nice to have this information in the wiki?"


http://docs.blackfin.uclinux.org/doku.p … netconsole
http://forum.doozan.com/read.php?3,14,14
http://buffalo.nas-central.org/index.ph … Install_nc

(Last edited by Orca on 1 Sep 2011, 13:58)

The discussion might have continued from here.