UART Booting HowTo for Selected Kirkwood Devices

mike Wrote:
-------------------------------------------------------
> I will try
> http://forum.doozan.com/read.php?2,11663,11713#msg
> -11713

No, dont try that. I will post link to different post.

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

Mike,

With SD rootfs plugged in, kwboot again, interrupt serial console and

run bootcmd_uenv
setenv dtb_file '/boot/dts/kirkwood-pogoplug_v4.dtb'
boot

You will boot into Debian correctly as the Pogo V4. LED should be on correctly.

Proceed to instal Pogo V4 u-boot for real:
http://forum.doozan.com/read.php?3,12381

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

Hi bodhi,
Thank you one more time for your help!
It's done. My pogoplug is alive.

4.6.0-kirkwood-tld-1 on board.

I did this to flash uboot to NAND.

flash_erase /dev/mtd0 0 4
nandwrite /dev/mtd0 uboot.2016.05-tld-1.pogo_v4.mtd0.kwb
flash_erase /dev/mtd0 0xc0000 1
nandwrite -s 786432 /dev/mtd0 uboot.2014.07-tld-1.environment.img
uboot.2016.05-tld-1.environment.img
fw_setenv arcNumber 3960
fw_setenv machid F78
fw_setenv usb_rootfstype ext3
fw_setenv mtdparts 'mtdparts=orion_nand:2M(u-boot),3M(uImage),3M(uImage2),8M(failsafe),112M(root)'
fw_setenv bootcmd 'run bootcmd_uenv; boot; reset'

After flashing you dont need uEnv.txt. Remove it and

Set bootcmd back to

fw_setenv bootcmd 'run bootcmd_uenv; run scan_disk; run set_bootargs; run bootcmd_exec; reset'

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

Hi Bodhi,
I have done this:

mv /boot/uEnv.txt /boot/uEnv.bak
fw_setenv bootcmd 'run bootcmd_uenv; run scan_disk; run set_bootargs; run bootcmd_exec; reset'
reboot

... and led was blinking green then appeared orange and pogo couldn't boot.

I've restored uEnv.txt on another linux box, restarted and pogo works again.
It seems that I have to have uEnv.txt in /boot/.

fw_prinenv

bootcmd_exec=run load_uimage; if run load_initrd; then if run load_dtb; then bootm $load_uimage_addr $load_initrd_addr $load_dtb_addr; else bootm $load_uimage_addr $load_initrd_addr; fi; else if run load_dtb; then bootm $load_uimage_addr - $load_dtb_addr; else bootm $load_uimage_addr; fi; fi
bootcmd_uenv=run uenv_load; if test $uenv_loaded -eq 1; then run uenv_import; fi
bootdelay=10
bootdev=usb
device=0:1
devices=usb ide mmc
disks=0 1 2 3
ethact=egiga0
ethaddr=52:3b:20:9c:11:51
led_error=orange blinking
led_exit=green off
led_init=green blinking
load_dtb_addr=0x1c00000
load_initrd_addr=0x1100000
load_uimage_addr=0x800000
load_dtb=echo loading DTB $dtb_file ...; load $bootdev $device $load_dtb_addr $dtb_file
load_initrd=echo loading uInitrd ...; load $bootdev $device $load_initrd_addr /boot/uInitrd
load_uimage=echo loading uImage ...; load $bootdev $device $load_uimage_addr /boot/uImage
mainlineLinux=yes
mtdids=nand0=orion_nand
partition=nand0,2
preboot_nc=run if_netconsole start_netconsole
scan_disk=echo running scan_disk ...; scan_done=0; setenv scan_usb "usb start";  setenv scan_ide "ide reset";  setenv scan_mmc "mmc rescan"; for dev in $devices; do if test $scan_done -eq 0; then echo Scan device $dev; run scan_$dev; for disknum in $disks; do if test $scan_done -eq 0; then echo device $dev $disknum:1; if load $dev $disknum:1 $load_uimage_addr /boot/uImage 1; then scan_done=1; echo Found bootable drive on $dev $disknum; setenv device $disknum:1; setenv bootdev $dev; fi; fi; done; fi; done
set_bootargs=setenv bootargs console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 $mtdparts $custom_params
stderr=serial
stdin=serial
stdout=serial
uenv_addr=0x810000
uenv_import=echo importing envs ...; env import -t $uenv_addr $filesize
uenv_init_devices=setenv init_usb "usb start";  setenv init_ide "ide reset";  setenv init_mmc "mmc rescan"; for devtype in $devices; do run init_$devtype; done;
uenv_load=run uenv_init_devices; setenv uenv_loaded 0; for devtype in $devices;  do for disknum in 0; do run uenv_read_disk; done; done;
uenv_read_disk=if test $devtype -eq mmc; then if $devtype part; then run uenv_read;  fi; else if $devtype part $disknum; then run uenv_read; fi;  fi
uenv_read=echo loading envs from $devtype $disknum ...; if load $devtype $disknum:1 $uenv_addr /boot/uEnv.txt; then setenv uenv_loaded 1; fi
usb_ready_retry=15
mtdparts=mtdparts=orion_nand:2M(u-boot),3M(uImage),3M(uImage2),8M(failsafe),112M(root)
arcNumber=3960
machid=F78
bootcmd=run bootcmd_uenv; run scan_disk; run set_bootargs; run bootcmd_exec; reset
dtb_file=/boot/kirkwood-pogoplug_v4.dtb
ipaddr=192.168.0.10
serverip=192.168.0.3
if_netconsole=ping $serverip
start_netconsole=setenv ncip $serverip; setenv bootdelay 10; setenv stdin nc; setenv stdout nc; setenv stderr nc; version;
preboot=run if_netconsole start_netconsole

