Gaogao,

Please post your serial boot log, dmesg, and fw_printenv.

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

Hi,

@bodhi: just a question from a newbie: Is it possible to install your uboot-loader into mtd3 a do some chainloading with the original uboot from a dockstar?

Thanks,
Ilsa

@ilsa,

Most likely it won't work. Chainloading from an old u-boot such as stock u-boot to a much newer u-boot is not possible. However, chainloading from a newer u-boot to a very old u-boot such as stock might work. Chainloading was never supported by the U-Boot developers (except for Blackfin u-boot). Afaik, it was an undocumented feature.

By the way, IMO, it is just not very useful to go back to stock (go against the whole purpose of installing new u-boot and kernel). Anything stock FW can do, there is a way to do it in newer environment!

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

@bodhi: as requested

serial boot log

dmesg output

fw_printenv output

TKS

@gaogao,

Wow, you got a short deal here my friend. 2 bad blocks on mtd0! So the flashing instruction needs to be adjusted to make it work. But it is OK, there are plenty of space on mtd0 (8 blocks). We just need to be a little more careful.

[    2.888565] Bad eraseblock 2 at 0x000000040000
[    2.893101] Bad eraseblock 3 at 0x000000060000

You've mentioned above that the env location of this new U-Boot works right away. Are you running davygravy's u-boot? is your current env location defined as:

cat /etc/fw_env.config

# MTD device name	Device offset	Env. size	Flash sector size	Number of sectors
/dev/mtd0 0xc0000 0x20000 0x20000

And to confirm your copy of downloaded U-Boot:

ls -lh uboot.2013.10-tld-1.nsa320.mtd0.kwb 

-rw-r--r-- 1 root root 384K Aug 18 00:06 uboot.2013.10-tld-1.nsa320.mtd0.kwb

I'll be back with the flashing steps.

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

