Debian on Synology RS816 (Armada 385)

@bodhi

Quote

mdio@72004 {
pinctrl-names = "default";
pinctrl-0 = <&mdio_pins>;

phy0: ethernet-phy@0 {
reg = <0>;
};

phy1: ethernet-phy@1 {
reg = <1>;
};
};

On its own does not bring up eth1
The reg needs to be swapped as eth0 is now on Lan 2 was on Lan 1 easy to swap but thought I better mention in case it affects anything else.

EDIT
Correction to above eth0 flip flops between Lan1 and Lan2 between boots..... very weird.



Edited 1 time(s). Last edit at 05/23/2019 07:07PM by richjn.

KWBOOT
Just tried kwboot so I could send you the log and now it's back to xmodem error.

[richard@Linux RS816_FLASH]$ kwboot -a  -t -B 115200 /dev/ttyUSB0 -b mtd0.stock.rs816  -p
Sending boot message. Please reboot the target...-
Sending boot image...

BootROM - 1.73
 (Boot)
Booting from SPI flash


General initialization - Version: 1.0.0
AVS selection from EFUSE disabled (Skip reading EFUSE values)
Detected Device ID 6820
High speed PHY - Version: 2.0

Init Synology board board SerDes lanes topology details:
 | Lane # | Speed|    Type     |
 ------------------------------|
 |   0    |  0   |  SGMII0     |
 |   1    |  6   |  SATA0      |
 |   2    |  5   |  PCIe1      |
 |   3    |  0   |  SGMII2     |
 |   4    |  5   |  USB3 HOST0 |
 |   5    |  5   |  USB3 HOST1 |
 -------------------------------
High speed PHY - Ended Successfully
DDR3 Training Sequence - Ver TIP-1.46.0
WARNING:Wrong configuration for pup #1 CS mask and CS mirroring for all pups should be the same
WARNING:Wrong configuration for pup #3 CS mask and CS mirroring for all pups should be the same
DDR3 Training Sequence - Switching XBAR Window to FastPath Window 
DDR3 Training Sequence - Ended Successfully
Not detected suspend to RAM indication
  0 % [+xmodem: Protocol error

I didn't imagine it working yesterday!

There seems to be a timing issue in as much if I start kwboot then the NAS 1 second later the nas boots and ignores kwboot or the other way round. To get anything to happen I have to start both at the same moment maybe my successful run was just lucky timing although that doesn't feel right to me.

I have tried with and without the -a option for armada xp which I beleive is also for armada-38x

Away for 12 hours

@bodhi & @1000001101000

Thank you both for help

ip link

root@debian:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1024
    link/ether 00:50:43:1c:24:27 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1024
    link/ether 36:5a:4e:16:f5:97 brd ff:ff:ff:ff:ff:ff

We neded an ethernet@34000 section and it was reg 8

Working version v13 DTS attached

EDIT
My meeting got put back an hour but I am gone for 11 hours now.

EDIT 2
DO NOT USE it needs more work, I must stop trying to do stuff at last minute



Edited 2 time(s). Last edit at 05/23/2019 08:46PM by richjn.

Final armada-385-synology-rs816 DTS v14

Actually working and properly tested eth0 & eth1

@bodhi

Before I push this rs816 back to production for a second time did you want to explore trying to understand what's going on with kwboot or shall we park that one for now ? we will get a another chance when I do my other rs816.

Richard,

Run kwboot without -a option. That's for Armada XP.

Play with

-q <req-delay>: use specific request-delay
-s <resp-timeo>: use specific response-timeout

Nobody knows what the correct values are :) but start with some very small number such as 1 or 2.

If you are not suceesful, like after 30 attempts, then we should revisit later.

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

@bodhi

As suggested I tried a few times without hitting the 'magic' numbers I will park that for now.

The u-boot implementation on this box sucks, I could spend a few hours seeing if I can rebuild stock u-boot but although I'm up for the risks of bricking my own box I guess a guide that starts with the following may prove an unpopular one :)

Quote

Step 1: In order to have the ability to rescue your box, further into the process in the event something goes wrong, we will first risk bricking your box by installing a new u-boot with no chance of rescue if it goes wrong.......

Because of that possible reality do you feel I would be wasting my time trying this or that it just needs someone prepared to take the risk to trial (me) and thereafter the risk becomes 'acceptable' ?

