Debian Installation on Thecus N2350 (Marvell Armada 385)

Hi bodhi,

Thanks for clarifying that.

So i use the debian definition

mtdparts=armada-nand:-(ubifs);spi1.0:0x00400000(uboot),0x00010000@0x00100000(uboot_env),0x00010000@0x00300000(uboot_scr)

which leads:

$ cat /proc/mtd 
dev:    size   erasesize  name
mtd0: 20000000 00020000 "ubifs"
mtd1: 00400000 00001000 "uboot"
mtd2: 00010000 00001000 "uboot_env"
mtd3: 00010000 00001000 "uboot_scr"

First i was confused, because the erase size is different then in your post, but in you last post your debian result shows the same. So i will continue now.

Hi,

Here we go:

$ sudo nanddump --noecc --omitoob -f thecus_n2350.mtd0 /dev/mtd0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x20000000...

$ sudo dd if=/dev/mtd1 of=thecus_n2350.mtd1 bs=4096k conv=sync
1+0 records in
1+0 records out
4194304 bytes (4.2 MB, 4.0 MiB) copied, 7.02599 s, 597 kB/s

$ sudo dd if=/dev/mtd2 of=thecus_n2350.mtd2 bs=3072k conv=sync
0+1 records in
1+0 records out
3145728 bytes (3.1 MB, 3.0 MiB) copied, 0.135414 s, 23.2 MB/s

$ sudo flashcp -v u-boot-a38x-2015T1_p18_Thecus-tld-2-spi.bin  /dev/mtd1
Erasing blocks: 235/235 (100%)
Writing data: 937k/937k (100%)
Verifying data: 937k/937k (100%)

$ sudo ./thecus-n2350-boot-script-tld-3.sh 
boot_config=setenv devices "usb ide"; setenv bootdev usb; setenv device 0:1; setenv disks "0 1 2 3 4 5 6 7";
scan_disk=echo running scan_disk ...; scan_done=0; setenv scan_usb "usb start";  setenv scan_ide "ide reset"; 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 ext2load $dev $disknum:1 $load_image_addr /boot/zImage 1; then scan_done=1; echo Found bootable drive on $dev $disknum; setenv device $disknum:1; setenv bootdev $dev; fi; fi; done; fi; done
kernel_config=setenv load_dtb_addr 0x1000000; setenv load_initrd_addr 0x3000000; setenv load_image_addr 0x02000000; setenv dtb_file /boot/dts/armada-385-thecus-n2350.dtb
load_image=echo loading zImage ...; ext2load $bootdev $device $load_image_addr /boot/zImage
load_dtb=echo loading DTB $dtb_file ...; ext2load $bootdev $device $load_dtb_addr $dtb_file
load_initrd=echo loading uInitrd ...; ext2load $bootdev $device $load_initrd_addr /boot/uInitrd
set_bootargs=setenv bootargs "console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 mtdparts=armada-nand:-(ubifs);spi1.0:0x00400000(uboot),0x00010000@0x00100000(uboot_env),0x00010000@0x00300000(uboot_scr) earlyprintk=serial"
set_bootargs_stock=setenv bootargs "root=/dev/ram0 rw max_loop=210 console=ttyS0,115200 init=sbin/init rootdelay=3 ubi.mtd=0 mtdparts=armada-nand:-(ubifs);spi_flash:0x00400000(uboot),0x00010000@0x00100000(uboot_env)"
bootcmd_exec=echo Booting from $bootdev $device …; setenv fdt_skip_update yes; setenv initrd_high 0xffffffff; if run load_image; then; if run load_initrd; then if run load_dtb; then bootz $load_image_addr $load_initrd_addr $load_dtb_addr; else bootz $load_image_addr $load_initrd_addr; fi; else if run load_dtb; then bootz $load_image_addr - $load_dtb_addr; else bootz $load_image_addr; fi; fi; fi
bootcmd_custom=run boot_config; run kernel_config; run scan_disk; run set_bootargs; run bootcmd_exec
bootcmd=echo Booting Debian ...; run bootcmd_custom; echo Booting stock ...; run set_bootargs_stock; usb reset; if fatload usb 0:1 0x2000000 rescue_fw/rescue_fw.img;then imi 0x2000000;source 0x2000000; fi; ubi part ubifs;ubifsmount boot;ubifsload 0x2000000 boot/bzImage;ubifsload 0x3000000 boot/ramdisk;bootm 0x2000000 0x3000000