uEnv.txt

dtb_file=/boot/dts/kirkwood-pogoplug_v4.dtb

mike,

Then after booting into Debian,

fw_setenv dtb_file '/boot/dts/kirkwood-pogoplug_v4.dtb'

And move uEnv.txt to uEnv.txt.bak.

If you still can't boot without uEnv.txt then use picocom to monitor serial console, capture the log and post here.

If you don't have picocom, then in Debian,

apt-get install picocom

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

It works. Thank you!

I can confirm that kwboot works with the Iomega IX4-200d which has BootRom v1.11

The trick is to flip the switch and start kwboot after approx 1 second. Quite reliable though.

My command is
kwboot -b uboot.2016.05-tld-1.sheevaplug.mtd0.kwb -B 115200 -t -p /dev/...

I'm not sure whether this uboot image came from this thread, but it's certainly here on the forum.

Qizhitong 501m v2 confirmed

Hi bodhi - I'm bbaaaaaacckkk (hopefully this won't be as epic a journey as with my E02 from a few days ago, and thanks again for all the help there by the way).

I have a Pogoplug Mobile which I must have messed up some time ago - it won't boot, but when I connect via serial I see some envs that look like they belong with an E02 and not a V4/Mobile.

I'm trying now to "test this boot image with UART booting before flashing to NAND" (from your latest U-boot post).

I untarred kwboot-2016.05.tar & downloaded your latest uboot, then typed

root@PogoV4Debian:/temp# ./kwboot -t -B 115200 /dev/ttyUSB0 -b uboot.2017.07-tld-1.pogo_v4.mtd0.kwb -p

At first I thought this was failing, but then I found this thread and your exchange with Mike, and after several repetitions of the kwboot command I got

Sending boot image...
  0 % [......................................................................]
  1 % [......................................................................]
...
 97 % [......................................................................]
 99 % [....................................]
[Type Ctrl-\ + c to quit]

...but then nothing else happens. At no point does the LED on my Pogo come on.

I'm supposed to see the U-boot start up here, correct?

I'm connecting with picocom running on a functioning Pogo-V4. My mobile has a USB stick plugged in with newest rootfs, and the ethernet cable is plugged in.

I have a feeling you might ask me to post printenv output:

Pogov4> printenv
arcNumber=3960
bootcmd=run bootcmd_usb; run bootcmd_mmc; run bootcmd_sata; run bootcmd_pogo; reset
bootcmd_exec=run load_uimage; if run load_initrd; then if run load_dtb; then bootm $load_uimage_addr $load_initrd_addr $load_dtb_addr; else bootm $load_uimage_addr $load_initrd_addr; fi; else if run load_dtb; then bootm $load_uimage_addr - $load_dtb_addr; else bootm $load_uimage_addr; fi; fi
bootcmd_uenv=run uenv_load; if test $uenv_loaded -eq 1; then run uenv_import; fi
bootdelay=10
bootdev=usb
device=0:1
devices=usb ide mmc
disks=0 1 2 3
dtb_file=/boot/dts/kirkwood-pogo_e02.dtb
ethact=egiga0
ethaddr=00:25:31:06:25:fd
if_netconsole=ping $serverip
ipaddr=192.168.0.231
led_error=orange blinking
led_exit=green off
led_init=green blinking
load_dtb=echo loading DTB $dtb_file ...; load $bootdev $device $load_dtb_addr $dtb_file
load_dtb_addr=0x1c00000
load_initrd=echo loading uInitrd ...; load $bootdev $device $load_initrd_addr /boot/uInitrd
load_initrd_addr=0x1100000
load_uimage=echo loading uImage ...; load $bootdev $device $load_uimage_addr /boot/uImage
load_uimage_addr=0x800000
machid=F78
mainlineLinux=yes
mtdids=nand0=orion_nand
mtdparts=mtdparts=orion_nand:2M(u-boot),3M(uImage),3M(uImage2),8M(failsafe),112M(root)
partition=nand0,2
preboot_nc=run if_netconsole start_netconsole
scan_disk=echo running scan_disk ...; scan_done=0; setenv scan_usb "usb start";  setenv scan_ide "ide reset";  setenv scan_mmc "mmc rescan"; for dev in $devices; do if test $scan_done -eq 0; then echo Scan device $dev; run scan_$dev; for disknum in $disks; do if test $scan_done -eq 0; then echo device $dev $disknum:1; if load $dev $disknum:1 $load_uimage_addr /boot/uImage 1; then scan_done=1; echo Found bootable drive on $dev $disknum; setenv device $disknum:1; setenv bootdev $dev; fi; fi; done; fi; done
serverip=192.168.0.220
set_bootargs=setenv bootargs console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 $mtdparts $custom_params
start_netconsole=setenv ncip $serverip; setenv bootdelay 10; setenv stdin nc; setenv stdout nc; setenv stderr nc; version;
stderr=serial
stdin=serial
stdout=serial
uenv_addr=0x810000
uenv_import=echo importing envs ...; env import -t $uenv_addr $filesize
uenv_init_devices=setenv init_usb "usb start";  setenv init_ide "ide reset";  setenv init_mmc "mmc rescan"; for devtype in $devices; do run init_$devtype; done;
uenv_load=run uenv_init_devices; setenv uenv_loaded 0; for devtype in $devices;  do for disknum in 0; do run uenv_read_disk; done; done;
uenv_read=echo loading envs from $devtype $disknum ...; if load $devtype $disknum:1 $uenv_addr /boot/uEnv.txt; then setenv uenv_loaded 1; fi
uenv_read_disk=if test $devtype -eq mmc; then if $devtype part; then run uenv_read;  fi; else if $devtype part $disknum; then run uenv_read; fi;  fi
usb_ready_retry=15
usb_rootfstype=ext3

Environment size: 2904/131068 bytes
Pogov4>

If you have some advice either on how to get the UART boot to work, or just changes to make to the envs, please let me know. I thought I had changed the obvious problems (dtb_file, serverip & ipaddr) but I must not have saved the changes and at this point it's probably best to just show you what's there.

As always, profuse and over-effusive thanks for all your help.
-huge


[EDIT: Should have mentioned the errors that come up on boot attempt. Here they are]

Pogov4> boot
## Error: "bootcmd_usb" not defined
## Error: "bootcmd_mmc" not defined
## Error: "bootcmd_sata" not defined
## Error: "bootcmd_pogo" not defined
resetting ...