Richard,

Don’t try to build or think of flashing uboot. kwboot has to work first.

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

@bodhi

Warning understood, I have no desire to brick one of my RS816's on a futile attempt but I am ok with a measured risk.

I had already taken a quick look at the u-boot-armada-2011.12 (latest Synology GPL on Sourceforge) which contains a build config for the RS815 the predecessor but very close relation to the RS816. The customization was fairly minimal beyond defining memory and SPI build config. I tried to build it "as is" but the build failed mainly, I believe, due to GCC 8 issues more than anything else.

I moved onto the latest released u-boot 2019.04 which contains a config for the DS414, this is a 4 bay box based on the Armada XP 2 core cpu. This built fine natively on the rs816 and leaves me wondering what would be different between the RS816 and the DS414 which would stop this u-boot from working. I do accept I have very little knowledge of u-boot but would there be much difference between a u-boot built with a Synology specific config and between two similar processors ?

Next I'm going to work my way backwards through kwboot versions and see if I get a different result with one back to circa 2013. If that works maybe trying the u-boot I've just built may seem viable.

Richard,

> I am ok with
> a measured risk.

Without successfully kwbooting the box, it is always very high risk, no other way around it :)

With the different u-boot on the same Kirkwood SoC, I'd test it by chainloading (running u-boot on top of another, but it has to be the same mainline version) to minimize the risk (if I don't have the boxes, and kwboot is not supported on that box).

> I had already taken a quick look at the
> u-boot-armada-2011.12 (latest Synology GPL on
> Sourceforge) which contains a build config for the
> RS815 the predecessor but very close relation to
> the RS816. The customization was fairly minimal
> beyond defining memory and SPI build config. I
> tried to build it "as is" but the build failed
> mainly, I believe, due to GCC 8 issues more than
> anything else.
>

I beleive I could build this easily (I have not tried though). I have a Linux VM just for building Armada u-boots already setup. I've rebuilt the Thecus N235 (Armada385) and Zyxel NAS326 (Armada 380) in the environment.


> I moved onto the latest released u-boot 2019.04
> which contains a config for the DS414, this is a 4
> bay box based on the Armada XP 2 core cpu. This
> built fine natively on the rs816 and leaves me
> wondering what would be different between the
> RS816 and the DS414 which would stop this u-boot
> from working.

> I do accept I have very little
> knowledge of u-boot but would there be much
> difference between a u-boot built with a Synology
> specific config and between two similar processors
> ?

Usually it will not work to use Armada XP on the Armada 38x. It would be OK for Armada 370. But once you can kwboot consistenly, the risk of bricking is close to nil.


> Next I'm going to work my way backwards through
> kwboot versions and see if I get a different
> result with one back to circa 2013. If that works
> maybe trying the u-boot I've just built may seem
> viable.

I've just rebuilt the attached kwboot for x86. See if you can start it. This vesion is about Nov 2018 master branch, meaning it it close to the Dec of 2018 release.

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



Edited 2 time(s). Last edit at 05/24/2019 09:57PM by bodhi.

@bodhi

>I beleive I could build this easily (I have not tried though).

If your vm is pre gcc-8 you probably can, I wasn't motivated enough to downgrade besides I wasn't sure how far I would have to go. I'm only going from memory but I think Synology are building with gcc-4.3

> Usually it will not work to use Armada XP on the Armada 38x.