After that i rebooted and the system booted using my rescue_fw method. I have no serial connected at the moment. I can do that this evening and will try to remove the rescue_fw partition from my disk and use your boot method.
Thanks!
Manuel

Manuel,

> First i was confused, because the erase size is
> different then in your post, but in you last post
> your debian result shows the same. So i will
> continue now.

I see. It does make sense why you asked. There is a 4K sector capability and 64K capability for SPI flash. The latest Linux driver is 4K-sector capable. We care only about the mtd size in that it must be as stated to be flashed correctly.

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

> After that i rebooted and the system booted using
> my rescue_fw method. I have no serial connected at
> the moment. I can do that this evening and will
> try to remove the rescue_fw partition from my disk
> and use your boot method.
> Thanks!
> Manuel

Cool! it did boot is that we care about. We can refine the envs, as we go.

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

Hi bodhi,

I removed the rescue_fw partition from my disk, so the system/debian image is the first partition on it, and it booted without problems using your envs/custom uboot.
Great! :)
Cheers,
Manuel

lordzahl Wrote:
-------------------------------------------------------
> Hi bodhi,
>
> I removed the rescue_fw partition from my disk, so
> the system/debian image is the first partition on
> it, and it booted without problems using your
> envs/custom uboot.
> Great! :)
> Cheers,
> Manuel

Awesome!

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

Manuel,

UART booting is quite reliable now that I've figured out the quirk of this box during UART handshake.

When you run the script to download the image, if it seems to take too long (ie. the script reports that it got something, but then go on to wait for the next handshake opportunity, and again,...), just control-C, recall the command and execute it again. It will catch the NAK from the Thecus box right away. There is no need to wait a long time for it to occur!

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

Hi,

Yeah, good that you write that down here. I think i did it already like this, but i never reported it.
Sometimes one misses little stuff, which might be very important to others.
Cheers, Manuel

Manuel,

Right! Without being able to run UART booting consistently, I would not want to develop new uboot for this and other Armada boxes.

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

Manuel,

When you booted up the Thecus the first time, stock OS set the IP address to the default 192.168.1.100. That would be a problem for people with router 192.168.0.1.

Did Thecus provide a way to set it to 192.168.0.x subnet? I means some automatic way for normal users with Wifi (other than connecting an ethernet cable to your PC so you can run admin setup).

I usually go straight to serial consle to hack a box, so I have not looked into this.

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



Edited 1 time(s). Last edit at 05/25/2018 03:47AM by bodhi.

Hi bodhi,

I am not quite sure. The setup process is a little bit weird. For the initial configuration the box can not be reached through the browser at that ip. One has to use their mobile phone app or desktop (windows) program to setup the router. I think that it is not communicating at that point over tcp but maybe over udp. But i am not familiar with these basic levels of networking.
I can only say for sure, that at the initial state the router can e.g. not be pinged and only reached by thecus' apps.
Cheers, Manuel

Hi Manuel,

> For the initial configuration the box
> can not be reached through the browser at that ip.
> One has to use their mobile phone app or desktop
> (windows) program to setup the router.

Thanks! I can see this is necessary because stock OS does not use DHCP to get an address. What a crazy way to setup a NAS, unless they want to make sure the Thecus installation app will phone home when people set up the box :)

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

Hi Manuel,

Are you booting with SATA rootfs? could you refresh my memory if we have done this setup?

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

Hi Manuel,

I've fixed the problem in envs to boot with SATA rootfs. The command is scsi reset, not ide reset.

fw_setenv boot_config 'setenv devices "scsi usb"; setenv bootdev scsi; setenv device 0:1; setenv disks "0 1 2 3 4 5 6 7";'

