(WIP) Linux Kernel and rootfs 4.14.24 for Seagate Business Storage NAS (CNS3xxx) package

Thanks luke, have been busy so I will take a look later.

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

Thanks to bodhi and luke. I can boot and login a debian squeeze rootfs through serial console.
The sata drive is working fine, but Ethernet and usb doesn't working yet.
I applied bodhi's patch on v3.18.21, and modified luke's config a little bit, attached for reference.

The attached patch on top of Bodhi's can bring up the eth0, but the network is still unusable, related information in dmesg:

libphy: Fixed MDIO Bus: probed
libphy: CNS3xxx MII Bus: probed
eth0: RGMII PHY 1 on cns3xxx Switch
Listening on LPF/eth0/00:10:75:43:91:17
Sending on   LPF/eth0/00:10:75:43:91:17
Sending on   Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
eth0: link up, speed 1000 Mb/s, full duplex
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 17
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 16
No DHCPOFFERS received.

Very nice work, dood!

On Debian, we always had problems with DHCP. It only worked sporadically.
Maybe try with another OS, like Arch or something, dunno.

I guess you didn't look onto getting SMP to work?

It may not be a DHCP problem. In the patch, the following code controls which MAC connect to which PHY port.
Based on stock kernel config (CONFIG_RTL8211_MAC0_PHYADDR1=y), it seems to be MAC0 and PHY1 connects a RTL8211.
But my following configuration does not work. May need other more experience people take a look.

file: arch/arm/mach-cns3xxx/cns3420vb.c
static struct cns3xxx_plat_info laguna_net_data = {
        .ports = 0x01,  //01, 03 also showup the eth0, but no connection!
        .phy = {
                1,          //read from old source code!
                0,
                2,
        },
};

To sum up, with my patch, the Ethernet driver respond to cable plug/unplug, show in dmesg as link up/link down.
But cannot ping or dhcp. With some hint from luke and a very blue video, the UART port of seagate central is marked in the picture.
I am totally lost and hope those information may help others to carry on.

Good news, after some digging, the ethernet is working now with the following patch on openwrt's driver cns3xxx_eth.c and my previous patch.

59d58
< #define IP_CHECKSUM 0x00040000
717,725c716,722
<       rx_ring->cur_index = i;
<       if (!received) {
<               napi_complete(napi);
<               enable_irq(sw->rx_irq);
< 
<               /* if rx descriptors are full schedule another poll */
<               if (rx_ring->desc[(i-1) & (RX_DESCS-1)].cown)
<                       eth_schedule_poll(sw);
<       }
---
>     rx_ring->cur_index = i;
>     enable_irq(sw->rx_irq);
>     napi_complete(napi);
> 
>     /* if rx descriptors are full schedule another poll */
>     if (rx_ring->desc[(i-1) & (RX_DESCS-1)].cown)
>         eth_schedule_poll(sw);

A complete patch apply on 4.2.y kernel tree is on https://github.com/KL-Yang/seagate_centeral_linux.
WORKS: sata, ethernet. (This should be enough as a basic NAS now)
NOT WORKS YET: smp, usb.

Wow... Amazed Yama is amazed :D

Just posting to show my appreciation^^

I messaged the ARM maintainer again and update you as soon as I get an answer :)

Oh yes, a probably good new.

But i have several question, what is your cmd line for booting your systeme ? (because on my systeme it boot with mem=256 and not with 512).

And Seagate Business Storage have two ethernet port no ?

For USB3 i think is connected to pcie 1x internal port and it seem it's just on litle think not correctly configurate.

When i found time i will try on my systeme

The fix is probably not that good.
I was testing use tftp boot, and when I thought the ethernet was fixed, I switch to boot from sata, then the ethernet does not work any more.
And switch back to tftp, boot into debian, ethernet is good again.
Looks like U-boot did something right to initiate the ethernet that missed in our drive. Sorry for the bad news.
Mine is a seagate central with only 1 ethernet and 1 usb 2.0 port and 256MB RAM. Here is my tftp boot log from UART port.
(I connect the seagate central first to my PC (192.168.1.x) to do tftp boot, then plug the cable to router (192.168.0.x)).

