Debian on Zyxel NAS326

I'm realizing the same with an udev rule:

SUBSYSTEM=="block", KERNEL=="sdb", RUN+="/sbin/hdparm -S 241 /dev/sdb"

Drive sda is a ssd with the system. I think, there's no need to put that drive into the sleep state.

Hi guys,

If any of you have the NAS326 GPL please PM me. I've tried this but could not get to the request page:
http://www.zyxel.com/us/en/form/gpl_oss_form.shtml

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Still no sources, see here:

http://www.zyxelforum.de/viewtopic.php?f=306&t=9904

pengu,

> http://www.zyxelforum.de/viewtopic.php?f=306&t=990

I've checked that site from time to time, too.

You need to request GPL from Zyxel and give them your box information (serial number, MAC address). I think they want to do just enough to satisfy the GPL license for the new boxes. For older boxes such as NSA325 or 310s/320s they are distributing widely. I can't understand the logic behind it, but that's how Zyxel has been.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi Wrote:
-------------------------------------------------------
> pengu,
>
> >
> http://www.zyxelforum.de/viewtopic.php?f=306&t=990
>
>
> I've checked that site from time to time, too.
>
> You need to request GPL from Zyxel and give them
> your box information (serial number, MAC address).
> I think they want to do just enough to satisfy the
> GPL license for the new boxes. For older boxes
> such as NSA325 or 310s/320s they are distributing
> widely. I can't understand the logic behind it,
> but that's how Zyxel has been.


You had luck with that? I have had requested NAS326 sources a month ago and never got any reply on that topic.
GPL, security, etc. are not topics that this kind of manufacturer not take serious. And of course it takes time and mancraft to clean up their mess and put together files including documentation. Also it is not a secret that the knowledge and in-house-capabilities of zyxel are very limited. They stick to the board support package and there are some odd things when you look through their firmware sources and quick and dirty fixes, avoiding package updates. You get what you pay for for.

> You had luck with that? I have had requested
> NAS326 sources a month ago and never got any reply
> on that topic.

No luck yet, that's why I asked :) will see in a couple more days. If I don't get any response from them then I'll have a plan B (thanks to a forum member).

> You get what you pay for for.

Compare to other NAS vendors, Zyxel make pretty decent hardware but lousy software for a much lower cost. Therefore we are hacking it to make perform like others. But I can't see the logic in not releasing GPL widely, it'll just turn off more experienced users and they'll gain nothing from being that way (not like there are any trade scerets in the GPL).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

All,

Indeed, according to the GPL source: NAS326 stock u-boot always restores the internal bootcmd at every boot.

I'm opening the box to connect serial console and will see this behavior first hand and see if I can fix this.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi Wrote:
-------------------------------------------------------
> All,
>
> Indeed, according to the GPL source: NAS326 stock
> u-boot always restores the internal bootcmd at
> every boot.
>
> I'm opening the box to connect serial console and
> will see this behavior first hand and see if I can
> fix this.
I have serial console permanently connected to my NAS326 running stock OS. So if you want me to try out something, just let us know. :)

I'm working on kwboot booting, but I'm having trouble building stock u-boot on Mint 17.2 VM, switching to Mint 18.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

sebr,

Thanks sebr! I already thougth of a way I think would work. But it's best to be able to boot with kwboot first so we have a recovery tool.

First thing you should do when you are in stock OS is backing up by dumping NANDs for all partitions 0-6.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Months ago, i buy a NAS326 Box, and now i found time to unboxing this.
I disassemble it direct and connect a Cable for the serial-console.

@hean01 , @musv
I have the same Problem, the Box is not booting if a USB-TTL transmiter is conneced. (I connent only GND and TX).
I solve this issue by adding a diode to TX-Line (Cathode/Ring-Mark to Box, Anode to Transmiter).
After that, Box booted directly (GND, TX and RX is connected).

@bodhi
If you are looking for tester, I am available

Thanks Kirsch,

I've since discovered a way to connect with serial console without having to manually replug the serial module (all sotware). But this is not a permanent solution as your HW mod !

Could you explain the reason why your diode mods work? does it have anything to do with the response timing? I vaguely recalled that somebody at Arch or this forum mentioned this mod. But I did not see explanation why it would work.

