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

[bodhi <tlibertin@xxxxxxxxx>]

Hi Neil,

Yes it did work perfectly, until the rootfs mounting. In this boot I still used USB rootfs, so expectedly the kernel could not mount it. I am setting up NFS rootfs to boot it instead.

Here is the boot log:

http://pastebin.com/Ep7NUj9A

Regards,

bodhi

On Fri, Dec 9, 2016 at 8:31 AM, Neil Armstrong <narmstrong@xxxxxxxxxxxx> wrote:

Hi Dqniel, Bodhi,

Thanks for your returns, don't hesitate to send some bugs or some branch for me to review,
If I can push more than USB for the next linux release, it would be great !

Neil

Le 09/12/2016 10:29, bodhi a écrit :
> 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
>

Sorry, does it mean it is working for you ?

>
> 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.
Great, can you provide the complete boot log on a pastebin ?

>
> 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>;
>>       }
>>     };
>> };

Yes, seems necessary, it will be necessary to reviez this structure once you made the driver work correctly.

>>
>> 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.
>>

Always hard to do such code without any documentation and very dirty code....

>>
>> Cheers
>>
>>
>> Daniel

Thanks,
Neil

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