Bummer, I guess that kills my idea dead in the water :(

> I've just rebuilt the attached kwboot for x86

Thanks for doing so, it runs no issue but the same outcome I'm afraid. I have rebuilt kwboot as far back as my gcc-9.1 environment will let (2018.01) no change in end result.

If you want a bit of think time for possible other routes I will hang on otherwise I'm going to push this box back to production. I still plan to convert my other rs816 so we will get a chance to retry stuff when I do.

Beyond that I think it may be shiraz O'clock time :)

Richard,

kwboot is another time consuming topic! Let’s try later when you start 2nd box. We can use that box to work out an installation procedure from stock OS (initial state). So be sure to let me know before you start.

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

@bodhi
Whilst waiting for Debian Buster to be released I have spent a bit more time looking at u-boot again. On closer inspection it transpires (I believe at the request of kernel devs) rather than continue the previous mvebu_armada-3xxx naming convention they have shifted to a soc naming convention and in our case the board identification db-88f6820-gp which covers the armada-38x range (there is also a stripped down board version db-88f6820-amc)

I went ahead and built it and am now wondering if the risk of installing has dropped to an acceptable level.
A number of binaries / configs were built as part of the process but I assume we are only interested in u-boot-spl.kwb

-rwxr-xr-x 1 root root 4.5M May 30 08:20 u-boot
-rw-r--r-- 1 root root 446K May 30 08:20 u-boot-dtb.bin
-rw-r--r-- 1 root root 446K May 30 08:21 u-boot-dtb.img
-rwxr-xr-x 1 root root 428K May 30 08:20 u-boot-nodtb.bin
-rw-r--r-- 1 root root 590K May 30 08:21 u-boot-spl.kwb
-rw-r--r-- 1 root root 446K May 30 08:20 u-boot.bin
-rw-r--r-- 1 root root  12K May 30 08:18 u-boot.cfg
-rw-r--r-- 1 root root 7.2K May 30 08:21 u-boot.cfg.configs
-rw-r--r-- 1 root root  19K May 30 08:21 u-boot.dtb
-rw-r--r-- 1 root root 446K May 30 08:21 u-boot.img
-rw-r--r-- 1 root root 1.7K May 30 08:20 u-boot.lds
-rw-r--r-- 1 root root 495K May 30 08:20 u-boot.map
-rwxr-xr-x 1 root root 1.2M May 30 08:20 u-boot.srec
-rw-r--r-- 1 root root 143K May 30 08:20 u-boot.sym

If I test it would be to the rs816 which has already been converted, I pushed this one into production as a outer firewall where the intention is to serve internet accessible content rather than forwarding those requests to internal servers as we currently do. The internal servers would then have their own non nat firewall. If something went wrong it would be quick and simple to swap the old firewall back in and we would still have the second rs816 to do the tutorial / push back into service as per the original.

I know the risks involved and am comfortable with them but does this still feel like its in the foolhardy category to you ?

Richard,

> they have shifted to a soc naming
> convention and in our case the board
> identification db-88f6820-gp which covers the
> armada-38x range (there is also a stripped down
> board version db-88f6820-amc)

No, that's not true. The naming convention that Marvell used was never accepted in mainline.

In mainline, when you see db-88F68xxxx, it means a reference board. When you see names like Seagate Dockstar or Marvell Dreamplug then they are specific boards for the same reference board for 88F6821. Or Solidrun Clearfog, then it is a specific board for 88F6820 (Armada 38x).


I have looked at and attempted to build u-boot for a38x and a37x. I'm ready now, after trying various things to figured out the new structure for Armada 38x and 37x u-boots. I'm procastinating to produce new u-boot for Armada mostly because of my dislike for the mainline code for this series.

Perhaps it will take a stronger motivation such as the Mirabox u-boot quirk that I have been trying to get through.


> I went ahead and built it and am now wondering if
> the risk of installing has dropped to an
> acceptable level.

Not even close to acceptable level.

> I know the risks involved and am comfortable with
> them but does this still feel like its in the
> foolhardy category to you ?

For a new box like this, if you cannot kwboot consistenly then my advice is: don't flash the binary.

Been there done that, and have bricked a few boxes :). Building u-boot is an entirely different beast from building kernel. You don't have a second chance to get it right, if you cannot do UART booting with kwboot.

If you are brave and flash it blindly, you will end up spending a lot of time trying to recover with kwboot, or JTAG.

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



Edited 1 time(s). Last edit at 05/30/2019 01:58AM by bodhi.

@bodhi

> If you are brave and flash it blindly, you will end up spending a lot of time trying to recover with kwboot, or > JTAG.

Curiosity had already go the better of me before I read your post and now I'm the proud owner of a shiny new brick :)

I would have been happier if it had worked but I was quite prepared for this to be the outcome. I have been looking at a few armada-38x specific kwboot patches and tried a couple already but no advancement yet.

Failing all else I do have some (very old on Xscale based PDA) experience with JTAG will go down that path as last resort.

Whether I'm brave or just dumb I will leave for others to judge for themselves :)

@bodhi
Just for something to do I tried sending my dud u-boot-spl.kwb via kwboot and to my surprise it started to transfer but then borked out at around 25% progress. I had to control-c to show the progress below because it just clears when it fails (no scroll back)