I've rebuilt stock u-boot and trying to kwboot the box. If I can get the timing response/delay figured out, I think it will work. Once I can run kwboot, I'll start building a new u-boot for it.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

If you only connect GND and TX, it should have no influence on the box. Because the connection is completely passive.

This is a very unusual behavior. Because the pin input on the TTL converter is highly resistive and therefore no current can flow. Without a circuit diagram, I cannot figure out the exact cause.

My first try was a resistance (100 and 470 ohms), but that did not help.
Then I took a diode of type 1N4148 (a BAT85 must also work).
If this had not worked, I would have had to take an optocoupler, for a compete galvanic separation.

A possible response, when switched on, the TX pin is configured as an input.
As soon as the TTL converter is connected, it is pulled to GND since it is not pulled from any side to a definite potential. And this LOW signal ensures wrong behavior in the Boot-Up-Code.

If so, a pullup with 10KOhm to 3.3V would have helped. Now I have my box reassembled and can not test it.

Kirsch,

Very interesting info for me personally! I am a software guy so your analysis is quite informative.

The interesting behavior with connecting serial console to this box, is that if it only detects the serial connection if you cold start (power on with the button). If you warm start (reboot from stock OS), then it will let serial communication unbroken. But it seems to stuck at boot again waiting. To let it run, I used kwboot in debugging mode as described below.

The trick I've discovered to run serial console without unplugging the USB module is to run kwboot from 2016.05 code in debugging mode (I've just uploaded in the u-boot thread)

Quote

To download ARM kwboot binary for UART booting at Dropbox
kwboot-2016.05.tar

Run kwboot in debugging mode as a normal serial console:

kwboot  -t -B 115200 /dev/ttyUSB0 -d

And then push the power button.

After that, wait and eventually the stock u-boot will start, and serial console will behave normally.

I'm still have not figugred out how to run kwboot successfully, it is a catch-22 I think. It is unlikely but possible that Zyxel has some trick in their board that change the reponse/timeout timing.

Let me post stock u-boot image in the next post and you can try it.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 2 time(s). Last edit at 12/26/2016 04:35AM by bodhi.

All,

Here is something you can try: run kwboot with the attached u-boot binary that I've rebuilt from stock code. See if you got the handshake going:

kwboot  -t -B 115200 /dev/ttyUSB0 -b u-boot-a38x-STG-328_2014_T3p6-nand-uart.bin

I would expect that Kirsch has a better chance to run kwboot this normal way.

There are new options to specify the response and timeout timming in this kwboot version. But the serial console restriction with this Zyxel board which aborts the kwboot process way to early to make this useful. But I would not rule this out, either, since we have not figured out exactly what Zyxel did on this board to enable the restriction.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Ok, I have now read what kwboot is and what it does.
I try that afterwards.

Where is the difference between your kwboot and the from u-boot-tools from Ubuntu 16.04?

Kirsch Wrote:
-------------------------------------------------------
> Ok, I have now read what kwboot is and what it
> does.
> I try that afterwards.
>
> Where is the difference between your kwboot and
> the from u-boot-tools from Ubuntu 16.04?

My kwboot build is for ARM 32, and from the u-boot-2016.05 source tree. Whatever version you found on Ubuntu is most likely x86 and 64-bit, and probably a lot older.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

It did not work.

Does kwboot need to trigger the 1 stage boot loader?
It always goes immediately in U-Boot.

I sniff the TX-Line with a second converter:

BootROM - 1.73
Booting from NAND flash▒

General initialization - Version: 1.0.0
Detected Device ID 6810
High speed PHY - Version: 2.0

Init RD NAS topology board SerDes lanes topology details:
 | Lane #  | Speed |  Type       |
 --------------------------------
 |   0    |  06   |  SATA0      |
 |   1    |  05   |  USB3 HOST0 |
 |   2    |  06   |  SATA1      |
 |   5    |  05   |  USB3 HOST1 |
 --------------------------------
High speed PHY - Ended Successfully
DDR3 Training Sequence - Ver TIP-1.26.0
mvSysEnvGetTopologyUpdateInfo: TWSI Read failed
DDR3 Training Sequence - Switching XBAR Window to FastPath Window
DDR3 Training Sequence - Ended Successfully
Not detected suspend to RAM indication
BootROM: Image checksum verification PASSED
▒
 __   __                      _ _
