[s]Warning using recovery image!

Don't use the recovery image builds from standard makefile
or stored at openwrt.org servers when using the upgrade tool for Windows XP.

They all miss the u-boot.bin partition and will make the wrt350nv2 unbootable.
relghuar has build a full-image.bin only use this file in conjunction with this download-mode software.

Upslug2 from OpenWrt is safe with standard openwrt-wrt350nv2-recovery images.[/s]

Update:
21.11.2010 - Updated wiki accordingly.
22.11.2010 - Updated the warning only for Windows XP tool

Analysing the recovery image on sunday, I found out, that U-Boot is missing in the provided openwrt-recovery-image.
Today I found out, that upslug2 with param "--image" only flashes up to the eRcOmM signature an ends at 0x75ffff,
so U-Boot at 0x7c0000 is safe!

24.11.2010 - No warning at all upslug2 and upgrade tool for WinXP is save

see Post +2

(Last edited by mrk on 24 Nov 2010, 22:53)

Thanks mrk for the hint.
Did you run into this problem?
If so, how to fix this?

I only used download mode once on my testing device. Unfortunately I can not remember what image I used (normal or recovery).

By the way the wrt350nv2-builder from OpenWrt can also add a U-Boot binary to the recovery image.
Extract the U-Boot image with this script and put it in tools/wrt350nv2-builder/files/

Makefile of wrt350nv2-builder
Makefile of Orion generic images

(Last edited by maddes.b on 21 Nov 2010, 15:51)

Well, my work concerning the download mode is finished by now.

As result, I can say, that the download mode is the safest way to reanimate the wrt350nv2 or get back to stock image.

I tried to add some features to the tool upslug2, among others I wanted to add some safety checks.
Therefor I analyzed the file structure of some image files. I found out, that the openwrt-*-recovery-images don't have a u-boot bin section in there.
That was the first time, I got shocked.

Upslug2 always erases the holy eRcOmM signature, even when I tried with the smaller squash images and reduced flashsize-variable in upslug2 source.
Really bad!

Upslug2 writes the data in two stages
1. erase flash and write new data
2. verify data and commit flash (make it readable)
This is done for all flash sections, which will be updated.

At that point, I thought that the complete recovery image would "update" the u-boot section at 0x7c0000,
and the empty openwrt-recovery images would kill u-boot.
First warning on 21.11.10. in post before.

Then I started to try out the latest stock image V2.0.20 (thank You maddes for the scripts).
In V2.0.20 is a newer U-Boot (Driver V1.07) than mine. I flashed the whole 8 MB stock and restarted.
stock Image; came up and worked.

But there was no new U-Boot Version on my router. (????)
Second reduced warning on 22.11.10.

At least I flashed the stock image with the upgrade tool under WinXP and there was no new u-boot, either.
Third cleared warning today.

Sercomm uses different packed-ids for communication in download mode for
1. HardwareInfo
2. UpgradeStart
3. UpgradeData
4. UpgradeVerify
5. Reboot
and
6. ReprogramStart

I sniffed the network traffic with wireshark on linux and windows, and both tools uses only the Upgrade mode and let u-boot alive.
Also the mac-address an machine-id (found in last 60 bytes in recovery image) leaved untouched.
Only the info about firmware version, also found there is cleared. Curious, but true.

At my point of view only the "reprogram mode" will reflash all areas incl. u-boot.
This mode is disabled in upslug2 and I think You should only use this with JTAG on Your desk.
I really will not try even not with the original firmware with newer u-boot.

Sorry for the warnings, but I was really in panic about that.

In the last days, I extended the upslug2 sources.

