Debian on Zyxel NAS326

Here is the modified DTS that compiled with kernel 4.9.x (DTSI changes in mainline 4.9 that resulted in compilation error in hean01/rr4m version of the DTS).

However, I have not tried to run this.

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



Edited 2 time(s). Last edit at 01/07/2017 06:13AM by bodhi.

Confirm, kernels 4.9.1 and 4.10-rc2 have an updated /arch/arm/boot/dts/armada-38x.dtsi file. Compared to 4.8.15 (and older), spi0 { ... }; and spi1 { ... }; peripheral now declared outside of internal-regs { ... }; section. Seems they try to make flattened device tree a bit more flat :)

Havent tried to build and run this yet, but should work IMO. Thanks to bodhi!

A few things.

1. The current patch has the USB and HDD power patched code, but it should be temporary.

Update: strike this "This is a proper u-boot function so if u-boot works correctly, there is no need to patch the kernel to do it" :-) I've misspoke here. Ignore what I said in this senstence. I was thinking of MAC address.

2. There is some information missing in the Armada 380 Functional Specs (FS). The Armada 370 FS contains all needed information, but the 380 does not. Especially about the boot sequence description which is very brief in the 380 spec. This document is from the webform link rr4m posted previously. I hoped to find out more about if there is any differences between the 370 vs 380 boot sequence, but the only available info right now is from the 370 FS and HW specs.

3. I'm guessing the serial output was dropped somewhere along the line when we run kwboot. The NAK that should come from the bootROM during power up did not arrive to the serial converter end for kwboot to start sending image. In my run I lost more characters:

Mine:

M - 1.73
Booting from NAND flashl

Kirsch's output on 2nd converter

BootROM - 1.73
Booting from NAND Flash

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



Edited 1 time(s). Last edit at 01/13/2017 04:45AM by bodhi.

Ok, found a minute to give kwboot a try, my steps:

1. Downloaded kwboot-tool.tar.gz x86_64 binary
2. Downloaded bodhi's u-boot-a38x-STG-328_2014_T3p6-nand-uart.bin
3. Setup Ubuntu 16.04.1 (virtualbox), connected FTDI232R UART to NAS326 and my linux, it detects as /dev/ttyUSB0, screen works, minicom works - no probs
4. Checking setup

root@16041:~/kwboot-tool# uname -a
Linux 16041 4.4.0-57-generic #78-Ubuntu SMP Fri Dec 9 23:50:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

root@16041:~/kwboot-tool# lsusb
Bus 001 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC

root@16041:~/kwboot-tool# ./kwboot 
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

5. Trying to upload a binary - long wait, no response. Killed with ^C. The way I did it - power off NAS, launch kwboot, power on NAS (kwboot tries to do something, rotates status, but no luck - just hangs finally).

root@16041:~/kwboot-tool# ./kwboot  -t -B 115200 /dev/ttyUSB0 -b ../u-boot-a38x-STG-328_2014_T3p6-nand-uart.bin 
Sending boot message. Please reboot the target...\^C

root@16041:~/kwboot-tool# ./kwboot  -B 115200 /dev/ttyUSB0 -b ../u-boot-a38x-STG-328_2014_T3p6-nand-uart.bin 
Sending boot message. Please reboot the target...\^C

6. kwboot mini terminal works without any problem (just like minicom and screen)

root@16041:~/kwboot-tool# ./kwboot  -t -B 115200 /dev/ttyUSB0
[Type Ctrl-\ + c to quit]
@
BootROM - 1.73
Booting from NAND flash

General initialization - Version: 1.0.0
Detected Device ID 6810
High speed PHY - Version: 2.0
...
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
...
Hit any key to stop autoboot:  2 
Marvell>>

7. Very first symbols u-boot sends before "BootROM - 1.73" differ. After plugging power to NAS326 I saw at least:

@
BootROM - 1.73

???-
BootROM - 1.73

?-
BootROM - 1.73

?
BootROM - 1.73

or just
BootROM - 1.73

So, no luck booting via kwboot so far. Seems we're missing something.

---

Quote
bodhi
1. The current patch has the USB and HDD power patched code, but it should be temporary. This is a proper u-boot function so if u-boot works correctly, there is no need to patch the kernel to do it.

Also, MAC address can be set up via u-boot live DTB patching (fdt set command) [1] [2]. But not critical IMO.

rr4m,