fw_setenv scan_disk 'echo running scan_disk ...; scan_done=0; setenv scan_usb "usb start";  setenv scan_scsi "scsi reset"; 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 ext2load $dev $disknum:1 $load_image_addr /boot/zImage 1; then scan_done=1; echo Found bootable drive on $dev $disknum; setenv device $disknum:1; setenv bootdev $dev; fi; fi; done; fi; done'

Here is the boot log looks like

BootROM - 1.73
Booting from SPI flash


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

Init Customer board board SerDes lanes topology details:
 | Lane # | Speed|    Type     |
 ------------------------------|
 |   0    |  0   |  SGMII0     |
 |   1    |  3   |  SATA0      |
 |   2    |  3   |  SATA1      |
 |   4    |  5   |  USB3 HOST0 |
 |   5    |  5   |  USB3 HOST1 |
 -------------------------------
High speed PHY - Ended Successfully
DDR4 Training Sequence - Ver TIP-0.23.(Sublib 0.8)0
DDR4 Training Sequence - Switching XBAR Window to FastPath Window 
DDR4 Training Sequence - Ended Successfully
BootROM: Image checksum verification PASSED

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


U-Boot 2013.01 (May 12 2018 - 16:14:10) Marvell version: 2015_T1.0p18-tld-2

Board: A38x-Customer0-Thecus-N2350
SoC:   MV88F6820 Rev A0
       running 2 CPUs
CPU:   ARM Cortex A9 MPCore (Rev 1) LE
       CPU 0
       CPU    @ 1066 [MHz]
       L2     @ 800 [MHz]
       TClock @ 200 [MHz]
       DDR4    @ 800 [MHz]
       DDR4 32 Bit Width,FastPath Memory Access, DLB Enabled, ECC Disabled
DRAM:  1 GiB
NAND:  512 MiB
MMC:   mv_sdh: 0
SF: Detected MX25L3205D with page size 64 KiB, total 4 MiB
USB2.0 0: Host Mode
USB3.0 0: Host Mode
USB3.0 1: Host Mode

Map:   Code:			0x3fed4000:0x3ff95cfc
       BSS:			0x3ffef504
       Stack:			0x3f9c3f20
       Heap:			0x3f9c4000:0x3fed4000
       U-Boot Environment:	0x00100000:0x00110000 (SPI)

Board configuration detected:
Net:   
|  port  | Interface | PHY address  |
|--------|-----------|--------------|
| egiga0 |   SGMII   |     0x01     |
egiga0 [PRIME]
Hit any key to stop autoboot:  0 
Booting Debian ...
running scan_disk ...
Scan device scsi

Reset SCSI
AHCI init for unit0
Target spinup took 0 ms.
SATA link 1 timeout.

Error: SCSI Controller(s) 1B4B:9215 1B4B:9235 not found
scanning bus for devices...
  Device 0: (0:0) Vendor: ATA Prod.: ST750LX003-1AC15 Rev: SM12
            Type: Hard Disk
            Capacity: 715404.8 MB = 698.6 GB (1465149168 x 512)
Found 1 device(s).
device scsi 0:1
1 bytes read in 150 ms (0 Bytes/s)
Found bootable drive on scsi 0
Booting from scsi 0:1 …
loading zImage ...
4502408 bytes read in 601 ms (7.1 MiB/s)
loading uInitrd ...
8661185 bytes read in 437 ms (18.9 MiB/s)
loading DTB /boot/dts/armada-385-thecus-n2350.dtb ...
19574 bytes read in 121 ms (157.2 KiB/s)
## Loading init Ramdisk from Legacy Image at 03000000 ...
   Image Name:   initramfs-4.19.1-mvebu-tld-1
   Created:      2018-11-10   3:53:23 UTC
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    8661121 Bytes = 8.3 MiB
   Load Address: 00000000
   Entry Point:  00000000
## Flattened Device Tree blob at 01000000
   Booting using the fdt blob at 0x01000000
   Loading Device Tree to 00ff8000, end 00fffc75 ... OK