|  \/  | __ _ _ ____   _____| | |
| |\/| |/ _` | '__\ \ / / _ \ | |
| |  | | (_| | |   \ V /  __/ | |
|_|  |_|\__,_|_|    \_/ \___|_|_|
         _   _     ____              _
        | | | |   | __ )  ___   ___ | |_
        | | | |___|  _ \ / _ \ / _ \| __|
        | |_| |___| |_) | (_) | (_) | |_
         \___/    |____/ \___/ \___/ \__|
 ** LOADER **


U-Boot 2013.01-svn48023 (Oct 13 2015 - 09:25:56) Marvell version: 2014_T3.0p6

Board: RD-NAS-88F6820-DDR3
SoC:   MV88F6810 Rev A0
       running 1 CPUs
CPU:   ARM Cortex A9 MPCore (Rev 1) LE
       CPU 0
       CPU    @ 1332 [MHz]
       L2     @ 666 [MHz]
       TClock @ 250 [MHz]
       DDR    @ 666 [MHz]
       DDR 32 Bit Width, FastPath Memory Access, DLB Enabled, ECC Disabled
DRAM:  512 MiB

Map:   Code:                    0x1fed0000:0x1ff95d60
       BSS:                     0x1ffef2b4
       Stack:                   0x1f9cff20
       Heap:                    0x1f9d0000:0x1fed0000
       U-Boot Environment:      0x00200000:0x00280000 (NAND)

NAND:  256 MiB
MMC:   mv_sdh: 0
*** Booting kernel from kernel 2 @0x08700000 ***
USB2.0 0: Host Mode
USB3.0 0: Host Mode
USB3.0 1: Host Mode
Board configuration detected:
Net:
|  port  | Interface | PHY address  |
|--------|-----------|--------------|
| egiga0 |   RGMII   |     0x01     |
egiga0 [PRIME]
Hit any key to stop autoboot:  0
Marvell>> ▒"3DUfw▒"3DUf""3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUf                                                                                                                     w▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw                                                                                                                     ▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒                                                                                                                     "3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"                                                                                                                     3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3                                                                                                                     DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3D                                                                                                                     Ufw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DU                                                                                                                     fw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒"3DUfw▒

Kirsch,

That's what I've been seeing with my serial console. Stock u-boot does not have SPL stage 1. It would go straight from the bootROM to u-boot in NAND. This is where UART booting would take precedence if it works. Marvell bootROM senses the UART0 port to boot from before it would go to another device (e.g. NAND, USB,...).

So the possibilities:

1. The handshake did not occur because Zyxel did not implemented it correctly in hardware in someway (intentionally or not).
2. Our kwboot did not keep up to a peculiarity of Marvell bootROM 1.73, which I'd doubt the is case. AFAICT, other boards that use Marvell bootROM 1.73 do not seem to have this problem.

So I'm still searching for the right handshake, if it does exist. I've found another potential approach and will try it out.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 12/27/2016 03:33AM by bodhi.

Very mysterious behavior with the TX-Line.

My diode tick does not work with the other converter to 100%.

I tried it now with a 10K pullup to 3.3V.
The box does not booting, looks like a reset loop. All LEDs toggle with a very high frequency.

Pulldown to GND works.

Kirsch,

If you have the box opened, please take a look to see any other peculiar headers, dip switch,... on the board?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

There is another header with 2 pins, but there is only 1.8V and GND

On JTAG the pins and series resistors are missing.

The ClearFog pro board has a DIP switch that they have to flip on to enable UART:
http://wtarreau.blogspot.com/2016_09_01_archive.html

I'd bet if our NAND u-boot were not present on mtd0, the bootROM will switch to UART. But I can't risk that.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 12/27/2016 06:04PM by bodhi.

Kirkwood 6281 SoC (earlier bootROM 1.2x)

Quote

BootROM Firmware Boot Options Boot from UART0

As previously indicated, boot from UART0 is not a sample at reset configuration option, but is performed before every type of boot through sensing the Rx side of the UART0 interface on both MPP options.

Armada 370 (bootROM 1.73)

Quote

6.2 Functional Description
The bootROM firmware—on the device’s integrated bootROM—is executed according to the Sample At Reset (SAR) configuration bits in the Sample at Reset Register (Table 1125 p. 1132).

Quote

Boot from the UART interface (using the Xmodem protocol) is attempted before a boot from any of the other interfaces. The device attempts to detect the various UART interfaces before proceeding with boot from the selected interface.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 2 time(s). Last edit at 12/28/2016 06:03PM by bodhi.

M - 1.73
Booting from NAND flash

General initialization - Version: 1.0.0
Detected Device ID 6810
High speed PHY - Version: 2.0

Init RD NAS topology board SerDes lanes topology details:
 | Lane #  | Speed |  Type       |
 --------------------------------
 |   0    |  06   |  SATA0	|
 |   1    |  05   |  USB3 HOST0	|
 |   2    |  06   |  SATA1	|
 |   5    |  05   |  USB3 HOST1	|
 --------------------------------
High speed PHY - Ended Successfully
DDR3 Training Sequence - Ver TIP-1.26.0
mvSysEnvGetTopologyUpdateInfo: TWSI Read failed
DDR3 Training Sequence - Switching XBAR Window to FastPath Window 
DDR3 Training Sequence - Ended Successfully
Not detected suspend to RAM indication
BootROM: Image checksum verification PASSED

 __   __                      _ _
|  \/  | __ _ _ ____   _____| | |
| |\/| |/ _` | '__\ \ / / _ \ | |
| |  | | (_| | |   \ V /  __/ | |
|_|  |_|\__,_|_|    \_/ \___|_|_|
         _   _     ____              _
        | | | |   | __ )  ___   ___ | |_ 
        | | | |___|  _ \ / _ \ / _ \| __| 
        | |_| |___| |_) | (_) | (_) | |_ 
         \___/    |____/ \___/ \___/ \__| 
 ** LOADER **