>
> root@16041:~/kwboot-tool# ./kwboot
> 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
>

BTW, this the old version, I'm using a newer one. I'll include the latest x86 version in the u-boot thread in the next few days.

> 7. Very first symbols u-boot sends before "BootROM
> - 1.73" differ. After plugging power to NAS326 I
> saw at least:
>

> @
> BootROM - 1.73
> 
> ???-
> BootROM - 1.73
> 
> ?-
> BootROM - 1.73
> 
> ?
> BootROM - 1.73
> 
> or just
> BootROM - 1.73
>

>

Interesting! that's in line of what I suspected. Zyxel board might have some problem with this. My kwboot never catched a NAK from the serial line.

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

bodhi,

I think those @, ???, ?- are just voltage spikes on TX line when I plug in power, 95% sure they're not generated by board (because each time they're different or just absent). I even saw once:

root@16041:~# ./kwboot.my -t /dev/ttyUSB0
[Type Ctrl-\ + c to quit]
??????????<?%??????????
BootROM - 1.73
Booting from NAND flash

Note regarding NAK. As far as I understand from docs, it works differently. Marvell chip on early boot initializes UART and listens for a 'magic' packet quietly. If there were so such packets - it boots from NAND or SPI (and prints BootROM - 1.73 Booting from NAND flash). So it simply listens. If magic packet arrives - then cpu replies and starts xmodem receive (uart boot).

Kwboot on the other hand sends magic packets one after another with a little delay and waits if remote board responds it's ready for xmodem xfer. What exactly kwboot sends? I suppose Kirsch posted those chunks:

Marvell>> ▒"3DUfw▒"3DUf""3DUfw▒"3DUfw▒"

Quote
bodhi
BTW, this the old version

Agree, kwboot I tried is rather old. If you have something fresher - let's give it a try!

rr4m,

> Note regarding NAK. As far as I understand from
> docs, it works differently. Marvell chip on early
> boot initializes UART and listens for a
> 'magic' packet quietly. If there were so such
> packets - it boots from NAND or SPI (and prints
> BootROM - 1.73 Booting from NAND flash). So
> it simply listens. If magic packet arrives - then
> cpu replies and starts xmodem receive (uart

The "magic packet" is simply the 1st byte of the boot message that Marvell chip expects. But Xmodem protocol starts data transfer after receiving a NAK. This is a standard behavior because kwboot has no way of knowing it the bootROM has received the boot message.

But this conversation triggered another thought that I might try to patch kwboot to see what else it received, if at all.

Update:

I think I can explain it a little better than I did above :) the NAK suppose to be sent by bootROM after it has received the boot message (the magic packets).

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



Edited 3 time(s). Last edit at 01/09/2017 12:31AM by bodhi.

rr4m,

Do you have an ARM box beside this NAS326? if you do, use the latest kwboot I've posted in the u-boot thread.

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

All,

I need this data point. When you run kwboot and eventually it is timed out by the NAS326 and it starts booting its own stock u-boot, how long is that T period?

T1:
kwboot ....

....

BootROM 1.73
T2:

T = T2 - T1

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



Edited 1 time(s). Last edit at 01/09/2017 12:39AM by bodhi.

Quote
bodhi
Do you have an ARM box beside this NAS326?

Nope, just that ZyXEL. +Arduinos for small projects.

Quote
bodhi
When you run kwboot and eventually it is timed out by the NAS326 and it starts booting its own stock u-boot, how long is that T period?

I'd say it's instant. Either I just power-on NAS326 or I run kwboot, then power-on NAS326 - it boots instantly. When I saw the longest chars sequence before 'Bootrom 1.73' - may be it was 1 second (probably I was plugging power jack too long?)

root@16041:~# ./kwboot.my -t /dev/ttyUSB0
[Type Ctrl-\ + c to quit]
??????????<?%??????????   <--- printed in about a second
BootROM - 1.73
Booting from NAND flash

BTW, it's possible to open 2 terminal windows at once - one with 'kwboot -b uboot.bin' + other with 'mincom' to see what's going on and how quick NAS responds. But output in minicom is flooded with '▒"3DUfw▒"3DUf""3DUfw▒' messages

1. # ./kwboot.my -t /dev/ttyUSB0 -b u-boot.bin

2. # minicom OR screen OR ./kwboot.my -t /dev/ttyUSB0