ouch :(

Anyway, YES and YES:

gaogao@mynas:~$ cat /etc/fw_env.config
# MTD device nameDevice offsetEnv. sizeFlash sector sizeNumber of sectors
/dev/mtd0 0xc0000 0x20000 0x20000

gaogao@mynas:~$ ls -lh uboot.2013.10-tld-1.nsa320.mtd0.kwb
-rwxr--r-- 1 gaogao gaogao 384K Aug 18 09:06 uboot.2013.10-tld-1.nsa320.mtd0.kwb
gaogao@mynas:~ md5sum uboot.2013.10-tld-1.nsa320.mtd0.kwb
b83ebd82c6c76fa5dfa41789ba9a1bd4  uboot.2013.10-tld-1.nsa320.mtd0.kwb

tks for helping me out with the flashing, much appreciated

@gaogao,

Note that these commands only applicable to your box with the bad blocks 2 and 3.

The first command will result in error when flash_erase encounters block 2 and 3, but it will erase the other 3 blocks successfully. The 2nd command will show that block 2 and 3 were skipped, because they are bad, but will write U-Boot image to the good 3 blocks successfully. If you'd like a confirmation, post your output of these 2 flashing commands below here before rebooting.

flash_erase /dev/mtd0 0 5
nandwrite /dev/mtd0 uboot.2013.10-tld-1.nsa320.mtd0.kwb

Next, list the envs for sanity check, there should be no error. If there is error, don't reboot, post the log here.

fw_printenv

Reboot the box. Watch the serial console and capture the boot log for later reference.

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

All working here thanks to your instructions: the NSA booted just fine from sata.
Kudos!

This post has been updated (new version uploaded) see here:

http://forum.doozan.com/read.php?3,12381,17420#msg-17420

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



Edited 2 time(s). Last edit at 08/30/2014 06:19PM by bodhi.

Hi bodhi,
since I still struggle with WOL, I'm very interested in trying out a new u-boot.
But this is all I got:

./kwboot -t -B 115200 /dev/ttyACM0 -b uboot.2013.10-tld-1.nsa325.mtd0.kwb -p
Sending boot message. Please reboot the target...\
Sending boot image...
  0 % [......................................................................]
  2 % [...................................................................+xmodem: Protocol error

Doesn't sound nice...
Do I have to set the envs location before I apply the update?
And what command would it be?

But also the other uboot produces the same error:

./kwboot -t -B 115200 /dev/ttyACM0 -b uboot.2013.10-tld-1.nsa320.mtd0.kwb -p
Sending boot message. Please reboot the target...|
Sending boot image...
  0 % [......................................................................]
  2 % [.....................................................................+xmodem: Protocol error

This is what I got at a normal boot:

U-Boot 1.1.4 (Jul 18 2013 - 10:47:29) Marvell version: 3.5.9

U-Boot code: 00600000 -> 0067FFF0  BSS: -> 006CFB00

Soc: 88F6282 A1CPU running @ 1600Mhz L2 running @ 800Mhz
SysClock = 533Mhz , TClock = 200Mhz 

DRAM (DDR3) CAS Latency = 7 tRP = 8 tRAS = 24 tRCD=8
DRAM CS[0] base 0x00000000   size 512MB 
DRAM Total size 512MB  16bit width
Addresses 10M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (10M - 7M): Done
NAND:128 MB
Flash:  0 kB

CPU : Marvell Feroceon (Rev 1)
Kernel address is 0x4640000.

Streaming disabled 
Write allocate disabled

Thanks!



Edited 1 time(s). Last edit at 08/26/2014 01:45AM by Eike.

Eike,

1. Have you found out what is your original MAC address? if you had kept the installation log it should be in there. This MAC address should work, it does for me.

2. For UART booting, should use this command (depending what device name the tty got assigned to, usually it is ttyUSB0):
./kwboot -t -B 115200 /dev/ttyUSB0 -b uboot.2013.10-tld-1.nsa325.mtd0.kwb -p

- On the NSA325, observe the Power button when you push it, if it flickers, then you will have to wait when the LED went out and start kwboot on the other Linux box. And you have to do this immediately before the LED light is on again.

- If the Power button does not flicker, then you have to start kwboot first, before pushing it.

Even though I know the image works, I would strongly recommend that UART booting is working first before flashing u-boot to NAND! because there will be time when you need a rescue mechanism.

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

Hi,
1. What installation log do you mean? Actually I have not installed anything to NAND. I just applied the scripts to modify the bootloader to boot from usb (I followed the instruction from http://zyxel.nas-central.org/wiki/Debian_on_325). The script usb_key_func.sh.2 from you is not touching the MAC address. So it should still be stock! It's stored in the ethaddr env var.

And also when booting to stock firmware, the zyxel webinterface is showing me exactly the same: 00:50:43:00:02:02. So I guess if the stock firmware is showing it to its users, it should be ok to use, or? Or do you thing when entering into sleep the marvell chip is changing the Mac somehow?

2. /dev/ttyACM0 is my serial port and it works w/o problems so far. It's an arduino usb2serial adapter with an additional 3.3v z-diode on its TX line. So booting from uart should normally work, as my command is like the one you suggested.

3. I'm somehow ashamed to ask you so many questions but there aren't other good information on the web ;)
So do you think it may be a good idea to completely reset the nsa325 and start from scratch? If yes, how can I reset *everything* to stock condition?

EDIT: Uboot UART booting is now starting but at ~80% it quits. The hdd spins down. It sounds like a shutdown. Maybe a watchdog issue...? I started kwboot immediately after the LED goes off for a short time.

pi@pi-Dell-System-XPS-L322X:~/Dokumente/Projekte/NAS/uboot/kwboot-tool$ ./kwboot -t -B 115200 /dev/ttyACM0 -b uboot.2013.10-tld-1.nsa325.mtd0.kwb -p
Sending boot message. Please reboot the target...\
Sending boot image...
  0 % [......................................................................]
  2 % [......................................................................]
  4 % [......................................................................]
  6 % [......................................................................]
  9 % [......................................................................]
 11 % [......................................................................]
 13 % [......................................................................]
 15 % [......................................................................]
 18 % [......................................................................]
 20 % [......................................................................]
 22 % [......................................................................]
 25 % [......................................................................]
 27 % [......................................................................]
 29 % [......................................................................]
 31 % [......................................................................]
 34 % [......................................................................]
 36 % [......................................................................]
 38 % [......................................................................]
 41 % [......................................................................]
 43 % [......................................................................]
 45 % [......................................................................]
 47 % [......................................................................]
 50 % [......................................................................]
 52 % [......................................................................]
 54 % [......................................................................]
 56 % [......................................................................]
 59 % [......................................................................]
 61 % [......................................................................]
 63 % [......................................................................]
 66 % [......................................................................]
 68 % [......................................................................]
 70 % [......................................................................]
 72 % [......................................................................]
 75 % [......................................................................]
 77 % [......................................................................]
 79 % [......................................................................]
 82 % [..........+xmodem: Protocol error

Thanks!



Edited 3 time(s). Last edit at 08/26/2014 10:16AM by Eike.

Eike,

> What installation log do you mean?

I meant when you power up the nsa325 the first time. Dmesg should show what was the original MAC address. I think Marvell software must have changed it. I've looked at my log to see exactly when it was changed, but could not find it. However, my 1st dmesg log showed a 10:7B:EF MAC address, not 00:50:43. My theory is that when you shut it down (not sleeping) and the NIC is still powered, the orginal MAC addr in the card is used.

> So do you think it may be a good idea to
> completely reset the nsa325 and start from
> scratch? If yes, how can I reset *everything* to
> stock condition?

No. It's working fine for you. I don't see the need to do this. WOL and UART booting should be working whether you run stock kernel or the 3.16 kernel.

> Uboot UART booting is now starting
> but at ~80% it quits. The hdd spins down. It
> sounds like a shutdown. Maybe a watchdog issue...?
> I started kwboot immediately after the LED goes
> off for a short time.

It does sound like the watchdog. If it was briefly reset like that. About the starting, once you see the loading message then the handshake has occurred. The image uboot.2013.10-tld-1.nsa325.mtd0.kwb is 384k, which should load completely before the watchdog kicks in. Keep trying a few times, perhaps it was just your serial console hardware.

If it still does not work after enough retries, how about trying the UART image UART from this post. This image should be executed without -p option:

kwboot -t -B 115200 /dev/ttyUSB0 -b uboot.2013.10-tld-1-test.nsa325.uart.kwb

This is a smaller image so it'll be easier to load it before watchdog starts.

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

Ok the test uboot works! It really seems to be a problem with the serial speed. So I tried out to double it:

fw_setenv console 'console=ttyS0,230400 mtdparts=nand_mtd:0xc0000@0(uboot)ro,0x7f00000@0x100000(root)'

but unfortunately the kwboot seems not to work with higher bitrates. I also tried 460800, 921600 baud.

./kwboot -t -B 230400 /dev/ttyACM0 -b uboot.2013.10-tld-1.nsa325.mtd0.kwb -p
Usage: kwboot -b <image> [ -p ] [ -t ] [-B <baud> ] <TTY>

  -b <image>: boot <image>
  -p: patch <image> to type 0x69 (uart boot)

  -t: mini terminal

  -B <baud>: set baud rate

1. But also with the new uboot the WoL and ACPID events are not working. Regarding the acpid events I wrote a github issue, to not bother you anymore.
Unfortunately I don't have a dmesg log from the very first boot. So no chance to get my original MAC address back :/
How about bruteforcing it ?!

2. What to do with the watchdog? Is it possible to somehow extend its period since faster baud rates aren't possible.

Eike,

Cool :) now you know that you have a rescue mechanism in case something goes wrong during flashing u-boot.

Quote

> 2. What to do with the watchdog? Is it possible to
> somehow extend its period since faster baud rates
> aren't possible.

There is no need to worry about it. Once you flashed new u-boot to NAND, the watchdog will be taken care of right the first second when u-boot starts to run. UART booting takes time to load, so that's why we need a small image. OTOH, u-boot in NAND is instantaneously loaded and executed.

Quote

> Unfortunately I don't have a dmesg log from the
> very first boot. So no chance to get my original
> MAC address back :/
> How about bruteforcing it ?!

This is hard to say. I can't say if you would want to reset the box. It's a judgement call, is WOL that important right now? perhaps there will be a way to make it work.

So I guess it is really up to you, whether you want to flash new u-boot now or wait until the official release in this thread. If you do want to upgrade u-boot to get rid of the watchdog, I'll post the instructions to do that. If you only want to fix WOL and ACPI then there is really no need to hurry. If you do want to flash, pls get the output of these and post here:

serial boot log
dmesg
fw_printenv
cat /etc/fw_env.config
cat /proc/mtd

By the way, this console env does not have anything to do with UART booting, it's only relevant as the kernel is concerned.

Quote

fw_setenv console 'console=ttyS0,230400 mtdparts=nand_mtd:0xc0000@0(uboot)ro,0x7f00000@0x100000(root)'

UART booting with these Marvell SoCs must be set at 115200 baudrate.

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

bodhi,
thanks for your fast reply. The reason I came all this way to try out a new u-boot is actually the WoL misfunction. For me it's a very important feature, since the NAS should not run all night without reason. So scheduled shutdown and automated start via WoL is what I actually want. So flashing U-Boot is not top priority right now.

I don't have a problem with resetting the whole NAS since my hdds and boot usb stick stay untouched and the only thing to do after a reset is to teach the nsa325 to boot from usb stick.

But as I'm writing these lines I'm not so confinced about a satisfying result. Why should it work afterwards?!
But what should I do instead? Format my usb stick and start with Kernel 3.14 again? I don't think that's solving my problem either :)
I even thought about a broken copper wire on the PCB which activates the whole boards after a MagicPacket reception...

Eike,

Quote
Eike
> I even thought about a broken copper wire on the
> PCB which activates the whole boards after a
> MagicPacket reception...

LOL. Sounds like you should go back to stock if WOL is that crucial to you. It is painless and simple as you've known. But keep your latest rootfs on USB, there is no need to repeat this process.

- Connect serial console and power up the nsa325.
- Let it boot into stock Debian.
- Capture the boot log, it should show in your dmesg what is your orginal MAC address is.
- setup USB booting.
- Boot with your latest Debian rootfs.
- Now try WOL like you did befofe, but with the orginal MAC addr.

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

*scratch head*

I mildly recall something about dicking around in the phy spin down to turn on WOL on one of the NSA32x's, having to actually write to a register the MAC address to listen for. I can't place where it was though. They screwed around with so many things.



Edited 1 time(s). Last edit at 08/27/2014 09:19PM by WarheadsSE.

@Warhead,

That might be it. I've only search in u-boot source for this, but not kernel source. may be I should just search the whole GPL source tree.

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



Edited 1 time(s). Last edit at 08/28/2014 12:49AM by bodhi.

@bodhi

Do you need another nsa325 tester?

Sorry if I missed something... but why did this thread switch from 2014.07 to 2013.10?

@dfarning,

> Do you need another nsa325 tester?

Sure. This is the pre-release test version for U-Boot:
http://forum.doozan.com/read.php?3,12381,17291#msg-17291

You can boot with UART and see if various new features working for you. I've already flashed this version to my NAND (so if you want to do so, it's safe). But please do boot with UART first to test this rescue capability. Among the 5 listed, I have not have time to test the last 4 items. If it's convenient in your environment then please try any of these. Thanks!

- watchdog is terminated upon start (already confirmed to work)
- EFI/GPT partition booting
- Ext4 booting
- Large disk > 2TB
- bootz

> Sorry if I missed something... but why did this
> thread switch from 2014.07 to 2013.10?

The nsa325 and nsa320 u-boot are still on 2013.10. So after WarheadsSE release it on GitHub, I will build and release the binary here. And then we'll rebase to 2014.07.

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

I just successfully moved my Pogo Mobile from USB Boot to MMC Boot for ArchLinux... Thanks again for the great 'ible.

Just 3 remarks regarding "Part B" instructions:
1) The rootfstype doesn't show up as a separate variable when using blparams from USB based ArchLinux (cannot comment on the Pogo native OS)
2) The mtdparts is not present at all when using blparams from USB based ArchLinux (cannot comment on the Pogo native OS) I reconstructed the correct values from /proc/mtd
3) The ethaddr is not present at all when using blparams from USB based ArchLinux (cannot comment on the Pogo native OS) I reconstructed that using ifconfig (easier than typing it over from the bottom sticker)