I'll post another script version soon.

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



Edited 1 time(s). Last edit at 11/10/2018 06:10PM by bodhi.

Hi bodhi!

First: Thanks for the newest kernel - it is already running on my box. I only need to reboot it for kernel updates - great.

> Are you booting with SATA rootfs? could you
> refresh my memory if we have done this setup?

I don't boot with SATA rootfs. I keep the SATA trays purely for data drives. My boot device is an old/small SSD in USB enclosure with a good chipset.
This works good for me and i don't intend to change it at the moment.
But its great you made the SATA rootfs boot to work. I guess that might be of use for you or others.

I am always on the look out for the bigger Thecus 4350 box with 4xSATA, if i ever see a (very) cheap one.
Sometimes the box is a little bit slow for all the services i run on it, but i think there is nothing better for this mixed server/NAS use case in the ARM/Marvell world than the 385? Is there?
Cheers,
Manuel

Manuel,

> I am always on the look out for the bigger Thecus
> 4350 box with 4xSATA, if i ever see a (very) cheap
> one.

That would be good to beef up your NAS services!


> Sometimes the box is a little bit slow for all the
> services i run on it, but i think there is nothing
> better for this mixed server/NAS use case in the
> ARM/Marvell world than the 385? Is there?

Yes. Other higher end Armada boxes. But those tend to be quite expensive comparing to these Thecus boxes (at least 3x). Thecus is the lowest cost/ performance among Armada boxes that I know of. So before the higher end Armada boxes coming down in prices, I would add another N2350 to your network to save money now.

My needs are OK with the mix of Marvell Kirkwood and Armada NAS farm I have for now. But always looking out for those more powerful Armada boxes :)

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

Hi Manuel,

I've been having intermittent problem with the Ethernet after a Cold Start.

Board: A38x-Customer0-Thecus-N2350
SoC:   MV88F6820 Rev A0
       running 2 CPUs
CPU:   ARM Cortex A9 MPCore (Rev 1) LE
       CPU 0
       CPU    @ 1066 [MHz]
       L2     @ 800 [MHz]
       TClock @ 200 [MHz]
       DDR4    @ 800 [MHz]
       DDR4 32 Bit Width,FastPath Memory Access, DLB Enabled, ECC Disabled
DRAM:  1 GiB
NAND:  512 MiB
MMC:   mv_sdh: 0
SF: Detected MX25L3205D with page size 64 KiB, total 4 MiB
USB2.0 0: Host Mode
USB3.0 0: Host Mode
USB3.0 1: Host Mode

Map:   Code:			0x3fed4000:0x3ff964f4
       BSS:			0x3ffeff24
       Stack:			0x3f9c3f20
       Heap:			0x3f9c4000:0x3fed4000
       U-Boot Environment:	0x00100000:0x00110000 (SPI)

Board configuration detected:
Port0: phyAddr=0x1, Not Marvell PHY id1 ffff id2 ffff
PHY error - shutdown port0
Net:   
|  port  | Interface | PHY address  |
|--------|-----------|--------------|
| egiga0 |   SGMII   |     0x01     |

Do you see it in your box?

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

Hi,

I need to attach to serial to see the uboot output, right? Or is it available in any log file?
I can try that maybe later today.
So after this you don't have ethernet?
I had no problem with my network connection at all.
Cheers

Hi Manuel,

> I need to attach to serial to see the uboot
> output, right? Or is it available in any log
> file?

Yes. You see it in serial only. It is way too early to have any log.


> I can try that maybe later today.
> So after this you don't have ethernet?
> I had no problem with my network connection at
> all.

I know :) I have been running OK, too. But after I played with u-boot netconsole, and while testing I realized that I could not connect, I've put serial wires back in and saw the error.

I think there might be a problem in hardware. This guy discovered "pin 27 and 39" were not connected:

http://forum.solid-run.com/linux-kernel-and-bootloaders-f34/u-boot-fails-to-detect-phy-on-a388-usom-2gb-board--t3356.html#p22482