If it can send this kwb then maybe there was an issue with the mtd0 back up which affected previous attempts / something happened to it post my successful run. I will repeat the backup process you described before on the other box and see what happens.

[richard@Linux RS816_FLASH]$ kwboot -t -B 115200 /dev/ttyUSB0 -b u-boot-spl.kwb  -p
Sending boot message. Please reboot the target...-
Sending boot image...
  0 % [......................................................................]
  1 % [......................................................................]
  2 % [......................................................................]
  4 % [......................................................................]
  5 % [....................................................^C
[richard@Linux RS816_FLASH]$

EDIT:
No change

Create .kwb

dd if=/dev/mtd0 of=rs816.stock.uboot.kwb bs=896k conv=sync

Try to run it to bricked box

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

0 % [+xmodem: Operation canceled

Edited 1 time(s). Last edit at 05/30/2019 04:56AM by richjn.

Richard,

> Curiosity had already go the better of me before I
> read your post and now I'm the proud owner of a
> shiny new brick :)

That's OK. It happened to me with the first u-boot build, too :))

>
> I would have been happier if it had worked but I
> was quite prepared for this to be the outcome. I
> have been looking at a few armada-38x specific
> kwboot patches and tried a couple already but no
> advancement yet.
>
>
> Whether I'm brave or just dumb I will leave for
> others to judge for themselves :)

Brave, I'd say. You've missed my warning.

Let's revcover from it. No JTAG needed yet. We can try to solve UART booting.

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



Edited 2 time(s). Last edit at 05/30/2019 04:33PM by bodhi.

Richard,

> Just for something to do I tried sending my dud
> u-boot-spl.kwb via kwboot and to my surprise it
> started to transfer but then borked out at around
> 25% progress. I had to control-c to show the
> progress below because it just clears when it
> fails (no scroll back)