Best,
--
Francesco

Some success.... and some failures.

I was able prove that my device can boot from UART vai kwboot as an error recovery console.

1. Rebooting was a challenge. Since the nas lives under the desk I do everything remotely, I had never enabled the shutdown button in debian. For some reason my old standby "sudo shutdown -r now" didn't cause the machine to reboot. It gave the system going down message, but didn't actually go down. I tried pulling the plug followed by timing power on and kwboot about 5 times but never got past 80% in the firmware upload.

2. What finally work was "run to_stock" and reboot via the stock webgui. That worked several times. I was able to boot to ext2 on both a usb stick and sata drive.

3. After a few test iterations, things started to get weird :( The power button and reset button stopped working. The serial console started producing gibberish. I could still enter commands via the console, ssh work and the varius web UI works. It was just the characters that were not displayed correctly in the serial console.

4. At this point I tried to reboot the stock firmware via the web gui and using force_flash on usb. Force flash fail and the stock firmware reported "invalid firmware"

5. Luckily I still have access to the device via webui, ssh, serial console, and kwboot so it is definitely not bricked. But I have exhausted my knowledge of uboot.

Is is possible to force a factory reset from the serial console or reflash the factory firmware so I get back to fully working state before I continue testing?

dfarning,

That is certainly strange. However, booting with UART does not change any thing :) nothing change in your box. Once you've rebooted, it's back to where you were.