Speculation:

If this is a hardware problem and why it has been working with old u-boot.

I think we might have been lucky that the memory region, where the PHY ID is, contains some dirty value :) So the PHY was detected. When I rebuilt u-boot with more code, I might have shifted the memory location, so it was now zero out the PHY ID. So it was not detected.

- If we look at the board with magnified glass, we might find the same missing connection for the loop back as "pani" discovered.
- So I think we might need to force u-boot PHY detection to be true with a valid Marvell ID to overcome the hardware problem (if indeed it is HW).
- Or we could poke GPIO 19 to fake the loop back signal (not sure).

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

Hi Manuel,

Quote

Speculation:

If this is a hardware problem and why it has been working with old u-boot.

I think we might have been lucky that the memory region, where the PHY ID is, contains some dirty value :) So the PHY was detected. When I rebuilt u-boot with more code, I might have shifted the memory location, so it was now zero out the PHY ID. So it was not detected.

It seems my speculation was somewhat close, but it was probably in the opposite :) that memory was probably not initialized correctly so any dirty values happen to be on it will screw up the ethernet PHY bring up.

I've unpluged the power cord overnight to let power charge drained. And now it boots up with ethernet OK.

U-Boot 2013.01 (May 12 2018 - 16:14:10) Marvell version: 2015_T1.0p18-tld-2

Board: A38x-Customer0-Thecus-N2350
SoC:   MV88F6820 Rev A0
       running 2 CPUs
CPU:   ARM Cortex A9 MPCore (Rev 1) LE
       CPU 0
       CPU    @ 1066 [MHz]
       L2     @ 800 [MHz]
       TClock @ 200 [MHz]
       DDR4    @ 800 [MHz]
       DDR4 32 Bit Width,FastPath Memory Access, DLB Enabled, ECC Disabled
DRAM:  1 GiB
NAND:  512 MiB
MMC:   mv_sdh: 0
SF: Detected MX25L3205D with page size 64 KiB, total 4 MiB
USB2.0 0: Host Mode
USB3.0 0: Host Mode
USB3.0 1: Host Mode

Map:   Code:			0x3fed4000:0x3ff95cfc
       BSS:			0x3ffef504
       Stack:			0x3f9c3f20
       Heap:			0x3f9c4000:0x3fed4000
       U-Boot Environment:	0x00100000:0x00110000 (SPI)

Board configuration detected:
Net:   
|  port  | Interface | PHY address  |
|--------|-----------|--------------|
| egiga0 |   SGMII   |     0x01     |
egiga0 [PRIME]
Hit any key to stop autoboot:  0

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

Hi,
Great that you have been able to figure it out. A hardware bug would have been bad news.
Cheers,
Manuel

Hi Manuel,

I've ported my netconsole patch to this stock u-boot. Run quite well so I will upload this new u-boot version later today.

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

Hi Manuel,

Here is Thecus N2350 uboot tld-4 version. This now has netconsole capability.

Download at Dropbox

thecus-n2350-Marvell-2015_T1.0p18-tld-4-bodhi.tar

md5sum
1a08b09b2e01824b47b525621fcc9944

sha256sum
8284087a4b3cde7db0b46e0942e985b7da6c52ccf65ee741fd4a2ceab5581ee9

There are 5 files in this tarball

Quote

u-boot-a38x-2015T1_p18_Thecus-tld-4-spi-uart.bin
u-boot-a38x-2015T1_p18_Thecus-tld-4-spi.bin
download-serial.sh
send-stop-pattern
send-stop-pattern.c

I will update this tarball to include a README file later. Will update this post when I do that.

In the meantime, you can test this new u-boot with UART using download-serial.sh. I've included the binary version of send-stop-pattern in here so download-serial.sh can run faster (not having to compile the send-stop-pattern.c file each time) .

Note:

If you are going to run netconsole server from the same box you have serial console, then you will need 2 terminals (one for serial, one for netconsole nc) in order to see all output and able to interact with netconsole. If you don't connect serial console then just 1 terminal.