There is an explanation for this. SPL in mainline takes 160K size, so it stops at 25% is about right. That kwb is way too large (this is my dislike of the SPL, we don't really care, I could do without it any day).

The fact that it handshaked and started transfer was excellent. Meaning we can eventually kwboot this box. Let me post some suggestion to go forward in next post.

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

I'll be back tomorrow to discuss this further.

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

@bodhi

For no reason other than blind optimism I have tried to kwboot some of the targets under boards/Marvel with varying outcomes, I doubt any of this is useful info but thought I'd post it anyway.

db-88f6820-amc

[richard@Linux Temp]$ kwboot -t -B 115200 /dev/ttyUSB0 -b u-boot-spl.kwb -p
Sending boot message. Please reboot the target...-
Sending boot image...
  0 % [......................................................................]
  1 % [......................................................................]
  2 % [......................................................................]
  3 % [......................................................................]
  5 % [......................................................................]
  6 % [......................................................................]
  7 % [......................................................................]
  9 % [......................................................................]
 10 % [......................................................................]
 11 % [......................................................................]
 12 % [......................................................................]
 14 % [......................................................................]
 15 % [......................................................................]
 16 % [......................................................................]
 18 % [......................................................................]
 19 % [......................................................................]
 20 % [...............................
U-Boot SPL 2019.07-rc3 (May 31 2019 - 05:17:50 +0800)
High speed PHY - Version: 2.0
Detected Device ID 6820
board SerDes lanes topology details:
 | Lane #  | Speed |  Type       |
 --------------------------------
 |   0    |  5   |  PCIe0	|
 |   4    |  0   |  SGMII1	|
 |   5    |  0   |  SGMII2	|
 --------------------------------
PCIe, Idx 0: detected no link
High speed PHY - Ended Successfully
mv_ddr: mv_ddr-armada-18.09.2 
+xmodem: Protocol error

dreamplug
Took over 30 mins to load but got to 100% then without any other output

[Type Ctrl-\ + c to quit]

I tried just using kwboot as a console then turning the box on to see if the db-88f6820-gp I had flashed would show anything.

kwboot -t -B 115200 /dev/ttyUSB0

On most tries I just got garbage but on one occasion it booted as far as showing me the board config but just froze at that point, I'm kicking myself now but didn't capture the output and have not managed to get it to repeat.

Richard,

> [richard@Linux Temp]$ kwboot -t -B 115200
> /dev/ttyUSB0 -b u-boot-spl.kwb -p
> Sending boot message. Please reboot the
> target...-
> Sending boot image...
>   0 %
> [......................................................................]
>   1 %
...
...
>  20 % [...............................


> U-Boot SPL 2019.07-rc3 (May 31 2019 - 05:17:50
> +0800)
> High speed PHY - Version: 2.0
> Detected Device ID 6820
> board SerDes lanes topology details:
>  | Lane #  | Speed |  Type       |
>  --------------------------------
>  |   0    |  5   |  PCIe0	|
>  |   4    |  0   |  SGMII1	|
>  |   5    |  0   |  SGMII2	|
>  --------------------------------
> PCIe, Idx 0: detected no link
> High speed PHY - Ended Successfully
> mv_ddr: mv_ddr-armada-18.09.2

So far, that was the correct behavior since you are kwbooting the u-boot for a reference board in the same family 88f6820 . However, each board has a slightly different hw configuration. The bootROM did not see what it expects to see following the SPL, so it stops.

> dreamplug

No, Dreamplug would never work, because it is for 88f6281, like many other Kirkwood boards on this list.

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

@bodhi

>So far, that was the correct behavior
Understood, it was just that the db-88f6820-amc got that far whereas db-88f6820-gp errors straight out so was wondering if tweaking the config of db-88f6820-amc might get us somewhere...... but I do know I'm just stabbing away in the dark.

Richard,

Your best bet is to rebuild stock u-boot and kwboot that. I've downloaded the tarball, and will see if I can build it in my old VM.

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

@bodhi
I had tried to rebuild stock u-boot before which after a couple of simple things to fix eventually got stuck with gcc-8 based errors all over the place. At the time I wasn't motivated enough to downgrade to gcc-6 partially because I wasn't convinced that would be far enough. Marvel SDK for this board uses gcc-4.6.

Very much appreciate you having a go at compiling this yourself but please don't burn too much time on it. I will try with gcc-6 and if no go probably park this for now.

@bodhi
I didn't spend long looking but I can't immediately see a clean way of installing gcc-6 on Buster so rather than mess with an in-production server I will setup a Wheezy armhf vm which should be about the right vintage and see how that goes.

Richard,

> @bodhi
> I didn't spend long looking but I can't
> immediately see a clean way of installing gcc-6 on
> Buster

Too much works to do that.

> so rather than mess with an in-production
> server I will setup a Wheezy armhf vm which should
> be about the right vintage and see how that goes.

Yes. Wheezy uses gcc-4.6.

But most of the time, there is specific tool chain that Marvell uses to build these old uboots. If you dont see that setup in the tarball, then perhaps Synology build process is cleaner in that a mainline wheezy rootfs will be enough.

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

@bodhi

My vm is provided by Qemu which supports arm* but it didn't like the armhf Wheezy installer, rather than waste time I decided to download the i386 Wheezy installer with a view to cross compiling and because there are no active repos for this grabbed the entire 13GB 3 dvd set burnt them and carried out the install no problem, I actually did need some packages from dvd 2 and 3 so it all seemed worthwhile.

It was at this point I learnt lesson of the day which is RESEARCH FIRST, apparently there are no cross compile toolchains available for Wheezy (or at least I couldn't find any) The Embedian website states they got skipped due to manpower shortages, Squeeze and Jessie are supported but not Wheezy.

I may be able to use a Ubuntu toolchain but suspect I would have issues with glibc versions etc.

There will now be a short recess whilst I sulk and console myself with a glass or two of shiraz :)

Richard,

Which u-boot tarball you tried to compile?

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

@bodhi

THIS ONE

This is u-boot-armada-2011.12 which contains a Synology perl script (assumes you are cross compiling) to define your target; the target in our case is the rs815 which is a close relative of the rs816 but after my disastrous attempts maybe its not close enough. I think the main change was a bump in cpu speed from 1.33 to 1.8

EDIT
Just re-downloaded myself and notice "armada_xp_rs815" (in the build script) which hadn't registered with me last time I looked at it but I'm guessing this is now a dead end as well. I will see if I can find out the actual board used.

EDIT2
Yep, dead end

Marvell Armada XP MV78230 Dual Core 1.33

Edited 3 time(s). Last edit at 05/31/2019 02:17AM by richjn.