4 hours ago, joaofl said:

Menaged to compile it, but id did not change the USB3 limitation.

Try to find any relevant information here: http://forum.lemaker.org/forum.php?gid=146

Mwah... gets weirder all the time. Don't know if it contributes anything.... My Roseapple Pi running the latest armbian jessie spits this out when I give a "lsusb -t":

I am using a USB3 sandisk 32GB flash drive.

 

root@roseapple:~# lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
root@roseapple:~#
 

So it seems that it is recognized as a USB3 port. When starting the gnome-disks benchmark on my drive it quits unexpectedly after starting,initial speeds seem to be around USB2: refer to the screenshot..

Spoiler

 

All boards that fancy micro USB connector for powering are prone to power related issues. I would secure that part firs. Different cables, PSU, perhaps powering via GPIO.

Got some surprising performance numbers:

root@DietPi:/# hdparm -T /dev/sda

/dev/sda:
 Timing cached reads:   888 MB in  2.00 seconds = 443.93 MB/sec
root@DietPi:/# hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads: 356 MB in  3.00 seconds = 118.64 MB/sec
root@DietPi:/#

 

 

After all, USB3 works, for reading only! Does it make any sense? Why not to write?
Because with the same HD on my notebook, I get 150MB/s for R/W... So the bottleneck is not at the USB HD controller.

4 hours ago, joaofl said:

fter all, USB3 works, for reading only! Does it make any sense? Why not to write?

Not necessarily. Most of those bench marking methods are wrong / pointless in first place. This way is more realistic, and as you can see, there is something wrong with USB3 stack ...  

 

 

10 hours ago, Igor said:

there is something wrong with USB3 stack ...  

Thats true. But despite the speed limitation it seems stable so far.

 

However, there is one warning I keep getting:

[ 30.600191] drivers/video/owl/backlight/owl_pwm_bl.c/owl_backlight_is_on: get backlight failed!

I tried to disable this module before compiling the kernel, but could not found it exactly. Do you have a clue? How can I get more info on the error, to better lead me to its corresponding module on the kernel?

I just (again) wasted two hours to remember that any of those kernels needs a lot of code cleaning and fixing than "just" USB3. When this is done, than it would be possible to start debugging without wasting hours / days. 

 

About year ago I was approached by Allo, when they were trying to design their own board around S500 (Sparky). They were talking about mainlining (wishes) or bringing things at least to kernel 4.4, but I guess they abandon the idea due to whatever reason. There was lots of discussion going on and after my second reminder, that they need to hire and pay for my time, if they want me involved into their activities, I tuned myself out. They didn't listen what I was trying to tell them anyway. 

6 hours ago, Igor said:

I just (again) wasted two hours to remember that any of those kernels needs a lot of code cleaning and fixing than "just" USB3.

 

And all of this just to help someone else push out another DietPi image: https://github.com/Fourdee/DietPi/issues/822 

 

SUSE's Andreas Färber started with an initial combined S500+S900 patchset: http://www.cnx-software.com/2017/03/24/cubieboard6-development-board-powered-by-actions-semi-s500-processor-comes-with-sata-lipo-battery-support/#comment-540618  (at v3 now: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-February/490420.html)

 

I would neither touch Cubieboard6, any of the 3 other boards or any of those legacy kernel variants and consider these S500 boards broken by design in the meantime. And if there happens something upstream then think about it again...

OMG. I think I'll just burn this board  With actual fire. 

2 hours ago, tkaiser said:

And all of this just to help someone else push out another DietPi image: https://github.com/Fourdee/DietPi/issues/822 

Do you really see it this way? I would rephrase it: to help anyone who wants to make their S500 based board useful/functional, and get the best out of it... My intentions are more towards learning what is behind the scenes. Is there any problem?

With or without USB3, I'm making the DietPi image, so I can use my board as some sort of NAS. My intentions is to drop the link to the image after getting it done.

 

 

8 hours ago, Igor said:

wasted two hours

I also gave a try, wasting probably many more hours, and doing pretty much nothing, on my shallow knowledge. By disabling ones module, a cascade of errors show up during compile. You solve one, 10 more show up. In the end, if you eventually manage to compile, something probably won't work properly.

 

Thanks a lot for your time.

did someone try this 4.1 repository https://github.com/WarrickJiang/linux-yocto-4.1/tree/standard/actions-s500_0426 ?

 

i will receive my allo sparky in few day and i hope to use a 4.x kernel to use btrfs.

 

Krissfr