Good news again. A new patch was updated on github and now ethernet works too when booting from sata.
When booting with tftp, u-boot initiated ethernet and leave us a working configuration in some register.
That configuration acquired from u-boot source code was added to the patch.
The speed can go beyond 500Mbps when testing with iperf connect directly with another PC.
The patch only tested with Seagate Central NAS, may not work for the business nas, and the patch is nasty, will clean it up later.
By the way, the cmd line argument in my config file was "Always use the default kernel command string".

Quote
ARM Maintainer
> Are you having ideas how we could make SMP and USB work?

They should work with OpenWrt patches.
IIRC the USB support require a cosmetic patch to compile
(drivers/usb/dwc/otg_pcd.h contents must be disabled by
#ifndef DWC_HOST_ONLY). You should simply enable SMP support and the
DWC_OTG driver and both SMP and USB should be functional.

USB could require some additional power management, though (e.g.
enabling power with GPIO). This depends on the hardware.

He told me earlier (half a year ago) he was able to boot a the mainline kernel on a Cavium device, but it didn't work for us.
I guess we have another chip for USB, since its USB 3.0, but we could give SMP a try.

I examine the difference of struct switch_regs , the ethernet driver doesn't initiate the bit of MAC[012]_CLOCK_ENABLE, and the CLOCK_SKEW for gigabit mac, and the lower 12bit of mac_cfg, I have found the definition of the most important bits in seagate's GPL source code, but the lower 8bit of switch_regs->mac_cfg is unknown, but seems the value does not affect my device. If there is datasheet or some information about those registers, it would be easier to figure things out. Without those information, it would be difficult to make the driver work smoothly in different environment.

I have spent too much time on it. Here is a summary.
The openwrt.cc.patch applies on top of openwrt CC's patch for cns3xxx (3.18.x kernel)
The config_seagate_good0 with smp disabled and good ethernet on Seagate Central NAS (faster than 500Mbps)
The other with smp and can seen 2 cpu, but ethernet only a few handrunds Kbps
Both can successfully boot into Debian Jessie armel rootfs.
Good luck on playing.

Hi echor,

does the kernel with your patches have the USB support? At least USB2.0? And does it work for 2-bay NAS?

Currently I run the Debian Squeeze on my NAS with old kernel 2.6.35 (compiled from sources provided by Seagate, everything works except for SMP) and I am wondering if it is worth to upgrade to 3.18 and Jessie.

BTW, much appreciation to all your work!

Best,
Tommy

Hi Tommy,

Strange that I cannot get Seagate kernel compiled correctly for my Central NAS.
I currently run 3.18 and Jessie for testing for a few days, now both SMP and ethernet is working reasonable, but USB and RTC are not working yet.
I can compile the kernel itself on the Central NAS (1Bay) with make -j2 use debian jessie rootfs.
I clean up the patches and configure file, it applies on top of openwrt's cnx3xxx kernel.
The USB driver itself shouldn't be a big problem, but it's hard to figure out those enabling bits and vbus pin kind of things.

I plan to compile the kernel with the patches now, but I really have no clue where to start...
All the files here are confusing me XD

go to openwrt 15.05 reponsitory,
copy files in target/linux /cns3xxx/files/ on top of linux-3.18.y stable tree
apply the patches in target/linux /cns3xxx/patches-3.18 on top of previous step
apply my patch 901_seagate_central_ethernet_smp.patch on top of that
use the config_seagate_smp to compile the kernel for Seagate Central NAS, good luck.
I used debian jessie's "gcc-arm-none-eabi" compiler. with command "LOADADDR=0x02000000 make ARCH=arm CROSS_COMPILE=arm-none-eabi- uImage"

Compiled the kernel, applied all the patches and finally my system was up with kernel 3.18!

Nice work dood :D

SMP seems to work. USB not and I couldn't manage to get network working.
I'm using the root from RPi of Archlinux.
eth0 is shown, but down and I can't bring it up. On both ports the LEDs are flashing as I plug the network cable in.

I noticed that you typed in /dev/sda3 in the config file and I was wondering why the fuck it wants to mount that :D
Anyway, my procedure how to rebuilt the initramfs and let the kernel ignore the commandline options is unecessary now^^
But I couldn't make that work with UUIDs and I need to use UUIDs there.

On Debian I was able to mount all flash partitions, but Arch doesn't show me these. So I wasn't able to replace the uImages again (without booting a Debian root). I wonder why Arch doesn't recognize the flash drive.

I have the Business 2-Bay and this should have 512MB of RAM. Setting the commandline option to 512M makes it no longer boot the kernel anymore. Maybe I'll try later with some lower values.

I will look for other Arch root which may fit for the NAS.

Yama,

It's easier using armv5 Debian or Arch.

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

Found out how to boot to specific partition with using UUIDs. The kernel uses PARTUUID, which is "Disk identifier" on fdisk, displayed like: 0x06e268c9

You need the part after 0x and add "-01" or "-02" for the partitionnumber.

root=PARTUUID=06e268c9-02

Add this in the kernel config to "CONFIG_CMDLINE" like in the config of echor.

The kernel doesn't loads even if I set mem=300M. But uboot is still showing DRAM: 512MB...

Same issues on Arch and Debian.
Network might be working on Seagate Central, but it is not working on the Business NAS 2-Bay.

ifconfig eth0 up
SIOCSIFFLAGS: Cannot assign requested address

The internal flash drive (supposed to be emmc) is not recognized by Debian either, there must be a missing kernel config.
I activated

CONFIG_MTD_NAND=y

but it didn't help.

The critical part might be that no single module gets loaded.
On Arch the whole service (systemd-modules-load.service) for loading modules didn't start and on both systems "lsmod" is showing an empty list.

Startup of Debian
Startup of Arch



Edited 2 time(s). Last edit at 11/25/2015 02:46AM by Yama.

> On Arch the whole service
> (systemd-modules-load.service) for loading modules
> didn't start and on both systems "lsmod" is
> showing an empty list.

Arch does not use any module. All drivers compiled into the kernel.

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

Hi all,

In my opinion the memory probleme is the missing 256m of ram is not correctly activate by the kernel.
For the ethernet probleme i think the port is not the same that nas central. We need to search in the original kernel source to find the correct way to be used.
And USB3 chip is connected to pcie port, so i think pcie port is not correctly activated to.

ps: Sorry i wrote directly in english and i'm a poor english writer ^^.

I tried more things out, like activating everything what has "CNS3XXX" in the name.
Couldn't get USB, network and 512MB RAM to work, but the internal flash.

I checked the original bootarg and yes, uboot loads the kernel with mem=512M.
Our self compiled 2.6 kernels are able to boot with that, I already set up earlier to boot my kernel with my rootfs without interrupting uboot.
But if I do it with the kernel verson 3.18.24 it just freezes like told before...

For internal mmc flash activate these:

• Device Drivers
  
  • MMC/SD/SDIO card support
    
    • Secure Digital Host Controller Interface support
    • SDHCI platform and OF driver helper
      
      • SDHCI support on the Cavium Networks CNS3xxx SoC

I don't think that USB and network will work with just playing in the kernel configuration...



Edited 1 time(s). Last edit at 11/27/2015 04:09PM by Yama.

My patch only works for Seagate Central.

Please try tftp boot to see if ethernet works.
On Seagate Central, OpenWRT's ethernet driver works only when boot from tftp.
UBoot will initiate some configuration register, and only after that ethernet works in linux.
If that works, we can check the value in those register and make it work when boot from sata too.

Finally had time to test it.

I loaded the kernel from tftp, but still the OS says

Cannot assign requested address

Hi there

I just want to say that i got modified firmware from seagate for SSH access on the Business storage 2-bay NAS - i have full SSH access now and SCP access. I can edit and write - im a newbie to this, and the only wish i have is to either install Debian or update the actual PHP and lighttpd versions on the NAS.

So please, can anyone help me or helping others with this?

Any help will be appreciated!

By the way, i can upload the .img .md5 files that i recieved from seagate, maybe its a help?. I really appreciate the good work youre doing.


Waiting to hear from you

@M

Sorry we can mod the official OS to update some software.

We currently want to remove the original OS to directly boot in an other OS (debian in this case).

So for the moment you have to play with the official OS until someone make a correct kernel and uboot for this machin.

You understand ?

ps: sorry for the bad english i'm juste a french guy ^^.

Thanks for the answer!

Yes i understand :)