U-Boot 2013.01-svn48797 (Jan 18 2016 - 03:10:12) Marvell version: 2014_T3.0p6

Board: RD-NAS-88F6820-DDR3
SoC:   MV88F6810 Rev A0
       running 1 CPUs
CPU:   ARM Cortex A9 MPCore (Rev 1) LE
       CPU 0
       CPU    @ 1332 [MHz]
       L2     @ 666 [MHz]
       TClock @ 200 [MHz]
       DDR    @ 666 [MHz]
       DDR 32 Bit Width, FastPath Memory Access, DLB Enabled, ECC Disabled
DRAM:  512 MiB

Map:   Code:			0x1fed0000:0x1ff95e28
       BSS:			0x1ffef2b4
       Stack:			0x1f9cff20
       Heap:			0x1f9d0000:0x1fed0000
       U-Boot Environment:	0x00200000:0x00280000 (NAND)

NAND:  256 MiB
MMC:   mv_sdh: 0
*** Booting kernel from kernel 1 @0x00E00000 ***
USB2.0 0: Host Mode
USB3.0 0: Host Mode
USB3.0 1: Host Mode
Board configuration detected:
Net:   
|  port  | Interface | PHY address  |
|--------|-----------|--------------|
| egiga0 |   RGMII   |     0x01     |
egiga0 [PRIME]
Hit any key to stop autoboot:  0 

Marvell>> SatR list
SatR - Sample At Reset sub-system

Usage:
SatR list <field>          - list configuration options for <field>

SatR read                  - print all SatR configuration values
SatR read <field>          - print the requested <field> value

SatR write default         - restore all SatR fields to their default values
SatR write <field> <val>   - write the requested <field> <value>

	HW SatR fields
	--------------
coreclock                  - core frequency
freq                       - CPU DDR frequency
cpusnum                    - DB-381-BP only: number of CPU cores
sscg                       - SSCG modes
bootsrc                    - boot source
	SW SatR fields
	--------------
ddrbuswidth		- DB, DB-GP, DB-AP: DDR bus width
ddreccenable		- DDR ECC enable
ddreccpupselect	- DDR ECC PUP selection
sgmiispeed		- SGMII speed
sgmiimode		- SGMII negotiation mode
ddr4select		- DDR3/4		(read only)
ecoversion		- ECO version	(read only)
boardid		- board ID	(read only)

	 Board Specific SW fields
	------------------------
devid			- DB, DB-GP:	Device ID flavor
gpserdes1		- DB-GP:	SerDes lane #1
gpserdes2		- DB-GP:	SerDes lane #2
gpserdes5		- DB-GP:	SerDes lane #5
dbserdes1		- DB:		SerDes lane #1
dbserdes2		- DB:		SerDes lane #2
usb3port0		- DB:		USB3-Port0 mode
usb3port1		- DB:		USB3-Port1 mode

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi Kirsch,