U-Boot 2016.05-tld-1 (Jun 12 2016 - 13:41:47 -0700)
Pogoplug V4

SoC:   Kirkwood 88F6192_A1
DRAM:  128 MiB
WARNING: Caches not enabled
NAND:  128 MiB
MMC:   kwsdio: 0
In:    serial
Out:   serial
Err:   serial
Net:   egiga0
Hit any key to stop autoboot:  0
Pogov4>

Edited 1 time(s). Last edit at 10/31/2017 04:55PM by huge.

huge,

> root@PogoV4Debian:/temp# ./kwboot -t -B 115200
> /dev/ttyUSB0 -b
> uboot.2017.07-tld-1.pogo_v4.mtd0.kwb -p

> [Type Ctrl-\ + c to quit]

When it stuck here, it might mean that your serial connection is not solid. At this point u-boot has not started yet, so don't worry about the envs. Check the wires and try again. Serial console might work OK with marginal connections, but kwboot does handshake so it could be stuck.

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

bodhi Wrote:
-------------------------------------------------------
> huge,
>
>

> > root@PogoV4Debian:/temp# ./kwboot -t -B 115200
> > /dev/ttyUSB0 -b
> > uboot.2017.07-tld-1.pogo_v4.mtd0.kwb -p
> 
> > [Type Ctrl-\ + c to quit]
>

>
> When it stuck here, it might mean that your serial
> connection is not solid. At this point u-boot has
> not started yet, so don't worry about the envs.
> Check the wires and try again. Serial console
> might work OK with marginal connections, but
> kwboot does handshake so it could be stuck.

Well, shoot. That's going to be tough. I don't own a soldering iron so I have the wires taped to the circuit board. I'm not surprised that I would have a "marginal connection", but at this point I don't know if I can do anything about it other than trying to clamp the wires down a little tighter.

huge Wrote:
-------------------------------------------------------
> bodhi Wrote:
> -------------------------------------------------------
> > huge,
> >
> >

> > > root@PogoV4Debian:/temp# ./kwboot -t -B
> 115200
> > > /dev/ttyUSB0 -b
> > > uboot.2017.07-tld-1.pogo_v4.mtd0.kwb -p
> > 
> > > [Type Ctrl-\ + c to quit]
> >

> >
> > When it stuck here, it might mean that your
> serial
> > connection is not solid. At this point u-boot
> has
> > not started yet, so don't worry about the envs.
> > Check the wires and try again. Serial console
> > might work OK with marginal connections, but
> > kwboot does handshake so it could be stuck.
>
> Well, shoot. That's going to be tough. I don't own
> a soldering iron so I have the wires taped to the
> circuit board. I'm not surprised that I would have
> a "marginal connection", but at this point I don't
> know if I can do anything about it other than
> trying to clamp the wires down a little tighter.

It worked fo rme in the past with small pins and test clips. These solder buttons are soft enough.

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

The UART boot works for NSA310

Would this work on a bricked Synology DS414?

I get console output but it’s stuck on the boot process and I think it needs uboot restoring.

I need some help but the Synology forums are rubbish.

Rik Bignell,

> Would this work on a bricked Synology DS414?

Yes it would. This box is Armada XP.

DS414	Marvell Armada XP MV78230	Dual Core	2	Yes	Armadaxp	DDR3 1 GB

When you run kwboot command from your serial converter host, use option -a (this is specific for Armada XP).

If you need help while doing the unbricking, start a new thread in this sub-forum with subject "Unbricking Synology DS414 (Armada XP)".

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

UART boot works with NSA325.
Tested with:
* kwboot from u-boot-utils 2019.07+dfsg-1ubuntu4~18.04.1
* uboot.2017.07-tld-1.nsa325.mtd0.kwb

Quote
Bodhi
And here is how you boot the Pogo Mobile (it is different from other Kirkwood boxes, a little bit flaky):

- Start kwboot on a different Linux box ....
- Power up the Pogo V4/Mobile.
- Within 1-2 seconds when the spinning | starts slowing down (but not too soon), Control-C to abort kwboot, and recall the command, execute kwboot again.
- Repeatedly run kwboot this way for a few times, it will handshake successfully eventually.