- im willing to give remote access to the NAS. As i described before i have full SSH access right now, and can send commandlines to the NAS


im trying to just update the PHP version ! - but i cant. I dont know how to do that. If anyone can guide me i will appreciate.

In the meantime im waiting for answer from Seagate - and trying to figure out if there is a way to install debian


Just want to share links that i found with you guys - maybe its helpfull to the process:

http://nickolaszev.blogspot.dk/2012/01/install-debian-lenny-in-nas-110.html

https://www.nerdbox.it/seagate-business-nas-shell-access/

http://www.noerenberg.de/hajo/pub/seagate-blackarmor-nas.txt

With the help of some friends, I found out, that the network is working on the 2-Bay NAS, too.
I needed to assign a mac-address, cause it was set to 00:00:00:00:00

On Archlinux, I set it that way.

$ cat /etc/systemd/network/eth0.network
[Match]
Name=eth0

[Network]
DHCP=yes

[Link]
# Original Mac-Adresse of Port1
MACAddress=00:10:75:6E:83:32

I found the mac-addresses in uboot, with the command printenv.
The second interface doesn't seems usable. Good thing I don't need it (currently).

Now the missing things are 512MB RAM, fan control and USB.

For USB I couldn't find anything...
The RAM issue seems to be cause if the mapping the devices.