I experimented a bit more - but still no luck (tried to set a jumper near uart port on main board, looked for another uart1 - not found, tried to count 1000-2000-3000 before running kwboot - still nothing). Keeping stock u-boot for now - in any case it does it's job and auto-boots my kernel and Ubuntu :)

rr4m Wrote:
-------------------------------------------------------
>

Quote
bodhi
> Do you have an ARM box beside this NAS326?
>

>
> Nope, just that ZyXEL. +Arduinos for small
> projects.
>
>

Quote
bodhi
> When you run kwboot and eventually it is timed out
> by the NAS326 and it starts booting its own stock
> u-boot, how long is that T period?
>

>
> I'd say it's instant. Either I just power-on
> NAS326 or I run kwboot, then power-on NAS326 - it
> boots instantly. When I saw the longest chars
> sequence before 'Bootrom 1.73' - may be it was 1
> second (probably I was plugging power jack too
> long?)
>

This is good info. It is *not* consistent with my box.


>

> root@16041:~# ./kwboot.my -t /dev/ttyUSB0
> [Type Ctrl-\ + c to quit]
> ??????????<?%??????????   <--- printed in about a
> second
> BootROM - 1.73
> Booting from NAND flash
>

>
> BTW, it's possible to open 2 terminal windows at
> once - one with 'kwboot -b uboot.bin' + other with
> 'mincom' to see what's going on and how quick NAS
> responds. But output in minicom is flooded with
> '▒"3DUfw▒"3DUf""3DUfw▒' messages
>
> 1. # ./kwboot.my -t /dev/ttyUSB0 -b u-boot.bin
>
> 2. # minicom OR screen OR ./kwboot.my -t
> /dev/ttyUSB0
>
> I experimented a bit more - but still no luck
> (tried to set a jumper near uart port on main
> board, looked for another uart1 - not found, tried
> to count 1000-2000-3000 before running kwboot -
> still nothing). Keeping stock u-boot for now - in
> any case it does it's job and auto-boots my kernel
> and Ubuntu :)

Fair enough! hean01 and you have done a lot of good works on the kernel side. I will take my time to do some more code reading.

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

Here is how to boot with separate DTB (uImage or zImage).

This Marvell stock u-boot will mess up the DTB really bad before starting the kernel. That's the reason it you use separate DTB and see really weird errors and inconsistency in kernel booting. It will try to update the DTB, if we don't tell it not to do it.

Set this env permanenly either in serial console for with fw_setenv:

setenv fdt_skip_update yes

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

@Kirsch and sebr,

It is still a work in progress, i.e. a lot more works to be done to run this box correctly, but I have built a working rootfs with kernel 4.9 for this box. Would you like to test run it?

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

Quote

unrecognized JEDEC id bytes: ff, ff, ff

This problem indicates SPI flash has not been initialized (no power). Stock u-boot did not bring up SPI. And stock "sf probe" does not work either. So my guess is stock u-boot has this bug, Because it should work for this a38x SoC.

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

hean01,

The memory poke does not look correct.

USB power is GPIO 11. If HDD power is GPIO 13 then in the post above:
http://forum.doozan.com/read.php?2,27108,30689#msg-30689

The HDD GPIO must be 2 position right next to it.

Like what musv said:
http://forum.doozan.com/read.php?2,27108,30688#msg-30688

Does the 2nd poke also activate Ethernet?

BTW, in your previous post, the output also not correct. It should be:

Marvell>> md.l f1018100 1
f1018100: 04200000    .. .

Marvell>> md.l f1018140 1
f1018140: 003c8000    ..<.

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



Edited 1 time(s). Last edit at 01/15/2017 04:18PM by bodhi.

Quote
myself
> unrecognized JEDEC id bytes: ff, ff,
> ff
>
> This problem indicates SPI flash has not been
> initialized (no power). Stock u-boot did not bring
> up SPI. And stock "sf probe" does not work either.
> So my guess is stock u-boot has this bug, Because
> it should work for this a38x SoC.

FYI, this was because Zyxel intentionally excluded SPI in stock u-boot build.

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

Hi rr4m,

Can you point me to where in the 370 reference manual you've found GPIO 11 for USB? It seems I lack some files, or something is missing in my copies of the 370 FS and HW specs (I downloaded these long ago when they became public).

Thanks!

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

Hey bodhi!

GPIO1 PIN 11 (or MPP43) controls USB power - it was found experimentally. As I wrote in my comment, GPIO address space on Armada 37x/38x is different from Kirkwood - and these GPIO addresses are declared in ARMADA370-FunctionalSpec-datasheet, page 1067