If your Thecus IP is 192.168.0.254, and you netconsole server IP is 192.168.0.253,

Thecus: set these envs

serverip=192.168.0.253
if_netconsole=ping $serverip
preboot_nc=setenv nc_ready 0; for pingstat in 1 2 3 4 5; do; sleep 1; if run if_netconsole; then setenv nc_ready 1; fi; done; if test $nc_ready -eq 1; then run start_netconsole; fi
start_netconsole=setenv ncip $serverip; setenv bootdelay 10; setenv stdin nc; setenv stdout nc; setenv stderr nc; version;
preboot=run preboot_nc

netconsole server starts

nc -lup 6666 192.168.0.254 6666

Netconsole terminal after it was established connection:

U-Boot 2013.01 (Nov 12 2018 - 20:56:19) Marvell version: 2015_T1.0p18-tld-4
arm-linux-gnueabi-gcc (Linaro GCC 4.9-2017.01) 4.9.4
GNU ld (Linaro_Binutils-2017.01) 2.24.0.20141017 Linaro 2014_11-3-git
Hit any key to stop autoboot:  0

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



Edited 3 time(s). Last edit at 11/15/2018 05:04AM by bodhi.

Hi Manuel,

I think I need to investigate this Network issue further in u-boot.

I had a brief power outage yesterday, and the PHY problem surfaces again when I power up the Thecus.

And unplugged the power cord for about 5 minutes has cleared up the problem too. The same pattern :)

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



Edited 1 time(s). Last edit at 11/22/2018 06:51PM by bodhi.

Hi bodhi,

Netconsole sounds great. I probably won't flash it soon, but it may come in handy.
Hm, maybe some part of the memory is written, which needs to be zero when initializing the PHY?
So it should be properly initialized, but it isn't. And removing power kind of initializes it?
Well, but this theory does not really help with anything..
Cheers, Manuel

Manuel,

I think this u-boot might have written over the memory area, and also other race condition code might have something to do with it.

For example, a busy loop like this. Instead, what should have been done here is a sleep period that specifies exactly how long the wait is to make sure the registers have data available. Code like below would never be accepted in mainline u-boot.

/* Wait for the data to update in the SMI register */
        			for (timeout = 0; timeout < ETH_PHY_TIMEOUT; timeout++)
                			;

And also, a failure condition for an important component like Ethernet should be retried many times before it gives up. In modern u-boot, the Ethernet PHY initialization takes a long time before it is declared a failure.

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

FYI,

For the Thecus N2350, this is the envs adjustment to boot with kernel linux-5.2.9-mvebu-tld-1

load_image=echo loading uImage ...; ext2load $bootdev $device $load_image_addr /boot/uImage
bootcmd_exec=echo Booting from $bootdev $device …; setenv fdt_skip_update yes; setenv initrd_high 0xffffffff; if run load_image; then if run load_initrd; then bootm $load_image_addr $load_initrd_addr; else bootm $load_image_addr; fi; fi

The uImage needs to be one with DTB embbeded in it.

cd /boot
cp -a zImage-5.2.9-mvebu-tld-1 zImage.fdt
cat dts/armada-385-thecus-n2350.dtb >> zImage.fdt 
mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-5.2.9-mvebu-tld-1 -d zImage.fdt uImage

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



Edited 1 time(s). Last edit at 08/25/2019 03:07PM by bodhi.

Hi bodhi,

Thanks for the Update. I upgraded to your Kernel 5.2.9 and also updated the envs.
I also upgraded to Debian Buster and got the MAC address problem, which has been described in another thread. I just hardcoded the address now.

Otherwise everything works fine. Thanks again!
Cheers, Manuel

Hi Manuel,

> I also upgraded to Debian Buster

Cool!

> and got the MAC
> address problem, which has been described in
> another thread. I just hardcoded the address now.

But the MAC address problem does not show up on my Thecus N2350 :). I have not posted this info because I wanted to track it down on the NAS326.

However, let's compare the system info on our boxes.