The new features are:
* network identity of wrt350nv2
* only "--image" option is allowed with wrt350nv2 (this prevents You of my first mistake at #951)
* security check of recovery image (linux hardware id, squashfs id and the holy eRcOmM)

If You want to try, use this patchfile 120-wrt350nv2-netid.patch.
Maybe we can give it into trunk.

@maddes
thank you for the scripts, helped a lot.
I think, You used the recovery image, because the normal is not accepted by the tools.

Btw, UpgradeTool is working in virtual WinXP, isn't there one in Win7
Perhaps, compiling with minigw is possible...

more question? just ask!
mrk

(Last edited by mrk on 25 Nov 2010, 00:37)

Hello all!
I have loaded new u-boot from V2.0.20 by means of JTAG and Openocd as have broken chip NOR Flash Memory K8D6316UT. Unfortunately I could not find anywhere in retail K8D6316UT and have replaced with its other chip S29GL064N90TFI03, it was necessary to correct a little a code in u-boot as did not coincide ID. After loading JTAG new u-boot 0x7c0000-0x7fffff, I have highlighted other part by means of Upgrage_207_XP, the truth was necessary to load 0 block JTAG. Regular WebUpgrade b SysUpgrade work normally. u-boot I have not found visible distinctions in work of the new version.
Oh, as though I wished to have u-boot which would allow to use resources USBFlash, who can already ?????? tried to make such?

Success to you!
Excuse for bad English.

(Last edited by ValCher on 25 Nov 2010, 20:05)

Did you use machine translation to translate from Russian to English?

Yes - ??

Hello,

Today I decided to resurrect my long lost wnr854t, but it won't cooperate. Searching the internet, there are some other people with this problem (in this very thread even), but no working solutions.

### JFFS2 loading 'uImage' to 0x400000
Scanning JFFS2 FS:   Unknown node type: e001 len 46 offset 0xc
[...]
..... done.
find_inode failed for name=uImage
load: Failed to find inode
### JFFS2 LOAD ERROR<0> for uImage!
## Booting image at 00400000 ...
Bad Magic Number...do_bootm

It does this on all images I've tried. Any ideas?

@nt

have you seen this thread?
https://forum.openwrt.org/viewtopic.php?pid=94355

@nt
Are you sure that the correct machine-id (8 bytes) is before the zImage inside the uImage?
Just a possible pitfall.

Excerpt from Makefile of Orion generic images:

# WNR854T: mach id 1801 (0x709)
echo -en "\x07\x1c\xa0\xe3\x09\x10\x81\xe3" > $(KDIR)/wnr854t-zImage
cat $(LINUX_DIR)/arch/arm/boot/zImage >> $(KDIR)/wnr854t-zImage
$(STAGING_DIR_HOST)/bin/mkimage -A arm -O linux -T kernel \
   -C none -a 0x00008000 -e 0x00008000 -n 'Linux-$(LINUX_VERSION)' \
   -d $(KDIR)/wnr854t-zImage $(KDIR)/wnr854t-uImage
cp $(KDIR)/wnr854t-uImage $(BIN_DIR)/openwrt-wnr854t-uImage

(Last edited by maddes.b on 26 Nov 2010, 00:06)

@mrk:
Thanks for all your effort.
I think the best way to get this patch into trunk is to create a new enhancement ticket for it (don't forget to enter your nick name in the ticket).
Then I would ask nbd if he will take care of it, as he was the one who added WRT350Nv2 support to upslug2 when I donated a WRT350Nv2.

Also glad to hear that U-Boot is safe even in download mode.

By the way there are even more scripts for OpenWrt handling in another folder (especially find_files.sh, search_makefiles.sh, what_linux_version.sh).

(Last edited by maddes.b on 26 Nov 2010, 00:07)

@ValCher:
It is possible to compile your own U-Boot and flash it.
You will get rid of the eCrOmM check, but also loose download mode.
I think relghuar mentioned this here in this thread (he was very active on the first 13 pages).
Do at your own risk. Be very careful. You have been warned.

(Last edited by maddes.b on 26 Nov 2010, 00:03)

Would be nice, if someone could also check if my upslug2-patch is working on his/her machine before committing.
Just copy the patch into trunk/tools/upslug2/patches an make.

@maddes
Good idea, to inform a developer about our patches.
My ticket #8271 is untouched, too.
Maybe You could acknowledge.

(Last edited by mrk on 26 Nov 2010, 07:39)

@ValCher
I think, it is possible to build a u-boot with sercomm addons, search in gpl-source from original linksys V2.0.20.
There are the binaries for that.
Link is in wiki at the very bottom.

Otherwise, I would follow maddes. Don't do anything with u-boot without JTAG.

@mrk,ValCher:
Yes, but maybe you have to adopt the Linksys changes to the current U-Boot. Could be a very annoying task.
If you do please let us know.

(Last edited by maddes.b on 26 Nov 2010, 19:36)

Is 40MHz HT mode supposed to work on WRT350Nv2? If I set my router to this mode, I can not connect to it wirelessly.
System log is full of the following messages:

Nov 27 00:10:39 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response
Nov 27 00:10:45 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 1)
Nov 27 00:10:50 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df WPA: pairwise key handshake completed (RSN)
Nov 27 00:10:53 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response
Nov 27 00:11:06 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response
Nov 27 00:11:11 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response
Nov 27 00:11:20 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response
Nov 27 00:11:20 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response
Nov 27 00:11:56 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: authenticated
Nov 27 00:11:57 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 1)
Nov 27 00:11:57 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 1)
Nov 27 00:11:59 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df WPA: received EAPOL-Key 2/4 Pairwise with unexpected replay counter
Nov 27 00:11:59 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df WPA: received EAPOL-Key 2/4 Pairwise with unexpected replay counter
Nov 27 00:11:59 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: deauthenticated due to local deauth request
Nov 27 00:12:01 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: authenticated
Nov 27 00:12:02 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 1)
Nov 27 00:12:04 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df WPA: pairwise key handshake completed (RSN)
Nov 27 00:12:30 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response
Nov 27 00:12:35 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response
Nov 27 00:12:35 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response
Nov 27 00:12:40 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: associated (aid 1)
Nov 27 00:12:41 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df WPA: received EAPOL-Key 2/4 Pairwise with unexpected replay counter
Nov 27 00:12:42 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df WPA: pairwise key handshake completed (RSN)
Nov 27 00:12:54 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response
Nov 27 00:12:54 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response
Nov 27 00:13:07 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response
Nov 27 00:13:24 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response
Nov 27 00:13:34 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response
Nov 27 00:13:48 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response
Nov 27 00:13:53 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response
Nov 27 00:14:04 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response
Nov 27 00:14:14 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response
Nov 27 00:14:20 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response
Nov 27 00:14:45 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response
Nov 27 00:14:50 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response
Nov 27 00:15:01 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response
Nov 27 00:15:01 OpenWrt daemon.info hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: deauthenticated due to local deauth request
Nov 27 00:15:10 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response
Nov 27 00:15:19 OpenWrt daemon.notice hostapd: wlan0: STA 00:0e:2e:af:6f:df IEEE 802.11: did not acknowledge authentication response