GPIO0 - f1018100
GPIO1 - f1018140

So, I sat down and started writing 0 and 1 to every general purpose in/out pin (using mw.l command in u-boot) - there are pins, controlling White and Red leds on the front panel, there are pins, controlling leds blink mode. After 10 minutes of poking I found that MPP43 enables usb power. Marvell's docs doesn't declare or restrict vendor to use MPP43 for that. Simply board vendor (ZyXEL or probably MitraStar Technology Corp made NAS326 motherboard for ZyXEL?) decided to put USB power (MPP43) and HDD's power (MPP29, MPP45) on these multi-purpose pins.

It's also can be found inside kernel 3.10.39 source from ZyXEL - but when I experimented I had no sources yet (arch/arm/boot/compressed/misc.c):

#define GPIO_POWER_ON_HDD1                                     45
#define GPIO_POWER_ON_HDD2                                     29
#define GPIO_POWER_ON_USB                                      43

Hi rr4m,

I've just found that in the GPL :) but appreciated for your response! The reference manual format has been overhauled by Marvell since the Armada releases. They stopped making it as helpful as the Kirkwood series (6281).

Yes, this is usually the case. Marvell MPP pins are quite flexible. Those unused GPIOs can be defined as anything by the board manufacterer.

That approach of poking each of the GPIOs is also a ritual for me whenever I developed a new u-boot :)

Since I got stuck on kwboot booting, I've switched gear and work on the kernel instead. So pretty soon I hope to release a Debian rootfs for this box.

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

Great! BTW - kernel. Recently I turned my NAS into openvpn client/server (with routing features). And found that our kernel config was lacking a lot of features (TUN/TAP was disabled, all netfilter stuff too) - so I recompiled that again, now sitting on patched 4.9.2. If anyone needs a kernel with tun/tap/iptables enabled - let me know, I'll share it (1 week uptime, no glitches so far).



Edited 1 time(s). Last edit at 01/16/2017 04:39AM by rr4m.

I have a NAS326 runnig Debian Stretch for about 2 weeks now without downtime or any other issues.
The system is based on a rootfs I had from another armhf box and is based in your 4.8 kernel in nand.

I got the 38x functional specification some of you seem to be looking for from here:
https://marvellcorp.wufoo.com/forms/marvell-armada-38x-functional-specifications/

I want to add these GPIOs to your collection:
20 poweroff system
53 hdd2 led white
54 hdd2 led red

rr4m, can you share your GPIO findings?

Quote
kralan
I want to add these GPIOs to your collection:
20 poweroff system
53 hdd2 led white
54 hdd2 led red
rr4m, can you share your GPIO findings?

Okay, here it comes, NAS326 leds and pins:

First we look at ARMADA370-FunctionalSpec-datasheet, page 1067, which says:

DataOut Register
GPIO_Num0: 0x00018100
GPIO_Num1: 0x00018140

Data Out Enable Control Register
GPIO_Num0: 0x00018104
GPIO_Num1: 0x00018144

Blink Enable Register
GPIO_Num0: 0x00018108
GPIO_Num1: 0x00018148

Let's read default values (3 groups, 4 bytes each)

Marvell>> md.l f1018100 3
f1018100: 04200000   0007f001          00000000
GPIO0     data-out   data-out-enable   blink-enable

Marvell>> md.l f1018140 3
f1018140: 003c8000   04024280          00000000
GPIO1     data-out   data-out-enable   blink-enable

Let's find out which pins configured as INPUTS (1) and OUTPUTS (0) - second group of 4 bytes will tell us that:

GPIO0 - 0007f001 = b0000 0000 0000 0111 1111 0000 0000 0001
                   31                  15                 0

GPIO1 - 04024280 = b0000 0100 0000 0010 0100 0010 1000 0000
                   31                  15                 0

Or translating this into human language:
GPIO0 pins 0, 12-18 are inputs (1)
GPIO1 pins 7, 9, 14, 17, 26 are inputs (1)

All the rest pins are configured as outputs (0):
GPIO0 pin1-pin11, pin19-pin31
GPIO1 pin0-pin6, pin8, pin10-pin13, pin15, pin16, pin18-pin25, pin27-pin31