Quote

I sniff the TX-Line with a second converter

Can you do this before starting kwboot on the 1st converter? I'm looking for a NAK that come back from the box bootROM.

I use a debugged version of kwboot and all I got was a continuous stream of 3DUfw, which does not make sense!

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

My trace above is complete, there is nothing before

BootROM - 1.73
Booting from NAND Flash

Kirsch Wrote:
-------------------------------------------------------
> My trace above is complete, there is nothing
> before

BootROM - 1.73
> Booting from NAND Flash

That's strange. We are not seeing the initial NAK that should be sent by the NAS326 to kwboot.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Another kernel update for NAS 326, patch includes all previous improvements by hean01 and also:

• MTD partitions work now - /dev/mtdX are visible, you can read them, BUT WRITE IS NOT TESTED. Kernel uses armada370-nand driver (NOT armada-nand == mvebu_nfc, like original ZyXEL 3.10.39 kernel - they're quite different)
• Added 'nas328_compile_kernel.sh' script - just pass a fresh 4.x.x kernel.tar.xz from kernel.org and it will uncompress it, apply patch, make zImage+initrd+dtb in a single file - zImage_dtb (you must have some desktop linux with cross-compile tools installed, I'm on Ubuntu 14.04.5 + stock gnueabihf cross-tools).
• Ready to use 4.8.15 kernel+initrd+dtb (single file) is in archive. You can boot it or write to nand (kernel1 or kernel2 partition)

nas326_4.8.15_kernel_20161230.tar.gz
nas326_20161230.patch

---
Boot it as usual - copy zImage_dtb to usb stick, plug it to front usb 2.0 port on nas 326. Then enter the following in u-boot console (I'm using cheap FTDI232 usb-serial interface, 3.3V logic levels):

## boot kernel from USB flash drive (front socket)
Marvell>> setenv bootargs "console=ttyS0,115200 root=LABEL=rootfs"
Marvell>> mw.l f1018140 003c8800
Marvell>> usb reset
Marvell>> ext2load usb 0:1 0x2000000 /boot/zImage_dtb
Marvell>> bootz 0x2000000

---
As I mentioned, MTD partitions are recognized and work now. It means after booting linux, you can access /dev/mtd1 (u-boot env params) and read them with fw_printenv utility.

1. Install fw_printenv + fw_setenv utilities (u-boot-tools Debian/Ubuntu package)
2. Create /etc/fw_env.config:

# NAND example
/dev/mtd1               0x0000          0x80000         0x20000                 4

3. Use fw_printenv to see u-boot environment

> sudo fw_printenv
ASset=max
CONTRY_TYPE=FF
FEATURE_BIT=00
MALLOC_len=5
MODEL_ID=B303
MPmode=SMP
PRODUCT_NAME=STG-328
VENDOR_NAME=MitraStar Technology Corp.
autoload=no
baudrate=115200
boot_order=hd_scr usb_scr mmc_scr hd_img usb_img mmc_img pxe net_img net_scr
bootargs=console=ttyS0,115200 root=LABEL=rootfs
bootargs_dflt=$console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel
.....

4. Or read params individually

sudo fw_printenv ethaddr
ethaddr=xx:xx:xx:xx:xx:xx

5. Having MAC address, you can apply it of course (this is exactly how it's done in ZyXEL firmware - they read it from env + apply with ifconfig):

sudo ifconfig eth0 down
sudo ifconfig eth0 hw ether xx:xx:xx:xx:xx:xx
sudo ifconfig eth0 up

6. Or you can hard-code it into /etc/network/interfaces (as I did):

# The primary network interface
auto eth0
iface eth0 inet dhcp
  hwaddress ether xx:xx:xx:xx:xx:xx

That's it for today. Happy holidays!

Kirsch,

Well it seems we lost some characters on the serial line. When you sniff with 2nd converter:

BootROM - 1.73

Did it pause here, if yes how long?

Booting from NAND flash

--------

I've sucessfully chainloaded a new Marvell u-boot build while stock u-boot is running. So I know my build is sane, but it is still not quite enough testing without loading by kwboot. However, if we are really out of ideas ... then I might flash it to mtd0.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)