> 1. Rebooting was a challenge. Since the nas lives
> under the desk I do everything remotely, I had
> never enabled the shutdown button in debian. For
> some reason my old standby "sudo shutdown -r now"
> didn't cause the machine to reboot. It gave the
> system going down message, but didn't actually go
> down. I tried pulling the plug followed by timing
> power on and kwboot about 5 times but never got
> past 80% in the firmware upload.

What you've experienced above does not have anything to do with u-boot. Have you tried "shutdown -r now", no sudo?

> 3. After a few test iterations, things started to
> get weird :( The power button and reset button
> stopped working. The serial console started
> producing gibberish. I could still enter commands
> via the console, ssh work and the varius web UI
> works. It was just the characters that were not
> displayed correctly in the serial console.

This is certain weird! when you boot with UART, and serial console is acting up like that, just power down, and start back up to your orginal system state from a cold start.

> 4. At this point I tried to reboot the stock
> firmware via the web gui and using force_flash on
> usb. Force flash fail and the stock firmware
> reported "invalid firmware"
>

I am not sure about "force flash"? is that a NSA325 factory reset? This step you've taken is a no-no!!! don't go back to the web GUI. Just use SSH.

After booting with UART, did you save or change any u-boot env while you are in the serial console, or in Debian?

> Is is possible to force a factory reset from the
> serial console or reflash the factory firmware so
> I get back to fully working state before I
> continue testing?

Have you power down, wait a few minutes, and boot your previous system (i.e. same rootfs, stock u-boot)? What do you see on serial console when you do that?

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



Edited 2 time(s). Last edit at 08/28/2014 08:22PM by bodhi.

I have seen this 'gibberish' before when I first tried to install debian on the device. I fixed it by

running
Marvell>> resetenv
Marvell>> reset

using the factory reset button.

running
Marvell>> resetenv
Marvell>> reset

So, this implies that I somehow hit a preexisting bug.... not anything new in your uboot.

Back to debugging

Ahh interesting neither shutdown +unplug + reboot nor shutdown + unplug+ wait 5 minutes + reboot fixed the issue.

Shutdown + unplug + go to dinner + think about it for a couple of hours + reboot to fix it.

Back to testing the new u-boot.

OK my next data points on loading the uboot via kwboot.

On my setup, I need to disconnect both the power cable and the serial cable from the nas before rebooting and disconnect the usb-serial adapter from the computer before rebooting otherwise there are random failures.

5 out of 5 times the upload fail with uboot.2013.10-tld-1.nsa325.mtd0.kwb. the failure was consistently at the same 82% mark Eike experienced.

4 out of 4 time successful upload with the smaller test file with ext2 /boot and ext4 rootfs on a USB stick.
4 out of 4 time successful upload with the smaller test file with ext2 /boot and ext4 rootfs on a SATA drive.

Does this seem stable enough to flash to nand and do another round of testing with ext4 /boot?

You did not attach the Vcc line of the serial, did you?

dfarning,

Quote

> 4 out of 4 time successful upload with the smaller
> test file with ext2 /boot and ext4 rootfs on a USB
> stick.
> 4 out of 4 time successful upload with the smaller
> test file with ext2 /boot and ext4 rootfs on a
> SATA drive.
>
> Does this seem stable enough to flash to nand and
> do another round of testing with ext4 /boot?

Ok, thanks for testing so far. I've run this 384K NAND version with UART quite a few times. It is always loaded completely before the watchdog kicks in. It could be the reduced speed that caused the problem. However, I will try a few more times with UART just to be sure I don't see what you experienced.

Update1:
Yes! first time in a while I saw it stop at 80%.

Update2:
384K seems too marginal for comfort. I will upload another NAND version for testing.

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



Edited 2 time(s). Last edit at 08/29/2014 11:59PM by bodhi.

dfarning,

Quote

> On my setup, I need to disconnect both the power
> cable and the serial cable from the nas before
> rebooting and disconnect the usb-serial adapter
> from the computer before rebooting otherwise there
> are random failures.

I agree with WarheadsSE. It sounds like you have either a faulty or incorrectly connected serial console?

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

Weird, I seem to have lost my reply to this thread.

Long story short, I ordered 2 new serial adapter and will continue testing when they arrive.