Or translating that into flat numeration (multi-purpose pins 0-63), we have outputs at:
MPP1-MPP11, MPP19-MPP31
MPP32-MPP38, MPP40, MPP42-MPP45, MPP47, MPP48, MPP50-MPP57, MPP59-MPP63

May be my method of separating INPUTS from OUTPUST is wrong. Have no ARM programming background - so it's just my opinion.

MPP19 - quiet buzzer sound (do in u-boot 'mw.l f1018100 04280000', then 'mw.l f1018100 04200000' to hear it)
MPP20 - power off (u-boot command 'mw.l f1018100 04300000' shuts the box down)
MPP21 - USB WHITE LED ('mw.l f1018100 04000000' - off, 'mw.l f1018100 04200000' - on)
MPP26 - BOTTOM WHITE LED - aka COPY WHITE LED ('mw.l f1018100 00000000' - off, 'mw.l f1018100 04000000' - on)
MPP29 - POWER_ON_HDD2 (mw.l f1018100 24200000)
---
MPP37 - BOTTOM RED LED - aka COPY RED LED ('mw.l f1018140 003c8000' - off, 'mw.l f1018140 003c8020' - on)
MPP43 - POWER_ON_USB ('mw.l f1018140 003c8800', then 'usb reset')
MPP45 - POWER_ON_HDD1 ('mw.l f1018140 003ca000')
MPP48 - HDD1 RED LED ('mw.l f1018140 003c8000' - off, 'mw.l f1018140 003d8000' - on)
MPP50 - HDD1 WHITE LED ('mw.l f1018140 003c8000' - on, 'mw.l f1018140 00388000' - off)
MPP52 - TOP WHITE LED - aka SYSTEM WHITE LED ('mw.l f1018140 003c8000' - on, 'mw.l f1018140 002c8000' - off)
MPP53 - HDD2 WHITE LED ('mw.l f1018140 003c8000' - on, 'mw.l f1018140 001c8000' - off)
MPP54 - HDD2 RED LED ('mw.l f1018140 007c8000' - on, 'mw.l f1018140 003c8000' - off)
MPP55 - TOP RED LED - aka SYSTEM RED LED ('mw.l f1018140 00bc8000' - on, 'mw.l f1018140 003c8000' - off)

All leds off;

mw.l f1018100 0
mw.l f1018140 0

Blink USB WHITE LED:

turn it on: mw.l f1018100 00200000
blink mode on: mw.l f1018108 00200000
blink mode off: mw.l f1018108 00000000

Blink TOP RED LED (aka SYSTEM RED LED):

turn it on: mw.l f1018140 00800000
blink on: mw.l f1018148 00800000
blink off: mw.l f1018148 00000000

Turn off fan (I dunno how it works, but it works :)))

mw.l f1018140 0
mw.l f1018100 ffefffff

Front 'Power' button and 'Copy' button must be sitting on some inputs. That's all I know for today.



Edited 4 time(s). Last edit at 01/18/2017 03:43PM by rr4m.

rr4m,

You are the hardcore tinker :) I've also found most of the needed GPIOs, but some are still unknown to me (perhaps they are on the list above). I'll see if I can reconcile my list with yours.

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

POWER button 46
RESET button 49
COPY button 39

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

bodhi,

Ha-ha :) Exactly as expected - those 3 pins are in my INPUTS list. What's left - a proper DTS device tree config.

rr4m Wrote:
-------------------------------------------------------
> bodhi,
>
> Ha-ha :) Exactly as expected - those 3 pins are in
> my INPUTS list. What's left - a proper DTS device
> tree config.

It is coming! I'll post a test version.

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

Bodhi:
Thanks for the modified dts file for 4.9.

I've created a release thread for this kernel:

http://forum.doozan.com/read.php?2,32146,32146#msg-32146

Please see the DTS source file attached in the 1st post of that thread.

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

This DTS is pretty close to compete: all the USB/HDD power, LED triggers, Buttons, and Power Off should work.

When you build kernel with this DTS, tatke out the misc.c code patch that powers up the USB and HDD, it is no longer necessary.

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



Edited 1 time(s). Last edit at 01/19/2017 03:47AM by bodhi.

Found an error :)

		red_sata1 {
			label = "nsa326:white:sata1";
			gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>;
                        linux,default-trigger = "ide-disk1";
		};

should be

                red_sata1 {
			label = "nsa326:red:sata1";
			gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>;
		};

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



Edited 1 time(s). Last edit at 01/20/2017 03:53AM by bodhi.