Bodhi knows far far more than I about these devices, but I have had trouble connecting to a new-old-stock V4-A3-01. Canceling/Switching the power did not help. It kwboot for the first time after cycling the power once and leaving it unattended for around 10-15min. I subsequently made the connection a few times by waiting 5-10 minutes. However, I just discovered that, if the serial connection is anywhere near the OEM power plug, this may cause problems. As soon as I separate these connections as far as possible kwboot starts running. After the initial connection, they can be in the same vicinity without causing me issue.
Note, I'm using an ~800mm long shielded audio cable connected to a panel mount audio jack that I added to the Pogoplug/UART connection and an Asian grey market PL2303 module for USB to TTL. I also used a CH340E isolation converter module to connect without issue. I'm only mentioning because the long cable could be causing/exasperating my kwboot startup connection issues.
I'm adding this post reply because, if I hadn't gotten up to make a cup of coffee while trying to get kwboot working I probably would have assumed other issues were afoot and taken much longer to discover that simply picking up the Pogoplug and holding the wires away from each other makes an immediate connection with repeatable results.
-Jake

P.S. Bodhi, Jeff, and other contributors on this forum- Thanks for all your work and effort here. This is a fun way to learn and explore a well documented device and toolchain.

Jake,

Thanks for an astute observation! very helpful.

The steps I listed above would allow the handshake to occur after many retries.

But I did not think further about the reason why there were errors on the wires. Now I realized from your observation that it simply catched the time when there was less interferrence. You've confirmed that was because the unshielded 3 wires we are all using stting next to the power supply connector :)

Thumb up!

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

Hello everyone,

it might make sense to use this thread for my problem as this is the origin of the instructions and maybe someone has faced something similar.

After unsuccessfully attempting to get my Zyxel NSA325v2 to read any USB device or connect to a TFTP server, I wanted to try to use kwboot to flash a new uboot (currently still Zyxel stock).
My original thread: https://forum.doozan.com/read.php?3,119919

I am running a RPi 4 with 8 GB, Raspian OS 64-bit.

[91387.374689] usb 1-1.3: Detected FT232RL
[91387.379766] usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB0
pi@pi:~/Downloads/kwboot-tool $ ls -la
total 5664
drwxr-xr-x 2 pi pi    4096 May 12 09:03 .
drwxr-xr-x 3 pi pi    4096 May 12 08:47 ..
-rw-r--r-- 1 pi pi 4063232 May 12 08:51 18.bin
-rwxrwxrwx 1 pi pi   15604 May 12 09:03 kwboot
-rw-r--r-- 1 pi pi  569104 May 12 08:51 uboot.bin
-rw-r--r-- 1 pi pi  569168 May 12 08:51 uboot.img
-rw-r--r-- 1 pi pi  569620 May 12 08:51 uboot.kwb
pi@pi:~/Downloads/kwboot-tool $ ./kwboot -t -B 115200 /dev/ttyUSB0 -b uboot.kwb
bash: ./kwboot: No such file or directory
pi@pi:~/Downloads/kwboot-tool $

Using this kwboot from the deopbox linked in this forum by bodhi https://bitly.com/2hfdNPS .
The uboot.kwb is the OpenWRT one.

/dev/ttyUSB0 seems to be working as Putty can connect without any issues.

So I am not quite sure what is goin wrong or what I am doing wrong. Anybody have any ideas?



Edited 2 time(s). Last edit at 05/12/2021 05:42AM by AleXSR700.

Try the kwboot in u-boot-tools package.

sudo apt-get update; sudo apt-get upgrade; sudo apt-get install u-boot-tools

then try to kwboot it.

Hello @daviddyer,
thank you for the suggestion. Didn't even think to check the official repo :-D

Anyway, one step closer but still not quite there

