Allwinner ARM Boards With SATA See Big Speed Boost From Single Line Patch

[phoronix]

Phoronix: Allwinner ARM Boards With SATA See Big Speed Boost From Single Line Patch

Right now the low-end Allwinner ARM SBC boards featuring a SATA port have been running at a measly 36~45MB/s but with changing around a single line of kernel code, that can jump to 120MB/s...

http://www.phoronix.com/scan.php?page=news_item&px=Faster-Allwinner-SATA-Patch

[ssam]

Nice. These boards have also recently gained main line graphics and video acceleration.

[elatllat]

Why do SOC venders still think NDAs and blobs without source are profitable? The most open SBC vender (rpi) soled 20 million units. The second best supported SBC vender (Odroid) sells out. RISC-V can't come soon enough.

[c117152]

Why do SOC venders still think NDAs and blobs without source are profitable? The most open SBC vender (rpi) soled 20 million units. The second best supported SBC vender (Odroid) sells out. RISC-V can't come soon enough.

It's departmental politics. The software guys want their work to have monetary value that competes against the hardware department for when it's time to choose who gets promoted / their curriculum vitae.

[starshipeleven]

Why do SOC venders still think NDAs and blobs without source are profitable? The most open SBC vender (rpi) soled 20 million units. The second best supported SBC vender (Odroid) sells out. RISC-V can't come soon enough.

That's peanuts if compared to the amount of sales of Allwinner SoCs to random shitty OEMs, especially in china.

[schmidtbag]

Why do SOC venders still think NDAs and blobs without source are profitable? The most open SBC vender (rpi) soled 20 million units. The second best supported SBC vender (Odroid) sells out. RISC-V can't come soon enough.

Unfortunately, SOC vendors don't give a crap about SBCs. In most cases, SBCs only make a small percentage of SOC sales. RPi was sort of the exception - marketing had a lot to do with its popularity, but it got popular before it got proper open drivers.
RISC-V is not going to fix this problem. The core architecture is open source but that doesn't mean anything else about it has to be. I'm confident that most GPUs made for it will have blob drivers, just like ARM does.

Regardless, I do agree that these closed drivers are a loss in profits. It'd be one thing if these companies would actually properly maintain their drivers and make them easy to install, like Nvidia does. But they don't. Their releases are always crappy and make system maintenance a nightmare. ARM has lost so much traction in Linux because of video drivers being so crippling.

[Raka555]

I wish they would come up with some "VESA standard" or something which dictates how some basic accelerated functions should work and everyone should have those as a minimum and then they can do whatever fancy stuff they like in whatever way they want on top of that.

[polarathene]

Not knowing much about what's going on myself with that change, did the dev submitting the patch explain/document it? I'd assume changing the bits to different values like that if not standard/spec could cause unexpected problems elsewhere? They cited Intel and TI according to the article, but there's no other information about it, was it just trying different values and choosing one that gave the best I/O results?

[schmidtbag]

Not knowing much about what's going on myself with that change, did the dev submitting the patch explain/document it? I'd assume changing the bits to different values like that if not standard/spec could cause unexpected problems elsewhere? They cited Intel and TI according to the article, but there's no other information about it, was it just trying different values and choosing one that gave the best I/O results?

Yeah I was thinking pretty much the same thing verbatim.

[willmore]

Not knowing much about what's going on myself with that change, did the dev submitting the patch explain/document it? I'd assume changing the bits to different values like that if not standard/spec could cause unexpected problems elsewhere? They cited Intel and TI according to the article, but there's no other information about it, was it just trying different values and choosing one that gave the best I/O results?

The basic situation is that there are many vendors of IP blocks like SATA interfaces, etc. Designware is a popular one, but there are quite a few. How they license things to chip designers is opaque to me, but the behavior of the designers seems to follow a few clear paths:
1) Fully licensed the IP docs and all. Publishes full docs for their chips (TI, NXP, ST, etc.)
2) Some kid of licensing, but no docs or poor docs. (Samsung, Rockchip (sorta), etc.)
3) Not sure they licensed the IP at all, maybe they stole it or coppied it or someone found something lying around and used it. No meaningful docs if any. Often 'docs' are just a cut and paste from some generic document found elsewhere. (Allwinner, Rockchip (mostly), MediaTek, etc.)

This leads to some odd behavior. Normally drivers for 1 get done first--there's docs, they're accurate, the vendor is often helpful, etc. Then there are the other groups. Often a good deal of RE is required to write a driver or--if you're 'lucky'--there's a BSP dumped somewhere using an ancient kernel which can be used as a source of 'documentation'. This often leads to a poorly written driver--not the fault of the author, but there's 'magic bits' in the original code and there's nothing they can do to explain things that weren't explained to them.

In this latter scenario, it's not uncommon to find out that you just wrote a driver that's almost identical to an existing one! That often gets caught in the code reviews done prior to merging. it can be extremely frustrating for the author to be told "why did you rewrite an existing driver?" If they don't give up in frustation, they will often adapt the existing driver to support their hardware--often by adding quirks or other patches for the foibles of the newer chip. This is really common in case 3 where the vendow will sometimes scramble the order in which registers are addressed--maybe in some attempt to hide the that they stole the IP?

In the case of this SATA driver, what the author did was realize that the Allwinner chips used the same IP for their SATA interface as TI did. But, where Allwinner didn't document the hardware well, TI did. So, they poked through the TI docs and found some parts that were missing from the Allwinner docs. Since this register wasn't documented in the proper vendor docs, yes, there could be problems with messing with it. Fortunately, there's been a lot of people with SBCs using this IP who are testing things to ensure there are no regressions.