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

[smitty3268]

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?

He did.

Hi Maxime & Others, what follows is a somewhat lengthy technical story behind this patch; you can just skip it and jump to the end. As can be seen in the ahci_sunxi.c, the port used in this patch is this one (32bit): #define AHCI_P0DMACR 0x0170 It's a so called "Vendor Specific Port" according to the SATA/AHCI specs by Intel. The data behind it is actually a struct, consisting of 4 fields, each 4bits long, plus a 16bits long field that is marked as Reserved in secondary literature (see below): struct AHCI_P0DMACR_t { unsigned TXTS : 4, RXTS : 4, TXABL : 4, RXABL : 4, Res1 : 16; }; This struct is just my creation for my own tests as it's not part of the driver source. The patch touches only the first 2 fields: TXTS and RXTS. See this similar product documentation by Texas Instruments for the above struct: https://www.ti.com/lit/ug/sprugj8c/sprugj8c.pdf TMS320C674x/OMAP-L1x Processor, Serial ATA (SATA) Controller, User's Guide, Literature Number: SPRUGJ8C, March 2011, Page 68, Chapter 4.33 "Port DMA Control Register (P0DMACR)" The above TI document describes the two fields as follows: TXTS: Transmit Transaction Size (TX_TRANSACTION_SIZE). This field defines the DMA transaction size in DWORDs for transmit (system bus read, device write) operation. [...] RXTS: Receive Transaction Size (RX_TRANSACTION_SIZE). This field defines the Port DMA transaction size in DWORDs for receive (system bus write, device read) operation. [...] So, in my patch the fields TXTS and RXTS are set to 3 each. Without the patch, these fields seem to have some random content (I'vee seen 5 and 6, 4 and 4, and 0 and 0 on different devices), as the previous code doesn't touch these 2 fields (ie. these two fields are not within the used old mask of 0xff00; cf. ahci_sunxi.c, function ahci_sunxi_start_engine(...)). Some background story in my hunt for obtaining product documentation: I couldn't find any product documentation for the SATA/AHCI in these SoCs by Allwinner Technology (allwinnertech.com), unlike with such products from other such companies. I asked Allwinner, but they just said that the A20 of my SBC would (allegedly) no more be actual and that the support for it has ended (but this statement somehow cannot be true as the A20 SoC is still continued being marketed at their website). They instead sent me a bunch of really irrelevant PDFs which have nothing to do with SATA/AHCI. So, the company Allwinner Technology unfortunately was not cooperative to provide me information on their SATA/AHCI-implementation in their SoCs :-( Even the ports used in the actual ahci_sunxi.c in the linux tree are undocumented; it is even commented with "/* This magic is from the original code */" and below it many ports are used for which no documentation is available, or at least I couldn't find any on the Internet. And the initial programmer in 2014 and prior was Daniel Wang ([email protected]), but email to that address bounces. So, I was forced to research secondary literature from other vendors like Texas Instruments (thanks TI !) and Intel, and also studying very old source codes in the old Linux repositories (as it differs much from the current version) going back to the year 2014, and had to do many (blind) experiments until I found this solution. The above given User's Guide by Texas Instruments (and their such documents for their newer such products) helped me much to find the solution. It's of course not really the correct documentation for the Allwinner SoCs, but still better than nothing. If I only had the right documentation, then I for sure could try to further improve that already achieved result by this patch, as with SATA-II upto 300 MiB/s is possible. Yes, I'll resend the patch with some appropriate comments. Uenal Mutlu

[zoomblab]

This is not factually correct. The GPU is completely proprietary with a FOSS linux driver. Other GPUs like Mali are more open in that they do not need this proprietary firmware but their FOSS linux driver is still at the early stages of development.

Like pal said, firmware doesn't matter. It is really part of the hardware. It could also happen to reside permanently on the hardware. AFAIK the fact that it isn't, is for flexibility.

[kenren]

This is simply wonderful, I really hope the best for future improvements, but I don't read anything on sunxi community about it... I think that if no official doc exist the best way is to write it from reverse engine.

[willmore]

This is simply wonderful, I really hope the best for future improvements, but I don't read anything on sunxi community about it... I think that if no official doc exist the best way is to write it from reverse engine.

That's normally what would have happened. Usually, the BSP serves as that source of information. If the register is documented, the mainline code will say what bits are getting set in what register. If the register isn't defined in a doc, then the mainline driver will say "magic bits from BSP driver, don't know what it does, but it works". But, in this case, the BSP driver didn't set these values properly either, so there was nothing there to RE--unless you want to start randomly poking at bits in the SATA controller register space. That's probably not a good idea.

[Terrablit]

This is not factually correct. The GPU is completely proprietary with a FOSS linux driver. Other GPUs like Mali are more open in that they do not need this proprietary firmware but their FOSS linux driver is still at the early stages of development.

You seem to forget that when we talk about devices and platforms being open, we're referring to the state in which the vendor offers them. At least until the day when everything that can be open has been opened. As of now, the state of these two GPUs is completely opposite from what you think it is.

Point 1: You're wrong about firmware. Almost all GPUs currently use proprietary firmware. The RPI isn't notably worse than any other GPU about this. Mali doesn't have to load binary blobs, but that doesn't necessarily make it more free.