As soon as I switch to 20MHz HT mode, I get a connection and everything seems to be working. I will see if this mode is stable now in 10.03.1-rc4.

I have realized another nifty feature for the wrt350nv2.
It's called securityled and triggers the security led from the wrt350nv2.

In stock firmware, the outermost right side led shows, if You have wifi encryption enabled.
Such the same is done with this script.

It contains of two parts.
1. the configuration file in "/etc/config/securityled"
2. the hotplug script in "/etc/hotplug.d/net/50-securityled"

Securityled reads out the uci wireless config and differs in three states
1. disabled - no encrytion at all
2. mixed - at least one iface encrypted, one iface open
3. enabled - all ifaces are encrypted

The led handling for these states can be established in config-file "/etc/config/securityled".
I have chosen as default:
disabled - led off
mixed - led toggles
enabled - led on

[s]Here is the patch -p0 for trunk, maybe backfire, too:[/s]
Update: see link in next post.

Greetz
mrk

@maddes, thank You for the support with the ticket.

(Last edited by mrk on 29 Nov 2010, 23:14)

@mrk:
Just some short notes as I'm not at home.

* Can you provide a download link? As I don't know if the forum messes up tabs.
Did you use tabs this time?
Update:
Re-worked the patch to use tabs to save space on the embedded device, patch available for download here.
(You still have FTP access to my machine, don't you?)

* Is "50-securityled" used by other targets? Do other targets have Hotplug-Scripts for security led? Just to make it consistent within OpenWrt.
Update:
Didn't find any target with a similar hotplug script.

* Last but not least, you have to get the current state from the wireless settings, not the current commited ones.
Use uci_get_state() to do this (included via config.sh, should be automatic).

Update:
* The config and script need to be more generic. Currently it's no good for WNR854T, which shares the same files.
Find out what is device specific, mostly sysfs and led names, then create a function that handles these by device (see the uci-defaults for an example).

Maddes

P.S.:
Do not thank me until the ticket changes are committed to trunk. I can only help to reduce problems.

(Last edited by maddes.b on 29 Nov 2010, 18:33)

I found a mistake in my upslug2 patch.
For security reason, I added some checks for the image file.

As I tried to flash stock V2.0.20, the check for the "mach id" fails,
because V2.0.20 has none ... as there is one in openwrt-image.
Update: ...and this is needed for booting kernel in backfire and trunk

Here is the new patch with corrected check: 120-wrt350nv2-netid.patch.

(Last edited by mrk on 30 Nov 2010, 11:40)

@maddes

#1 - Well, didn't care about tabs by now. Will do this in future.
(Unfortunately, I lost my old mails :-( )

#2 - Could not find anything, too.

#3 - Have correct the uci - function and something more. Update will come soon.

#4 - Yes, You are right, the wnr854t has a silly way let led blink.
I will think about this.

MRK

hi all

since almost 3 month, to root on my external disk, i am having problem while trying to build image for my linksys WRT350N V2  ARH=orion
I have tried every tutorial but i am still getting error...
When i tried a " Make V=99 " to see what was wrong, below is the result i got.... (the text in red at the end of the code color is the beginning of the error)

sergy@Sergy:~/wrt350N$ make V=99 ARCH="orion"
make[1]: Entering directory `/home/sergy/wrt350N'
make[2]: Entering directory `/home/sergy/wrt350N'
++ mkdir -p /home/sergy/wrt350N/staging_dir/target-orion_v5t_uClibc-0.9.30.1_eabi
++ cd /home/sergy/wrt350N/staging_dir/target-orion_v5t_uClibc-0.9.30.1_eabi
++ mkdir -p bin lib include stamp
mkdir -p /home/sergy/wrt350N/build_dir/target-orion_v5t_uClibc-0.9.30.1_eabi/stamp
touch /home/sergy/wrt350N/staging_dir/target-orion_v5t_uClibc-0.9.30.1_eabi/.prepared
make[3]: Entering directory `/home/sergy/wrt350N/toolchain/binutils'
make[3]: Nothing to be done for `prepare'.
make[3]: Leaving directory `/home/sergy/wrt350N/toolchain/binutils'
make[3]: Entering directory `/home/sergy/wrt350N/toolchain/binutils'
make -C /home/sergy/wrt350N/build_dir/toolchain-orion_v5t_gcc-4.3.3+cs_uClibc-0.9.30.1_eabi/binutils-2.19.1 all
make[4]: Entering directory `/home/sergy/wrt350N/build_dir/toolchain-orion_v5t_gcc-4.3.3+cs_uClibc-0.9.30.1_eabi/binutils-2.19.1'
make[5]: Entering directory `/home/sergy/wrt350N/build_dir/toolchain-orion_v5t_gcc-4.3.3+cs_uClibc-0.9.30.1_eabi/binutils-2.19.1'
Configuring in ./bfd
configure: loading cache ./config.cache
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... orion-openwrt-linux-uclibcgnueabi
checking for x86_64-linux-gnu-gcc... x86_64-linux-gnu-gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether x86_64-linux-gnu-gcc accepts -g... yes
checking for x86_64-linux-gnu-gcc option to accept ANSI C... none needed
checking for library containing strerror... none required
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking dependency style of x86_64-linux-gnu-gcc... gcc3
checking for x86_64-linux-gnu-ar... ar
checking for x86_64-linux-gnu-ranlib... ranlib
checking for x86_64-linux-gnu-gcc... (cached) x86_64-linux-gnu-gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether x86_64-linux-gnu-gcc accepts -g... (cached) yes
checking for x86_64-linux-gnu-gcc option to accept ANSI C... (cached) none needed
checking how to run the C preprocessor... x86_64-linux-gnu-gcc -E
checking for egrep... grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for a sed that does not truncate output... /home/sergy/wrt350N/staging_dir/host/bin/sed
checking for fgrep... grep -F
checking for ld used by x86_64-linux-gnu-gcc... ld
checking if the linker (ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... nm
checking the name lister (nm) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 3458764513820540925
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for ld option to reload object files... -r
checking how to recognize dependent libraries... pass_all
checking for x86_64-linux-gnu-ar... (cached) ar
checking for x86_64-linux-gnu-strip... no
checking for strip... strip
checking for x86_64-linux-gnu-ranlib... (cached) ranlib
checking command to parse nm output from x86_64-linux-gnu-gcc object... ok
checking for dlfcn.h... yes
checking for objdir... .libs
checking if x86_64-linux-gnu-gcc supports -fno-rtti -fno-exceptions... no
checking for x86_64-linux-gnu-gcc option to produce PIC... -fPIC -DPIC
checking if x86_64-linux-gnu-gcc PIC flag -fPIC -DPIC works... yes
checking if x86_64-linux-gnu-gcc static flag -static works... yes
checking if x86_64-linux-gnu-gcc supports -c -o file.o... yes
checking if x86_64-linux-gnu-gcc supports -c -o file.o... (cached) yes
checking whether the x86_64-linux-gnu-gcc linker (ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... no
checking whether to build static libraries... yes
Setting warning flags = -W -Wall -Wstrict-prototypes -Wmissing-prototypes
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether to install libbfd... no
checking whether NLS is requested... no
checking whether NLS is requested... no
checking for msgfmt... /usr/bin/msgfmt
checking for gmsgfmt... /usr/bin/msgfmt
checking for xgettext... /usr/bin/xgettext
checking for msgmerge... /usr/bin/msgmerge
checking for a BSD-compatible install... /usr/bin/install -c
checking for long long... yes
checking size of long long... 8
checking for void *... yes
checking size of void *... 8
checking for long... yes
checking size of long... 8
checking alloca.h usability... yes
checking alloca.h presence... yes
checking for alloca.h... yes
checking stddef.h usability... yes
checking stddef.h presence... yes
checking for stddef.h... yes
checking for string.h... (cached) yes
checking for strings.h... (cached) yes
checking for stdlib.h... (cached) yes
checking time.h usability... yes
checking time.h presence... yes
checking for time.h... yes
checking for unistd.h... (cached) yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking sys/file.h usability... yes
checking sys/file.h presence... yes
checking for sys/file.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
looking for a compliant stdint.h in stdint.h, checking for uintmax_t... yes
checking for uintptr_t... yes
checking for int_least32_t... yes
checking for int_fast32_t... yes
checking for uint64_t... yes
checking what to include in bfd_stdint.h... stdint.h (already complete)
checking whether time.h and sys/time.h may both be included... yes
checking for dirent.h that defines DIR... yes
checking for library containing opendir... none required
checking whether string.h and strings.h may both be included... yes
checking for fcntl... yes
checking for getpagesize... yes
checking for setitimer... yes
checking for sysconf... yes
checking for fdopen... yes
checking for getuid... yes
checking for getgid... yes
checking for strtoull... yes
checking whether basename is declared... yes
checking whether ftello is declared... yes
checking whether ftello64 is declared... yes
checking whether fseeko is declared... yes
checking whether fseeko64 is declared... yes
checking whether ffs is declared... yes
checking whether free is declared... yes
checking whether getenv is declared... yes
checking whether malloc is declared... yes
checking whether realloc is declared... yes
checking whether stpcpy is declared... yes
checking whether strstr is declared... yes
checking whether snprintf is declared... yes
checking whether vsnprintf is declared... yes
checking for library containing zlibVersion... -lz
checking zlib.h usability... yes
checking zlib.h presence... yes
checking for zlib.h... yes
*** BFD does not support target orion-openwrt-linux-uclibcgnueabi.
*** Look in bfd/config.bfd for supported targets.
make[5]: *** [configure-bfd] Error 1
make[5]: Leaving directory `/home/sergy/wrt350N/build_dir/toolchain-orion_v5t_gcc-4.3.3+cs_uClibc-0.9.30.1_eabi/binutils-2.19.1'
make[4]: *** [all] Error 2
make[4]: Leaving directory `/home/sergy/wrt350N/build_dir/toolchain-orion_v5t_gcc-4.3.3+cs_uClibc-0.9.30.1_eabi/binutils-2.19.1'
make[3]: *** [/home/sergy/wrt350N/build_dir/toolchain-orion_v5t_gcc-4.3.3+cs_uClibc-0.9.30.1_eabi/binutils-2.19.1/.built] Error 2
make[3]: Leaving directory `/home/sergy/wrt350N/toolchain/binutils'
make[2]: *** [toolchain/binutils/compile] Error 2
make[2]: Leaving directory `/home/sergy/wrt350N'
make[1]: *** [/home/sergy/wrt350N/staging_dir/toolchain-orion_v5t_gcc-4.3.3+cs_uClibc-0.9.30.1_eabi/stamp/.toolchain_install] Error 2
make[1]: Leaving directory `/home/sergy/wrt350N'
make: *** [world] Erreur 2

Well, my vacation are ending now, and here is my implementation for failsafe mode of orion/wrt350nv2.
As prerequisite, You need to activate the button-keys from post #939.

The following svn diff for trunk contains all files (hope, I forgot no file): orion_failsafe.patch

New features are:
* diag.sh - led signaling while booting
* reset button-hotplug - entering failsafe
* preinit network - preinit network message
* failsafe network configuration
* reset-button for normal operating mode

Booting wrt350nv2 will now be:
1. power led green on - you are in u-boot boot wait
2. led off - starting kernel
3. power led orange on - preinit wait for key mode
4a. power led green/orange - init mode, kernel boots normal
4b. power led orange flashing - failsafe mode
5. power led green on - done mode

When You push and hold the reset button in mode 3. (power led orange on), You will get in failsafe mode.
Watch for power led flashing orange, then You are in failsafe mode.

Some parameters can be set in make menuconfig -> Image configuration -> Preinit configuration option.
Preinit network interface should be "br-lan".
Show all preinit network message will open a preinit network and broadcast status messages via udp. You can whatch them with recvudp.
When You don't have any preinit config options, a bridge named "br-lan-fs" with ip 192.168.1.1 will be created.

It's not perfect, but another step!

greets
mrk

PS:
I have lost the wps-plastic-button for the wrt350nv2. It fell on the floor as I had my wrt open for this work here and probably it is eaten by my hoover!
I also called linksys support and asked for a spare part. The man there was astonished and told me something about lost of guaranty.
Well, and I even didn't told him about the hole in the case for serial cable In result, he could not help me.

So, if someone knows someone, who can tell me how to get a wps-button for wrt350nv2 as spare part, I would be very thankful.

I searched around and tried to find some information concerning RTC for the our Marvel SoC.
Well, I didn't found anything helpfull.
There is no internal rtc, like in kirkwood and the driver in stock firmware belongs to a DS1339, which I can not find on the wrt350nv2-board and even cannot be announced in kernel.

I used:

+static struct i2c_board_info __initdata wrt350n_v2_i2c_rtc = {
+    I2C_BOARD_INFO("ds1339", 0x68),
+};

in wrt350nv2-setup.c. Maybe, the wrong dev-addr 0x68?

From my point of view, we can disable the config for rtc in make kernel_menuconfig.
Then the quoted error message will disappear.

This is for ID: 'nt',

I had the same problem. I uploaded openwrt-wnr854t-jffs2-64k-webupgrade.img and then did original netgear firmware.

Hope it works for you, too. Good luck.

@mrk

Just wanted to let you know, great effort! Nice to see these nifty features

@dirkNL

Thank You, would be nice, if You can review the scripts and support to bring them in trunk!

mrk