$ cat /proc/iomem
00000000-0fffffff : System RAM
  00008000-00560fab : Kernel code
  00592000-005d5e9f : Kernel data
10000000-17ffffff : physmap-flash.0
70000000-70000fff : eth0_mem
  70000000-70000fff : eth0_mem
78000000-7800001f : serial
82000000-82ffffff : ehci-platform.0
  82000000-82ffffff : ehci-platform.0
83000000-83ffffff : ahci.0
  83000000-83ffffff : ahci.0
85000000-85000fff : sdhci-cns3xxx.0
  85000000-85000fff : mmc0
88000000-88ffffff : ohci-platform.0

This output is from the kernel 3.18. I don't have the output from 2.6 but it completely differs from 3.18 and has alot more devices in it, like pcie.
It seems, that the problem is the flash drive, which is directly mapped after the RAM, so setting a higher RAM value conflicts with the flash drive.

1329-M-arch-arm-mach-cns3xxx-Makefile.boot-M-arch-arm-mac.patch

This patch from the NAS-sources is for patching the kernel to make it run with 512MB RAM, but it fails on the new kernel and some files are missing, too.
I am not able to fix the patch for 3.18.

The sensors for temperatures and the fan worked on our 2.6 kernel, but are not working on 3.18, even after enabling "ADT7475" drivers, which include ADT7473 drivers, which our sensor is.
http://pastebin.com/NS4Xtj3T
This is the output of sensors-detect. The device is on 0x2e and the error occurs exactly on that.
I can live for now with 256MB RAM, since it works, but I can't let the fan run at 100% in the living room.

GPL/linux/1544-Whitney-Econa-Update-kernel-from-RC6-2788-to-r2875.r.patch

Seems to be the patch to make the sensors work, also from the NAS-sources.
I wasn't able to make it work on 3.18.

OpenWRT already ported the patches to kernel 4.4, but I didn't played around with them.
https://dev.openwrt.org/browser/trunk/target/linux/cns3xxx?rev=48336&order=name