pi@pi:~/Downloads $ kwboot -t -B 115200 /dev/ttyUSB0 -b uboot.kwb -p
Sending boot message. Please reboot the target...\
Sending boot image...
  0 % [+xmodem: Protocol error
pi@pi:~/Downloads $

Did I do something wrong or does it only work with special uboot versions?
I used the one from here:
https://downloads.openwrt.org/releases/18.06.9/targets/kirkwood/generic/u-boot-nsa325/

P.S.: I tried repeating the commend a bunch of times without rebooting, but no luck. I wanted to log with putty in parallel, but I don't see anything in putty.
I can boot to uboot with putty and then start kwboot, but it just again tells me to reboot and then shows the above error.

EDIT:
Serial logging of normal boot:

         __  __                      _ _
        |  \/  | __ _ _ ____   _____| | |
        | |\/| |/ _` | '__\ \ / / _ \ | |
        | |  | | (_| | |   \ V /  __/ | |
        |_|  |_|\__,_|_|    \_/ \___|_|_|
 _   _     ____              _
| | | |   | __ )  ___   ___ | |_ 
| | | |___|  _ \ / _ \ / _ \| __| 
| |_| |___| |_) | (_) | (_) | |_ 
 \___/    |____/ \___/ \___/ \__| 
 ** MARVELL BOARD: DB-88F6282A-BP LE 

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 @ 533Mhz
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 0xc80000.

Streaming disabled 
Write allocate disabled


USB 0: host mode
	[BlueDBG] reseting SoC Pex[0]  0 ...
PEX 0: PCI Express Root Complex Interface
PEX interface detected Link X1
	[BlueDBG] reseting SoC Pex[1]  0 ...
	[BlueDBG] reseting SoC Pex[1]  1 ...
	[BlueDBG] reseting SoC Pex[1]  2 ...
	[BlueDBG] reseting SoC Pex[1]  3 ...
	[BlueDBG] reseting SoC Pex[1]  4 ...
	[BlueDBG] reseting SoC Pex[1]  5 ...
	[BlueDBG] reseting SoC Pex[1]  6 ...
	[BlueDBG] reseting SoC Pex[1]  7 ...
	[BlueDBG] reseting SoC Pex[1]  8 ...
	[BlueDBG] reseting SoC Pex[1]  9 ...
	[BlueDBG] reseting SoC Pex[1]  10 ...
PEX 1: interface detected no Link.
Net:   egiga0 [PRIME]
Hit any key to stop autoboot:  2  1  0 

NAND read: device 0 offset 0xc80000, size 0xa00000


Bad block at 0xc80000 in erase block from 0xc80000 will be skipped

Reading data from 0xca0000 --   0% complete.
Reading data from 0xcb9800 --   1% complete.
Reading data from 0xcd3000 --   2% complete.
Reading data from 0xcec800 --   3% complete.

and so on

Reading data from 0x169f800 -- 100% complete.
 10485760 bytes read: OK
## Booting image at 02000000 ...
   Image Name:   Linux-2.6.31.8
   Created:      2016-05-02   6:32:03 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    5796204 Bytes =  5.5 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux................................................................................................................................................................................................................................................................................ done, booting the kernel.

Linux version 2.6.31.8 (root@BuildMachine) (gcc version 4.3.2 (sdk3.3-ct-ng-1.4.1) ) #2 Mon May 2 14:31:47 CST 2016
CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
CPU: VIVT data cache, VIVT instruction cache
Machine: Feroceon-KW
Using UBoot passing parameters structure
Memory policy: ECC disabled, Data cache writeback

Edited 3 time(s). Last edit at 05/12/2021 11:25AM by AleXSR700.

AleXSR700,

davygravy has not come around the forum for quite a while.

> pi@pi:~/Downloads $ kwboot -t -B 115200
> /dev/ttyUSB0 -b uboot.kwb -p
> Sending boot message. Please reboot the
> target...\
> Sending boot image...
> 0 % [+xmodem: Protocol error

You can run the kwboot binary that comes with the rPi (I forgot to update the u-boot instruction to recommend that).

When you see the "xmodem: Protocol error", do the following:

- Make sure the serial wires are far from the power cord (to avoid interference).

- Run with the image uboot.2017.07-tld-1.nsa325.mtd0.kwb as I mentioned on the other thread.

- When you see the protocol error, recall the kwboot command and immediately execute that. Repeat this quickly, as many time as needed.

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

I tried it and tried it to no avail :(
Always the same message.
Is there a way to stop the system e.g. via Putty at a point where kwboot would be able to start sending?

AleXSR700,

> I tried it and tried it to no avail :(
> Always the same message.
> Is there a way to stop the system e.g. via Putty
> at a point where kwboot would be able to start
> sending?

Post the kwboot command that you used and its output.

The NSA325v2 does support kwboot. So it is good to check the serial connections, and make sure that you can use picocom/minicom to see the serial connection is working well, and then try kwboot.

And don't rely on putty. You need to use picocom or minicom to test it using the rPi.

On rPi,

apt-get install picocom

and then

picocom --b 115200 --f n --p n --d 8 /dev/ttyUSB0

And then power up the NSA325.

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

picocom worked straight out of the box. No problems.

kwboot -t -B 115200 /dev/ttyUSB0 -b uboot.kwb -p

I tried and retried but I always get the same modem error.
If I then, after then 20 tries with kwboot call the picocom without rebooting, the board recognizes the connection and starts a reboot.
If I then stop the boot and go to uboot with picocom and in another terminal call the kwboot (with picocom wtill connected), I can see that the NSA325v2 receives the kwboot command because the screen immediately goes hyroglyphical in picocom.

So I am assuming that any bad connection on the serial or wrong connection can be ruled out because communication is working.
But some reason the NSA is not accepting the kwboot call.

There is nothing I can trigger via picocom first to get the board "ready" and waiting?

AleXSR700,

> So I am assuming that any bad connection on the
> serial or wrong connection can be ruled out
> because communication is working.

That's not a good assumption. Because kwboot is using xmodem protocol. And piccom is a terminal.

xmodem is susceptible to noise. The handshake (a special encoded string of characters needs to be received by the box BootROM) would occur first, and then later each sector will have ACK/NAK. Very different from a normal tty session.

So a good serial connection by picocom is just a test to see TX and RX connections are good to go.

> But some reason the NSA is not accepting the
> kwboot call.
>
> There is nothing I can trigger via picocom first
> to get the board "ready" and waiting?

No. There is nothing software-wise that we can do. There are NAS boxes that use a DIP switch to put the box BootROM into a listening mode right away after power up (basically bypass the handshake). But this box does not have that.

I have seen the xmodem protocol error countless times. It's a miss-handshake. Usually happens a lot with boxes like the Popoplug V4. With the NSA325, I did not see this problem (I probably have kwboot my NSA325 hundred times during developing u-boot for it).

Upon power up, Marvell BootROM listens to the serial port for a special string and when it "hears" that, it responds with a byte that kwboot recognizes so it start sending the payload (u-boot image).

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

Quote

I can see that the NSA325v2 receives the kwboot command because the screen immediately goes hyroglyphical in picocom.

Not sure I understood this statement.

Are you running 2 terminals, kwboot and picocom? don't do that. kwboot should be the only session.

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

No no, I was only running one terminal with one UART session.

But when I saw that it was not working I figured I might as well not reboot or touch anything and simply open picocom to see if the connection is possible. And it was.

So I then figured "what the heck", might as well keep the picocom alive and send the kwboot command in a second terminal just to see if the NAS is reacting or whether this command does not register at all.
But it did.

So I know that a signal is coming in. The NAS is seeing the kwboot command. I just do not know what it is seeing because you cannot run kwboot and picocom successfully at the same time.

It was just a test setup to check hardware connections.

I assume that none of this would be possible if the TX/RX was crossed or the GND had a poor connection.

But I am not getting anywhere. I have tried and tried and it just won't send the uboot. Always the xmodem error.
At some point it won't do anything anymore and just wait. So after e.g. 10 times resending the command, it will just show

pi@pi:~/Downloads $ kwboot -t -B 115200 /dev/ttyUSB0 -b uboot.kwb -p
Sending boot message. Please reboot the target...\

and not do anything anymore. Even after 30 min, nothing. So it seems to have reached a point at which the NAS is finished listening or has performed whatever boot it was trying to perform.