"Investigation - can we use the existing u-boot to load and test openwrt without serial access, and with the option of going back to stock firmware easily?"
Just noting some results of some investigation of u-boot in my type B.
As/If I find more details, I'll try to update this post.
In 'perm_storage' in the flash, there are 2 u-boots.
somewhere else I have read that the first runs the second (after aggressively checking a signature), and the second runs linux; but no confirmation here.
The u-boots are at:
0x0-0x3FFFF (0-0x2CC1F is the actual code, the rest is zeros).
0x100000-0x13FFFF (0x100000-0x12CC1F is the actual code, the rest is zeros).
The u-boots are IDENTICAL, marked (around 0x24120) as V1.3.1a Apr 2009.
The u-boot does not appear to be compressed?
The cramfs contains a u-boot.bin marked (around 0x24120) as V1.3.1a Feb 2009.
This is a different size slightly larger(0-0x2CD33), and the differences start pretty close to the beginning (at 0x047E), although the differences seem to be in offsets until 0x2DB33. at this point a string seems to have been inserted refering to /mnt/jffs2/openrg.console.log
Strange; I've not seen reference to jffs2 before? (it does seem to be in the jungo opensrc config).
To me, it looks like the actual code is pretty similar - the size increase is not enough to account for extra network code, for example.
Config:
The default config is at 0x2B2E0
The stored config is at 0x40000 in perm_storage
u-boot's config starts with a 4 bytes CRC, then is null-terminated lines, ending with a double null.
The default config in u-boot.bin from cramfs is identical to that in the rom u-boots, but the running config contains in addition 'stdin=serial' 'stdout=serial' and 'silent=1'.
the silent flag can be set from the OpenRG CLI, as stated in another thread.
Both the default and running config refer to TFTP from 192.168.1.10, file u-boot.bin, which would be flashed to 0xb0000000 if the script was actioned. hub IP would be 192.168.1.1
on another site referring to Siemens routers, someone was told to 'hold reset for 10 seconds, continue to hold reset whilst power off for 10 seconds, continue to hold for 10 seconds from boot' which seemed to run some form of network update.
Latest u-boots do have a facility to run a webserver for firmware update, but can't find this in the openrg version..
Next task is to find if pressing a button during boot will restore u-boot config defaults. if it does, then we can easily change the u-boot config to load a kernel from tftp and start it.
note: it seems it may be 'difficult' to load an alternative u-boot into RAM and execute it: http://stackoverflow.com/questions/5218449/loading-u-boot-in-memory-instead-of-flashing-it explains why this is not an easy task... basically related to the fact that if you load it into DRAM, one of the first things it will do is configure DRAM, and so distupt itself . ... except in u-boot/board/danube/README, it refers to building for RAM boot, so maybe it is easily possible?
in terms of buiulding u-boot, we are definately missing flash_layout.c, which is included from cmd_openrg.c
We may be able to re-create this.
The attached file is my attempt at reproducing the missing flash_layout.c
With this file placed here:
~/rg-4.7.5.1/rg/build.SHC PORTA2/vendor/shc/porta2
u-boot then builds successfully.
The u-boot does not end up identical to either of the u-boots identified in the previous post; the difference appears to start in danube/flash.c, and the supplied source is newer than either of the compiled u-boots, so I think we can assume it's correct.
The parts supplied by flash_layout ARE identical - this file basically defines the flash layout; what is plain is that there are parts in the NAND, and parts not.
My next step will be to try to understand how to:
change build to be ram loadable.
add netconsole to the u-boot.
make the new u-boot temporarily ignore the u-boot config.
design a u-boot config which will attempt to tftp the new u-boot to ram and run it, but falling back to running OpenRG.
Or better, which tftps a script and runs that...
ok, more findings:
in the native u-boot, we do not have 'hush' (a kind of shell), so no conditional commands
I can't find any reference within u-boot to the script 'update-uboot', which operates the tftp. so i'm guessing this is there only as a manual (serial) command, just so engineering can't get it wrong. I don't think we can cause TFTP of u-boot from a button push...
The multiple copies we find are probably the flash addresses wrapping.
further investigation:
The HH V2B has 2 types of flash.
The first is NOR (?) and is used for u-boot and RGconfig
The second is NAND, and hold two OpenRG images at 0x4000 and 0xE04000, size 0xE00000
The OpenRG images are checksummed at the end of each section.
Successfully flashed a new u-boot!
used a tftp server (tftpd32.exe - from the v1reflashredboot package available somewhere here).
Laptop is set to static IP 192.168.1.10 (actually is wireless to my main router HH V2.0a, with the V2B set with static address of 192.168.1.1 wired to the V2A).
Accessed the CLI, and used
"flash load -u tftp://192.168.1.10/u-boot.bin -s 0"
rebooted, and the hub came back.
used
"flash dump -r 0x023e00 -l 100" (location of compile date in my u-boot)
to confirm it was my u-boot in place
u-boot was unmodified as built with below flash_layout.c from V2B open source.
next; to modify u-boot to enable netcat & hush shell, and flash....
ok, not perfect, but probably good enough for use.
On my network, the hub reports the occasional 'bad checksum' (assume it's looking at UDP checksums), and output is sometimes (often) corrupted, but my lan is quite busy....
However, you get the boot output, and can break in with any key.
This WILL allow us to tftp a OpenWRT image into RAM and run it, without disturbing the existing BT software. To restore the BT software, you would just allow the boot to complete without interruption. We should also be able to store away the BT image, and then restore it later as required.
I'll prepare a zip of all the required bits and pieces, and post here next.
ok, attached file contains all you need to:
Update u-boot on BT HH V2.0B to support netconsole.
Operate netconsole on Windows.
break into the HH boot process without a serial port fitted... .
Build this version based on the Jungo OpenRG opensource.
Please use this to play with OpenWRT. Be aware that if OpenWRT understands the flash, it will/may write jffs2 over it!
I'm sure if you are going to play, you will backup your complete flash first so you can restore it using u-boot - I've not investigated this yet, so don't blame me if this can't be done.
Be aware that I'm seeing some network errors with this version (but most likely in the netconsole code), but don't be surprised if there are tftp errors; please check before you rely on it.
. ... except in u-boot/board/danube/README, it refers to building for RAM boot, so maybe it is easily possible?
Reply With Quote
