[linux-oxnas] Re: OX820 SATA (Re: Update support for OX820 patch)

Hi Neil,

Hi Daniel,

I have booted the 4.9-rc8 kernel, built from https://github.com/OXNAS/linux on a Pogoplug Pro (PCIe version).

[ 0.000000] Booting Linux on physical CPU 0x0

[ 0.000000] Linux version 4.9.0-rc8-oxnas-tld-1 (root@tldDebian) (gcc version 4.9.2 (Debian 4.9.2-10) ) #2 SMP PREEMPT Tue Dec 6 07:07:14 PST 2016

[ 0.000000] CPU: ARMv6-compatible processor [410fb025] revision 5 (ARMv7), cr=00c5787d

[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache

[ 0.000000] OF: fdt:Machine model: Cloud Engines PogoPlug Series 3

This was tested using u-boot 2015.10, and the box was running at 800Mhz. I'll prepare an NFS rootfs to boot this kernel, will report the resullt later.

Off topic, thanks Daniel for your works! I've been able to use OpenWrt patch, and ideas from Neil upstream patch series to build and run kernel 4.4.11 successfully!

Regards,

-bodhi

On Mon, Dec 5, 2016 at 4:43 AM, Daniel Golle <daniel@xxxxxxxxxxxxxx> wrote:

Hi Neil,
Hi Bodhi,

On Mon, Dec 05, 2016 at 09:16:37AM +0100, Neil Armstrong wrote:
> Hi Bodhi !
>
> Thanks for your interest !
>
> The initial support for OX820 on Pogo Plug V3 will land in Linux 4.10, which merge merge should start next week and be tagged in february 2017.
>
> But In the meantime I can provide you a 4.9-rc8 kernel with all the patches applied !
>
> Beware that SATA, PCIe and USB support are missing, and must be forward-ported from the 4.0/4.1 kernel OpenWRT and you uses.

I'm planning to back-port upstream oxnas support from the 4.9-rc8 tree
you provided to LEDE's Kernel 4.4 (should be possible with the use of
some kernel version ifdef'ery and such).
Porting EHCI and PCIe support seems quite straight forward to me.

The SATA/RAID core is a more complex beast, however. I reckon we need
another nested simple-bus @45000000, ie.

apb-bridge@44000000 {
....
sata-phy@900000 {
compatible = "oxsemi,ox820-sata-phy";
reg = <0x900000 0xc>;
...
};
};

apb-bridge@45000000 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "simple-bus";
ranges = <0 0x45000000 0x1000000>;

sdio@400000 { ... };
i2s@500000 { ... };
dma@600000 { ... };
sgdma@610000 { ... };
crypto@700000 { ... };
video@800000 { ... };

sata@900000 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
compatible = "simple-bus";
ranges = <0 0x900000 0x100000>;

porta: sata-port@0 {
reg = <0x0 0x10000>;
};
portb: sata-port@10000 {
reg = <0x10000 0x10000>;
};
dma0: sata-dma@a0000 {
reg = <0xa0000 0x20>;
};
dma1: sata-dma@a0020 {
reg = <0xa0020 0x20>;
};
sgdma0: sata-sgdma@b0000 {
reg = <0xb0000 0x10>;
};
sgdma1: sata-sgdma@b0010 {
reg = <0xb0020 0x10>;
};
sata-crypto@c0000 {
reg = <0xc0000 0x10000>;
}
sata-core@e0000 {
reg = <0xe0000 0x10000>;
}
sata-raid@f0000 {
reg = <0xf0000 0x10000>;
}
};
};

The S-ATA driver itself interacts with both ports as well as dma and
sgdma regions and the sata-core. In order to support RAID and CRYPTO,
an MFD driver needs to be created (see [1] in the vendor source tree).

I reckon porting the S-ATA driver from OpenWrt/LEDE is going to be
the first thing I'd be doing once I got upstream-oxnas backported to
LEDE's current kernel. I've been working a bit on the S-ATA driver
before, starting from kref's single-port implementation. It now comes
with supports for both ports and has proven to work pretty well.
Obviously, RAID-1 write operations are much slower than they could be
if hardware offloading would be utilized...
There also seem to be some problems with error handling resulting
in an endless fault-reset-fault-reset-... loop when a drive is
hot-unplugged or fails during operation. I've been trying to wrap my
head around the hack'ish partial-reset tricks used in the vendor
driver which prevent a full core reset in case a single port is failing
but couldn't fully sort out things back then two years ago.

Cheers

Daniel

[1]: https://github.com/kref/linux-oxnas/blob/reference/sdk/drivers/ata/ox820direct-storage.c