Thecus N2350
Linux version 5.2.9-mvebu-tld-1 (root@tldDebianVM) (gcc version 7.4.0 (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04.1)) #1 SMP PREEMPT Mon Aug 19 12:47:39 PDT 2019
Debian 10.0
console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 mtdparts=pxa3xx_nand-0:-(ubifs);spi1.0:0x00400000(uboot),0x00010000@0x00100000(uboot_env),0x00010000@0x00300000(uboot_scr) earlyprintk=serial
uboot_version=U-Boot 2013.01 (Nov 12 2018 - 20:56:19) Marvell version: 2015_T1.0p18-tld-4

root@tldDebian:~# dpkg -l | grep udev

ii  libgudev-1.0-0:armel                   232-2                         armel        GObject-based wrapper library for libudev
ii  libudev0:armel                         175-7.2                       armel        libudev shared library
ii  libudev1:armel                         241-5                         armel        libudev shared library
ii  udev                                   241-5                         armel        /dev/ and hotplug management daemon

root@tldDebian:~# dmesg | grep -i mac

[    0.000000] OF: fdt: Machine model: Thecus N2350
[    4.172727] mvneta f1070000.ethernet eth0: Using hardware mac address 00:14:xx:xx:xx:xx
[   25.068216] systemd-udevd[1790]: Could not generate persistent MAC address for ip6tnl0: No such file or directory

Note that ipv6 error is not relevant.

root@tldDebian:~# sysctl -a | grep ipv6 | grep disable

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.all.disable_policy = 0
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.default.disable_policy = 0
net.ipv6.conf.eth0.disable_ipv6 = 1
net.ipv6.conf.eth0.disable_policy = 0
net.ipv6.conf.ip6tnl0.disable_ipv6 = 1
net.ipv6.conf.ip6tnl0.disable_policy = 0
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.conf.lo.disable_policy = 0
net.ipv6.conf.sit0.disable_ipv6 = 1
net.ipv6.conf.sit0.disable_policy = 0

I got to the point where I think u-boot version seems to be the only difference. But I need to lok at the DTS to see there is difference between the N2350 and NAS326, regarding ethernet.

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

Hi bodhi,

Quote
bodhi
However, let's compare the system info on our boxes.

How did you get that information?

mjung@vega:~$ dpkg -l | grep udev
ii  libgudev-1.0-0:armhf                 232-2                           armhf        GObject-based wrapper library for libudev
ii  libinput-bin                         1.12.6-2                        armhf        input device management and event handling library - udev quirks
ii  libudev1:armhf                       241-5                           armhf        libudev shared library
ii  udev                                 241-5                           armhf        /dev/ and hotplug management daemon

mjung@vega:~$ dmesg | grep -i mac 
[    0.000000] OF: fdt: Machine model: Thecus N2350
[    4.119846] mvneta f1070000.ethernet eth0: Using random mac address 7e:ee:ba:fa:20:8b
[   17.225243] systemd[1]: systemd 241 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid)

mjung@vega:~$ sudo sysctl -a | grep ipv6 | grep disable 
net.ipv6.conf.all.disable_ipv6 = 0
net.ipv6.conf.all.disable_policy = 0
net.ipv6.conf.default.disable_ipv6 = 0
net.ipv6.conf.default.disable_policy = 0
net.ipv6.conf.eth0.disable_ipv6 = 0
net.ipv6.conf.eth0.disable_policy = 0
net.ipv6.conf.ip6tnl0.disable_ipv6 = 0
net.ipv6.conf.ip6tnl0.disable_policy = 0
net.ipv6.conf.lo.disable_ipv6 = 0
net.ipv6.conf.lo.disable_policy = 0
net.ipv6.conf.sit0.disable_ipv6 = 0
net.ipv6.conf.sit0.disable_policy = 0

I think it might be possible that i had the problem with random MAC addresses also before the upgrade, but i did not keep the customized hard coded MAC address in the config file, but chose the new one from the package maintainer - not sure about that.

Cheers, Manuel