Oddly enough, the GNU line says binary blobs are "non-free", while both flashable and baked-in firmwares are "free". Which is one of the biggest problems I have with their judginess, as it's viewed entirely from a software perspective ("if the code exists on the user's data drive, do we have it"?) instead of a hardware perspective ("how much can the user alter the behavior of the device?"). I value the capability for hardware hacking, and I think it's a mistake to prefer non-hackable devices over hackable blobs.

Whether that firmware's flashable or needs to be loaded at init is mostly irrelevant. It's a typical point for GNU rhetoric wankery in that it doesn't make much of a difference despite being an ideological hill that people love to die on. As long as the device firmware isn't write-once, doesn't blow fuses, and isn't walled off behind vendor signatures, both options are equally open to reverse engineering efforts and modifications. Which is effectively not at all from a FOSS perspective. Being capable of breaking the lock on a door doesn't make it an open door. And having the internals be locked/unlocked for hacking is different from using proprietary/FOSS drivers in the OS. Stop confusing those concepts.

Mali also has firmware. You need that sort of thing when you sell drop-in independent IP blocks like ARM does with Mali. It doesn't use a blob, so the only question is if it's flashable or not. And there's no source for it, so it's proprietary. Thus, both devices have proprietary firmware. So it's the most useless thing ever for you to bring this up in a comparison as if it actually means anything at all.

It's also significantly less important to have open firmware than it is to have an open driver. Open firmware allows for hacking the device to fix hardware bugs, add new functionality, etc. But you can still get advertised usage out of a device with closed/locked firmware. Drivers, on the other hand, are what we generally get stuck on because vendors write their drivers in old bespoke trees and refuse to invest time in updating them. Which means users get stuck on old, outdated kernels and deal with tons of massive security issues just to get the advertised usage out of a device. Both are great, but if you've got to pick, having a mainlined driver is significantly more important to users because it doesn't restrict the selection of the rest of the software on the system.

So, no, Mali is not more open because it doesn't have a binary blob. That's preposterous.


Point 2: Mali has never been more open than any other ARM GPU driver from a vendor perspective. ARM doesn't help at all with Mali besides the kernel drivers which have to be paired with proprietary user code to be useful. Which isn't enough open code to get anything particularly useful from a user standpoint. Everything else open that exists about Mali comes from users and other companies donating free time to reverse engineer it. Just because we have an open driver doesn't mean the platform is open. Because it's not. Everything is hidden behind NDAs.

On the other hand, Broadcom (RPI SoC vendor) published documentation for significant portions of the RPI. They published code for similar systems to jump start community efforts. They hired Eric Anholt to write a new GPU driver for the VC4 and the subsequent generations. Sure, they could have done more, and they've made a lot of shitty moves in the past. But they're doing pretty well with RPI and they're significantly better than all other ARM vendors at the moment.

So, no, closed firmware with no drivers and no docs is not better than closed firmware with lots of docs and paying someone to write a driver in any form of reality.


Point 3: One loadable firmware you might be talking about is the VPU bootloader that already has a RE'd alternative. It's on github at https://github.com/christinaa/rpi-open-firmware. It still needs lots of work and the design is arguably stupid, but it's there. I think there's still more firmware in use. But it's not something that blocks kernel updates, so it's extremely low priority and hardly a reason to congratulate Mali and ARM, given how difficult of a platform/vendor they've been historically.

If you want an open stack running a modern kernel on an ARM SoC, RPI or Vivante/Adreno systems are your best choices. They're not 100%, for sure. But, of those, Broadcom has done the most to open up the platform themselves. They're not saints, for sure, but that doesn't mean we shouldn't give the RPI platform the credit it's due.

Hopefully now you'll stop saying wrong things. But at least no one in this thread should erroneously accept your misinformation as useful or informative.

[starshipeleven]

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 changed only Allwinner Sata controller driver. At most they broke Allwinner controllers. But given the testing I doubt it.

[starshipeleven]

Mind blown!

Glad to hear that NXP is in the "good" category with TI, as I've sponsored them both privately and professionally.

NXP also uses OpenWrt as their SDK for Linux SoCs, and they routinely sync their changes and maintain them in OpenWrt project.

[SystemCrasher]

Whoa. People always wondered what makes native SATA on Allwinner boards unreadonably slow. And now ... just THAT?! At which point these cheap fancy things are looking even more appealing for NAS-like uses/automatic downloaders/etc.

p.s. yes, chinese documentation sucks. I've recently evaluated GD32 microcontrollers for one project - and guess what? These nuts can't even document pinout properly!!! So 28-pin MCU lists pinout of 64-pin MCU - have fun trying to plug that into your circuitry. That leaves me puzzled on how someone actually implements some circuits out of it.

[danboid]

This did make it into 5.3 BTW, although I've not tested it yet.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=120357ea176e420d313cf8cf2ff35fbe233d3bab

[danboid]

I finally got round to updating my old BPi M1 to a 5.3+ kernel, specifically Armbian Focal running Linux 5.10.21 and 7/8 years after buying my BPi I finally get decent SATA speeds! With a Crucial 240 GB BX500 plugged into its SATA port I'm getting about 170 MB/s read. That's about 1/2 the speed I get from this disk when its plugged the USB3 port on an Rpi 4 (~360 MB/s via a Sabrent USB 3.1 SATA3 adapter) but its still over twice as fast as it was pre 5.3 so I'm pleased with the update.