Welcher SATA-Controller in Banana PI's / Allwinner SoC's ?

[Mutluit M. (mutluit)]

Hi,

ich möchte in Erfahrung bringen, welcher SATA-II-Controller 
(Chip/IP-Core/Hersteller etc.) in dem Banana Pi M1 (bzw. Banana Pi R1; 
auch weitere Boards mit SATA scheinen den selben SATA-Controller zu 
haben) steckt.

Es handelt sich um Allwinner A20 SoC's (bzw. wahrscheinlich alle deren 
SoC's mit SATA).
Die Handbücher zu den o.g. 2 Board-Modellen die ich durchsucht habe, 
geben diese Info leider nicht her.

Ich habe lange im Web vergeblich recherchiert, und auch die Hersteller 
des SoC (allwinnertech.com) und des Boards (banana-pi.org) direkt 
angefragt, aber leider keine richtige Auskunft erhalten.

Es muss doch eine Möglichkeit geben, den SATA-Controller in Erfahrung zu 
bringen. Diese ARM boards haben ja kein PCI-Bus, folglich geht lspci 
nicht, und hwinfo liefert diese Info leider auch nicht :-(

Kann mir jemand helfen?

Thx

[poode (Gast)]

Mutluit M. schrieb:
> Kann mir jemand helfen?

http://www.kernel.org

[Thorsten (Gast)]

Der SATA Controller ist eine Eigenentwicklung von Allwinner und sitzt 
direkt mit auf dem SoC.

[Mutluit M. (mutluit)]

Thorsten schrieb:
> Der SATA Controller ist eine Eigenentwicklung von Allwinner und sitzt
> direkt mit auf dem SoC.

Und ich ging die ganze Zeit davon aus dass die eine fertige Lösung eines 
anderen Herstellers in ihren SoCs integriert hätten :-)

Weisst du zufällig ob zu deren SATA/AHCI eine richtige 
Programmier-Dokumentation existiert?

Denn die Informationen bzgl. SATA/AHCI in deren SoC-User-Manuals (z.B. 
"A20 User Manual Revision 1.4, Apr. 20, 2015") die ich durchgeforstet 
habe reichen nicht aus um SATA/AHCI programmieren zu können, z.B. die 
folgenden SATA-Ports (Offsets zu 0x01c18000) für Initialisierung
  PHYCS0R  0x00c0
  PHYCS1R  0x00c4
  PHYCS2R  0x00c8
sind undokumentiert, aber in deren Linux-Kernel-Treiber (ahci_sunxi.c) 
benutzt.
Ausserdem fehlt auch die Information über TX- und RX-FIFOs: Grösse/Tiefe 
und ob man sie anders konfigurieren kann (vergrössern).

Thx

[Mutluit M. (mutluit)]

poode schrieb:
> Mutluit M. schrieb:
>> Kann mir jemand helfen?
>
> http://www.kernel.org

Hab ich schon durchgeforstet: bin sogar zurück bis zum kernel v3.1 
gegangen, in der Hoffnung in den source-codes Kommentare/Links/Adressen 
zu finden die mir evtl. weitergeholfen hätten, war aber leider 
vergeblich :-(

Früher hiess der Treiber sw_ahci.c oder sw_platform.c, und das "sw_" 
soll für eine Partnerfirma "SoftWinner" (oder eine Sub-Division von 
Allwinner) gestanden haben, aber das scheint nicht mehr zu existieren.

Der Programmierer soll ein "danielwang" gewesen sein, hab den 
Allwinner-Support gebeten meine Anfrage an den weiterzuleiten, aber bis 
jetzt leider keine Reaktion :-(

[Twist (Gast)]

Mutluit M. schrieb:
> poode schrieb:
>> Mutluit M. schrieb:
>>> Kann mir jemand helfen?
>>
>> http://www.kernel.org
>
> Hab ich schon durchgeforstet: bin sogar zurück bis zum kernel v3.1
> gegangen, in der Hoffnung in den source-codes Kommentare/Links/Adressen
> zu finden die mir evtl. weitergeholfen hätten, war aber leider
> vergeblich :-(
>

Evtl. hier: http://linux-sunxi.org/Main_Page

[ich (Gast)]

Allwinner verwendet viele Synopsys Cores (z.B. DRAM, HDMI, Ethernet) , 
wahrscheinlich auch der SATA-Controller, aber häufig eigene PHYs. Und 
manchmal verschleiern sie auch die Verwendung bestimmter Cores, z.B. bei 
HDMI und manchen DRAM-Controllern.
Informationen vom Hersteller wirst du nicht bekommen, hier ist raten 
angesagt und dann kommt man meist auch nicht an die nötige Doku 
(Synopsys veröffentlicht auch nichts)

Falls der Grund der Frage ist, dass du denkst die 
Geschwindigkeits-Probleme beim Schreiben könnten einfach an schlechten 
Einstellungen (der FIFOs z.B.) liegen, willkommen im Club. Bisher hatte 
ich aber auch keinen Erfolg genug Informationen zu bekommen, hab es aber 
auch die letzten 2,5 Jahre nicht mehr weiter verfolgt.

[Mutluit M. (mutluit)]

ich schrieb:
> Allwinner verwendet viele Synopsys Cores (z.B. DRAM, HDMI, Ethernet) ,
> wahrscheinlich auch der SATA-Controller, aber häufig eigene PHYs. Und
> manchmal verschleiern sie auch die Verwendung bestimmter Cores, z.B. bei
> HDMI und manchen DRAM-Controllern.
> Informationen vom Hersteller wirst du nicht bekommen, hier ist raten
> angesagt und dann kommt man meist auch nicht an die nötige Doku
> (Synopsys veröffentlicht auch nichts)

So eine Firmenpolitik ist zu bedauern bzw. zu verdammen.
Der Konkurrenzkampf sollte sie eigentlich zwingen besseren Support und 
Dokumentation zu liefern, aber es klappt leider nicht :-(
Andererseits hat Allwinner ja in den letzten Jahren viel an Rockchip 
verloren... Ich weiss aber nicht wie die Lage dort aussieht.

> Falls der Grund der Frage ist, dass du denkst die
> Geschwindigkeits-Probleme beim Schreiben könnten einfach an schlechten
> Einstellungen (der FIFOs z.B.) liegen, willkommen im Club. Bisher hatte
> ich aber auch keinen Erfolg genug Informationen zu bekommen, hab es aber
> auch die letzten 2,5 Jahre nicht mehr weiter verfolgt.

Dann habe ich evtl. eine gute Nachricht für dich und viele andere Banana 
Pi User mit SATA boards:
ich habe den write-speed von 45 MB/s bereits auf 120 MB/s gesteigert :-)
Aber ich wollte so gern die vollen 300 MB/s erreichen... :-)

[Mutluit M. (mutluit)]

Twist schrieb:
> Mutluit M. schrieb:
>> poode schrieb:
>>> Mutluit M. schrieb:
>>>> Kann mir jemand helfen?
>>>
>>> http://www.kernel.org
>>
>> Hab ich schon durchgeforstet: bin sogar zurück bis zum kernel v3.1
>> gegangen, in der Hoffnung in den source-codes Kommentare/Links/Adressen
>> zu finden die mir evtl. weitergeholfen hätten, war aber leider
>> vergeblich :-(
>>
>
> Evtl. hier: http://linux-sunxi.org/Main_Page

War ich auch schon da. Ist zwar gut, aber die speziellen Infos die ich 
brauche, haben die leider auch nicht.

Die Infos müsste eigentlich der SoC-Hersteller liefern, weil es sich bei 
den o.g. Ports um sog. Vendor Specific SATA/AHCI Ports handelt.

[ich (Gast)]

Mutluit M. schrieb:
> Dann habe ich evtl. eine gute Nachricht für dich und viele andere Banana
> Pi User mit SATA boards:
> ich habe den write-speed von 45 MB/s bereits auf 120 MB/s gesteigert :-)
> Aber ich wollte so gern die vollen 300 MB/s erreichen... :-)

Gut :) Gibts dazu schon irgendwelche öffentlichen Infos?
Und die 120 MB/s Grenze könnte vielleicht auch durch die DRAM-Anbindung 
entstehen. Ich bin wie gesagt schon eine Weile raus aus dem Thema, aber 
es gab da so einen MBUS, dessen Taktfrequenz großen Einfluss auf 
Datenraten hatte. Der MBUS ist wahrscheinlich ein Memory-BUS über den 
diverse High-Speed Peripherie am DRAM hängt, statt AXI/AHB für die 
langsameren.
Außerdem gibt es im DRAM-Controller noch Host-Port-Control-Register, die 
auch irgendwas am Zugriff für einzelne Peripherie regeln: 
https://linux-sunxi.org/A10_DRAM_Controller_Register_Guide#SDR_HPCR
Meine Vermutung war mal dass die "command number" eine schlechte 
Übersetzung sein könnte und eigentlich Burst-Länge meint, kann aber auch 
totaler Blödsinn sein... Aber vielleicht lohnen sich da jetzt weitere 
Experimente.

[Mutluit M. (mutluit)]

ich schrieb:
> Mutluit M. schrieb:
>> Dann habe ich evtl. eine gute Nachricht für dich und viele andere Banana
>> Pi User mit SATA boards:
>> ich habe den write-speed von 45 MB/s bereits auf 120 MB/s gesteigert :-)
>> Aber ich wollte so gern die vollen 300 MB/s erreichen... :-)
>
> Gut :) Gibts dazu schon irgendwelche öffentlichen Infos?

Ich will bald ein Patch für Linux kernel (ggf. auch für u-boot) posten.
Aber das Problem ist, dass ich das nur auf einem (1) A20 SoC/Board 
(Banana Pi R1 aka BPI-R1, Lamobo R1) soweit ausgiebig getestet habe.

Einmal habe ich absichtlich mit zu hohen Werten experimentiert und das 
hat mein ext4-rootfs auf meiner SSD auf sda1 zerschossen. fsck hat IMHO 
alles nur verschlimmbessert, aber das kann auch nur eine subjektive 
Beurteilung sein; bin nicht gerade der Profi für ext-Filesysteme. Aber 
zum Glück war es nur eine Kopie des rootfs auf der SD-Karte (mmcblk0p2).

Wenn man am SATA-Treiber bastelt, dann sollte die root-Partition klein 
sein, z.B. 1 GB oder weniger, und möglichst viele Teile des Systems sich 
auf weiteren Partitionen (am besten GPT) befinden und via /etc/fstab 
gemountet werden, sodass wenn beim booten das rootfs zerschossen wird, 
dieser leicht ersetzt/zurückkopiert/wiederhergestellt werden kann.

D.h. es ist bis jetzt nur auf einem Bruchteil der vielen Boards und SoCs 
getestet, die den ahci_sunxi Treiber benutzen. Und ich habe bis jetzt 
nur die Kernelvariante getestet, nicht die Modulvariante.

Bevor man bei Linux ein Patch einreicht, soll es idealerweise auf allen 
betroffenen Systemen ausgiebig getestet worden sein. Wie kann man dieses 
Problem am besten lösen?

> Und die 120 MB/s Grenze könnte vielleicht auch durch die DRAM-Anbindung
> entstehen. Ich bin wie gesagt schon eine Weile raus aus dem Thema, aber
> es gab da so einen MBUS, dessen Taktfrequenz großen Einfluss auf
> Datenraten hatte. Der MBUS ist wahrscheinlich ein Memory-BUS über den
> diverse High-Speed Peripherie am DRAM hängt, statt AXI/AHB für die
> langsameren.
> Außerdem gibt es im DRAM-Controller noch Host-Port-Control-Register, die
> auch irgendwas am Zugriff für einzelne Peripherie regeln:
> https://linux-sunxi.org/A10_DRAM_Controller_Register_Guide#SDR_HPCR
> Meine Vermutung war mal dass die "command number" eine schlechte
> Übersetzung sein könnte und eigentlich Burst-Länge meint, kann aber auch
> totaler Blödsinn sein... Aber vielleicht lohnen sich da jetzt weitere
> Experimente.

Ja, diese Infos von dir sind auch interessant zum testen. Ich habe mich 
bis jetzt nur auf die ausdrücklichen SATA/AHCI-Sachen konzentrieren 
können.
Ich habe auch simple quasi-Reverse-Engineering-Methoden eingesetzt 
(haupts. für benutzte, aber undokumentierte, Ports). Hab aber bei weitem 
nicht alle möglichen Werte und Kombinationen testen können. Ist ja auch 
sehr zeitaufwendig: nach jeder kleinsten Änderung das Board neu-starten 
und analysieren ob alles noch richtig funktioniert...

Mittlerweile habe ich ein gutes headerfile der SATA/AHCI-Ports erstellt, 
aber dann habe ich im Intel-Spec gesehen, dass man viele Felder noch 
weiter unterteilen kann bzw. muss (bei sunxi, oder in Handbüchern von 
Texas Instruments, z.B. oberflächlich nur als byte dokumentiert, jedoch 
in der Realität handelt es sich aber um mehrere felder mit x bits). Das 
ist auch sehr zeitaufwendig, und auch fraglich ob für das Speed-Problem 
relevant ist. Ich habe das auch deswegen angefangen, weil ich auch den 
SATA Port Multiplier (ist noch unterwegs von China) testen und verstehen 
wollte und es ggfs. auch für andere Zwecke einsetzen wollte, und dachte 
soviel dokumentieren wie nur möglich.

Wenn wir alle unsere Anstrengungen zusammentun, könnten wir die 
(absichtlich eingebauten?) Handbremsen im SoC loslösen und diese IMO 
sehr interessanten SoC-Systeme von Allwinner auch erweitern.

[Mutluit M. (mutluit)]

ich schrieb:
> Und die 120 MB/s Grenze könnte vielleicht auch durch die DRAM-Anbindung
> entstehen. Ich bin wie gesagt schon eine Weile raus aus dem Thema, aber
> es gab da so einen MBUS, dessen Taktfrequenz großen Einfluss auf
> Datenraten hatte. Der MBUS ist wahrscheinlich ein Memory-BUS über den
> diverse High-Speed Peripherie am DRAM hängt, statt AXI/AHB für die
> langsameren.
> Außerdem gibt es im DRAM-Controller noch Host-Port-Control-Register, die
> auch irgendwas am Zugriff für einzelne Peripherie regeln:
> https://linux-sunxi.org/A10_DRAM_Controller_Register_Guide#SDR_HPCR
> Meine Vermutung war mal dass die "command number" eine schlechte
> Übersetzung sein könnte und eigentlich Burst-Länge meint, kann aber auch
> totaler Blödsinn sein... Aber vielleicht lohnen sich da jetzt weitere
> Experimente.

Evtl. kennst du das schon: das ccm_tool
( https://github.com/hno/sunxi_ccm_tool ) liefert folgende Werte (einige 
wie CPU-speed sind variabel):

PLL1CTL   : a1004d00
CPU       :  312.00 MHz
SYSCLKDIV : 00020192
ATB       :  312.00 MHz
AXI       :  104.00 MHz
AHB       :  300.00 MHz
APB0      :  150.00 MHz
APB1CLKDIV: 00000000
APB1      :   24.00 MHz
DRAM      :  432.00 MHz
PLL5CTL   : b1049291
PLL5      :  864.00 MHz
SATA      :  100.00 MHz
PLL6      :  600.00 MHz
PLL62     : 1200.00 MHz
MBUSCLK   : 81000003
MBUS      :  300.00 MHz

[Mutluit M. (mutluit)]

Eine (durchaus ernstgeminte) Quizfage in die Runde:
Woran würde es letzlich scheitern (?), einen SATA-II Controller (z.B. 
den in den Banana Pi Boards) als SATA-III zu initialisieren und zu 
betreiben? :-)
Was ist der Unterschied (HW/firmware/treiber etc) zw. SATA-II und 
SATA-III?

[Rufus Τ. F. (rufus)]

Mutluit M. schrieb:
> Was ist der Unterschied (HW/firmware/treiber etc) zw. SATA-II und
> SATA-III?

Hardware. Sata-II überträgt 3 GBit/sec (d.h. etwa 300 MByte/sec), 
Sata-III doppelt so viel.

[/sys (Gast)]

Mutluit M. schrieb:
> Evtl. kennst du das schon: das ccm_tool
> ( https://github.com/hno/sunxi_ccm_tool ) liefert folgende Werte (einige
> wie CPU-speed sind variabel):

Sowas gehört nach /sys

[Mutluit M. (mutluit)]

Rufus Τ. F. schrieb:
> Mutluit M. schrieb:
>> Was ist der Unterschied (HW/firmware/treiber etc) zw. SATA-II und
>> SATA-III?
>
> Hardware. Sata-II überträgt 3 GBit/sec (d.h. etwa 300 MByte/sec),
> Sata-III doppelt so viel.

Ja, schon klar. Die Frage war mehr darüber ob man SATA-II-Hardware 
austricken kann damit es SATA-III-Geschwindigkeiten macht, also 
praktisch daraus eine SATA-III zu machen.

[Mutluit M. (mutluit)]

/sys schrieb:
> Mutluit M. schrieb:
>> Evtl. kennst du das schon: das ccm_tool
>> ( https://github.com/hno/sunxi_ccm_tool ) liefert folgende Werte (einige
>> wie CPU-speed sind variabel):
>
> Sowas gehört nach /sys

Ja, finde ich auch. Am besten sollte jedes Board es machen.
Es gibt noch viele weitere solch interessanter Ports die man unter /sys 
aufnehmen könnte.

Viele CPU-Sachen sind bekanntlich zu finden unter:
/sys/devices/system/cpu/

[c = λ⋅f (Gast)]

Mutluit M. schrieb:

> Ja, schon klar. Die Frage war mehr darüber ob man SATA-II-Hardware
> austricken kann damit es SATA-III-Geschwindigkeiten macht, also
> praktisch daraus eine SATA-III zu machen.

Jajajaja software kann alles, ich hab hier auch einen tollen 
Opensourcepatch auf meinen C64 laufen der Lichtgeschwindigkeit, 
Abtastheorem und auch sonst die ganze Physik austrickst und jetztz läuft 
das ganze so schnell wie ein Octocore ...

[Bananenbrotbaum (Gast)]

Beim A20 als NAS wars doch so dass in einer Richtung SATA gebremst hat 
und in die andere Richtung die GMAC(1000aseT), IIRC.

Wirds jetzt schneller oder ist dann die CPU am limit?

[Mutluit M. (mutluit)]

Bananenbrotbaum schrieb:
> Beim A20 als NAS wars doch so dass in einer Richtung SATA gebremst hat
> und in die andere Richtung die GMAC(1000aseT), IIRC.
>
> Wirds jetzt schneller oder ist dann die CPU am limit?

Ich habe mich die ganze Zeit nur auf den SATA Write-Speed konzentriert.
Ob und wieviel sich auch der Read-Speed geändert hat, muss ich noch 
messen.

Hier meine Testmethode und aktuelle Zahlen (getestet auf einem BPI-R1 
mit 5.0.5 kernel, darin gepatchter ahci_sunxi.c, auf einer Patriot Burst 
120GB SSD in einer 4GB GPT-Partition mit ext4-Dateisystem, OS ist Debian 
8 (jessie)):

--------------------------------------
WRITE TEST:

root@r1-3:/mnt/sda1/tmp3# dd if=/dev/zero of=test2 bs=4k count=512k 
conv=sync
524288+0 records in
524288+0 records out
2147483648 bytes (2.1 GB) copied, 17.6765 s, 121 MB/s

root@r1-3:/mnt/sda1/tmp3# dd if=/dev/zero of=test2 bs=4k count=512k 
conv=sync
524288+0 records in
524288+0 records out
2147483648 bytes (2.1 GB) copied, 17.8549 s, 120 MB/s

root@r1-3:/mnt/sda1/tmp3# dd if=/dev/zero of=test2 bs=4k count=512k 
conv=sync
524288+0 records in
524288+0 records out
2147483648 bytes (2.1 GB) copied, 17.4569 s, 123 MB/s

root@r1-3:/mnt/sda1/tmp3# dd if=/dev/zero of=test2 bs=4k count=512k 
conv=sync
524288+0 records in
524288+0 records out
2147483648 bytes (2.1 GB) copied, 17.719 s, 121 MB/s


--------------------------------------
READ TEST:

root@r1-3:/mnt/sda1/tmp3# dd of=/dev/null if=test2 bs=4k count=512k 
conv=sync
524288+0 records in
524288+0 records out
2147483648 bytes (2.1 GB) copied, 10.075 s, 213 MB/s

root@r1-3:/mnt/sda1/tmp3# dd of=/dev/null if=test2 bs=4k count=512k 
conv=sync
524288+0 records in
524288+0 records out
2147483648 bytes (2.1 GB) copied, 9.95026 s, 216 MB/s

root@r1-3:/mnt/sda1/tmp3# dd of=/dev/null if=test2 bs=4k count=512k 
conv=sync
524288+0 records in
524288+0 records out
2147483648 bytes (2.1 GB) copied, 9.94472 s, 216 MB/s

root@r1-3:/mnt/sda1/tmp3# dd of=/dev/null if=test2 bs=4k count=512k 
conv=sync
524288+0 records in
524288+0 records out
2147483648 bytes (2.1 GB) copied, 10.0115 s, 215 MB/s



Ansonsten dürfte sich an der System-Performance nichts ändern, aber 
umfangreiche System-Tests stehen noch aus.

Ich habe bis jetzt nur die CPU-Temperatur beobachtet (ca. 26C ohne 
Kühlblech oder sonst. Kühler). Ausserdem sind im Leerlauf beide CPUs 
fast 100% Idle, d.h. da läuft nichts grossartiges im Hintergrund.

Bzgl. NIC: als ich das letzte mal vor einigen Wochen testete, hatte ich 
so um die 860 Mb/s (=107.5 MB/s), aber ich habe nur in eine Richtung 
getestet und auch nur ein NIC-Port benutzt (der R1 hat noch ein 
4-Port-Switch integriert, das habe ich noch nicht getestet (hatte noch 
keine Zeit dazu).

[Rufus Τ. F. (rufus)]

Mutluit M. schrieb:
> Die Frage war mehr darüber ob man SATA-II-Hardware austricken kann damit
> es SATA-III-Geschwindigkeiten macht,

Das ist mehr als unwahrscheinlich. Du wirst auch nicht per Software aus 
einem USB2.0-Anschluss USB3.0-Geschwindigkeit 'rausholen können.

[Mutluit M. (mutluit)]

Rufus Τ. F. schrieb:
> Mutluit M. schrieb:
>> Die Frage war mehr darüber ob man SATA-II-Hardware austricken kann damit
>> es SATA-III-Geschwindigkeiten macht,
>
> Das ist mehr als unwahrscheinlich. Du wirst auch nicht per Software aus
> einem USB2.0-Anschluss USB3.0-Geschwindigkeit 'rausholen können.

Naja, ich dachte vlt. kann man den austricken indem man bei 
Initialisierung des Treibers ins Port-Feld CAP.ISS schreibt es handle 
sich um ein SATA-III device. ABER: CAP.ISS ist leider READ-ONLY :-(
Wär ja auch zu schön gewesen :-)

[ich (Gast)]

Ich könnte noch auf einem Cubietruck (A20) testen, vielleicht auch ein 
Olimex LIME (A10).
Ansonsten könntest du den Patch auch als RFC mal auf die Mailing-Liste 
setzten, ein paar Leute können da bestimmt auch noch Ideen und Tests 
beisteuern. Die Erfahrung lehrt nur leider, dass auch Leute die keine 
Ahnung haben damit rumspielen und dann meckern, dass was nicht 
funktioniert...

[Mutluit M. (mutluit)]

ich schrieb:
> Ich könnte noch auf einem Cubietruck (A20) testen, vielleicht auch ein
> Olimex LIME (A10).
> Ansonsten könntest du den Patch auch als RFC mal auf die Mailing-Liste
> setzten, ein paar Leute können da bestimmt auch noch Ideen und Tests
> beisteuern.

Ja, sehr gute Idee mit der RFC! Danke. Genau so werde ich es machen.
Morgen oder am Sa wird es in der kernel mailing list erscheinen.

> Die Erfahrung lehrt nur leider, dass auch Leute die keine
> Ahnung haben damit rumspielen und dann meckern, dass was nicht
> funktioniert...

Genau das ist auch meine Befürchtung :-), denn ich will nicht verdammt 
werden wenn es bei jemandem nicht funktioniert und er dadurch Daten 
verliert.
Ich hab oben ja schon von meiner eigenen Negativ-Erfahrung berichtet als 
ich einmal mit zu hohen Werten experimentierte und der Treiber dann das 
Dateisystem zerschoss... :-(

Ciao

[Mutluit M. (mutluit)]

Ich hab heute ein gebrauchtes BPI-M1 bekommen und will den SATA-Patch 
auf dem auch testen bevor ich es dann poste.

[Mutluit M. (mutluit)]

Ich bin noch beim Zusammenstellen des patches.
Als Testanleitung wollte ich folgendes mitschicken:

Test steps / tips / precautions:
  1) backup all data of your SATA storage device(s)
     (for these tests you better should attach just one empty SSD drive)
  2) create a baseline of your current SATA write and read performance (similar to step 8 and 9)
  3) you should boot the patched kernel from a different device than SATA, ie. from SD/MMC/NAND/USB etc.
  4) fsck your storage partition on your SSD, ie. fsck /dev/sda1
  5) mount your storage partition (should have at least 4 GB free space), ie. mount /dev/sda1 /mnt
  6) create a test directory on the mounted partition, ie. mkdir /mnt/test
  7) go to the test directory, ie. cd /mnt/test
  8) perform write tests, ie. dd if=/dev/zero of=/mnt/test/test.tmp bs=4k count=512k conv=sync 
  9) perform read tests,  ie. dd of=/dev/null if=/mnt/test/test.tmp bs=4k count=512k conv=sync
 10) then unmount, ie. umount /dev/sda1
 11) then fsck the storage partition, ie. fsck /dev/sda1
 12) compare the test results to your baseline data (see step 2)
 13) Report back any problems and/or any significant performance improvements or degradations
     (give also device info, boot loader info, kernel info, os info, and any relevant log entries and messages)

Geht das so in Ordnug oder sollte man es vlt. anders machen?

[foobar (Gast)]

Das ist doch Kinderkacke - die Leute auf der LKML wissen schon, wie sie 
die Performance eines SATA-Treibers testen.  Und die benutzen bestimmt 
kein fsck um zu überprüfen, ob er auch alles richtig gemacht hat.

Die wollen wissen, wie du das erreichst, ob die Methode verlässlich 
ist, was für Nachteile es gibt, etc.

Evtl vorher mal mit den Sunxi-Typen sprechen - die waren mal auf'm IRC 
aktiv, keine Ahnung ob immer noch.

[Mutluit M. (mutluit)]

Ok, SATA am Banana Pi M1 (classic) habe ich jetzt am Laufen.
Ich konnte erst aber nur Tests mit dem ungepatchten kernel durchführen.
Hab hierzu auf die Schnelle mit einer Armbian image getestet (ARMBIAN 
5.31 stable Debian GNU/Linux 8 (jessie) 4.9.7-sunxi):

Also, das sind die "Normalwerte" beim Schreiben und Lesen auf eine SSD 
via SATA mit dem ahci_sunxi Kernel-Treiber (ohne mein patch):
READ:  201, 197, 198, 197 MB/s
WRITE: 38.2, 40.5, 40.0, 40.3 MB/s

SSD war wieder die o.g. Patriot Burst 120 GB.

Im Laufe des Tages werde ich es dann mit dem Patch auch testen.
Hierzu muss ich erstmal einen neuen Kernel kompilieren mit dem Patch, 
der aber auch die DTB des M1 benutzt. Ist ne Arbeit von einigen 
Stunden...

Wenn alles klappt, dann sollte auch beim M1 der Write-Speed auf 120 MB/s 
steigen...

[Markus W. (dl8mby)]

@all,

ich traue den Zahlen des o.g. Tests nicht ganz, weil mit NULL-Daten
(0x00)

dd if=/dev/zero of=/mnt/test/test.tmp bs=4k count=512k conv=sync

Könnt Ihr bitte mit
dd if=/dev/urandom of=/dev/shm/BIG_FILE_1GB.bin bs=1M count=1024
ein 1GB File mit zufälligem Muster erzeugen und dann dieses File
auf die SSD loslassen!
Sollte /dev/shm nicht reichen, weil weniger wie zwei GB RAM
vorhanden, je nach Modell, dann das File im eMMC erstellen.

Dann den eigentlichen SSD-Write Test starten.
time $(if=/dev/shm/BIG_FILE_1GB.bin of=/mnt/test/test.tmp bs=4k 
count=256k conv=sync; sync)

Ich selber habe zwei BPi-R2 und etliche Cubiboards mit A20 in meiner
SBC Sammlung und wäre auch an den Ergebnissen mit Patch interessiert.

Danke schon mal für den Aufwand und die Ergebnisse.

Markus

[Mutluit M. (mutluit)]

Markus W. schrieb:
> @all,
>
> ich traue den Zahlen des o.g. Tests nicht ganz, weil mit NULL-Daten
> (0x00)
>
> Könnt Ihr bitte mit
> dd if=/dev/urandom of=/dev/shm/BIG_FILE_1GB.bin bs=1M count=1024
> ein 1GB File mit zufälligem Muster erzeugen und dann dieses File
> auf die SSD loslassen!
> Sollte /dev/shm nicht reichen, weil weniger wie zwei GB RAM
> vorhanden, je nach Modell, dann das File im eMMC erstellen.
>
> Dann den eigentlichen SSD-Write Test starten.
> time $(if=/dev/shm/BIG_FILE_1GB.bin of=/mnt/test/test.tmp bs=4k
> count=256k conv=sync; sync)
>
> Ich selber habe zwei BPi-R2 und etliche Cubiboards mit A20 in meiner
> SBC Sammlung und wäre auch an den Ergebnissen mit Patch interessiert.

Ich hab leider kein MMC, hab nur SD (und die ist bekanntlich langsamer 
als SSD). Und RAM ist bei meinem BPI-R1 und BPI-M1 leider nur 1 GB, 
sonst hätte man das von einer Ramdisk heraus machen können.
Für solche Tests sollte man mind. 2 GB nehmen, damit die Zahlen nicht 
durch sekundäres Caching etc. verfälscht werden.
D.h. ich kann höchstens das mit time hinzunehmen, aber müsste weiterhin 
von /dev/zero einlesen.
Aber aus reiner Neugier heraus werde ich auch testen wie sich die Zahlen 
ändern wenn man direkt von /dev/urandom einliest.

[Markus W. (dl8mby)]

@Mutluit M,

/dev/urandom ist für diesen Zweck zu langsam!!!
Man muss sich vorab damit eine Testdatei mit
zufälligen Werten erzeugen und diese dann an
dd if=TEST_FILE übergeben.

Da Du zu wenig RAM hast, musst du eine kleinere
Datei in /dev/shm erzeugen (z.B. 512MB) und
dann diese in eine loop mit sich ändernden Filenamen
an die SSD schicken.

Siehe Skript:

#! /bin/bash
STARTT=`date +%s`
for i in `seq 1 10`
do
  echo ${i}
  dd if=/dev/shm/TEST_FILE of=/<SSD_Mount>/TEST_FILE_${f} bs=1M
done
sync
STOPT=`date +%s`
echo "$STOPT - $STARTT" | bc -i



Markus

[Torsten S. (tse)]

Also ich habe auch noch 2 BPi hier rumzuliegen. Bei Bedarf kann ich beim 
testen helfen.

[Mutluit M. (mutluit)]

Markus W. schrieb:
> Siehe Skript:
>
> #! /bin/bash
...

Ok, hab jetzt damit auf BPi-R1 getestet und bekomme ca. 105 MB/s raus
(hab den dd in time sh -c "dd ..." eingebettet, und bs=1M wie im obigen 
original belassen).
Da mein /dev/shm nur 502MB gross ist, habe ich /dev/shm/TEST_FILE 256MiB 
gross gemacht, d.h. mittels dd entsprechend aus /dev/urandom gefüllt.
Btw, 268MB unten steht natürlich für 256MiB :-), s.a. 
https://en.wikipedia.org/wiki/Unit_prefix

1
256+0 records in
256+0 records out
268435456 bytes (268 MB) copied, 2.5272 s, 106 MB/s

real  0m2.792s
user  0m0.002s
sys  0m2.770s
2
256+0 records in
256+0 records out
268435456 bytes (268 MB) copied, 2.55158 s, 105 MB/s

real  0m2.958s
user  0m0.000s
sys  0m2.817s
3
256+0 records in
256+0 records out
268435456 bytes (268 MB) copied, 2.56164 s, 105 MB/s

real  0m2.973s
user  0m0.005s
sys  0m2.817s
4
256+0 records in
256+0 records out
268435456 bytes (268 MB) copied, 2.42452 s, 111 MB/s

real  0m2.838s
user  0m0.015s
sys  0m2.686s
5
256+0 records in
256+0 records out
268435456 bytes (268 MB) copied, 2.56256 s, 105 MB/s

real  0m2.967s
user  0m0.000s
sys  0m2.793s
6
256+0 records in
256+0 records out
268435456 bytes (268 MB) copied, 2.4236 s, 111 MB/s

real  0m2.834s
user  0m0.005s
sys  0m2.675s
7
256+0 records in
256+0 records out
268435456 bytes (268 MB) copied, 2.55837 s, 105 MB/s

real  0m2.982s
user  0m0.035s
sys  0m2.780s
8
256+0 records in
256+0 records out
268435456 bytes (268 MB) copied, 2.54243 s, 106 MB/s

real  0m2.939s
user  0m0.005s
sys  0m2.810s
9
256+0 records in
256+0 records out
268435456 bytes (268 MB) copied, 2.58396 s, 104 MB/s

real  0m3.029s
user  0m0.015s
sys  0m2.810s
10
256+0 records in
256+0 records out
268435456 bytes (268 MB) copied, 2.55042 s, 105 MB/s

real  0m2.965s
user  0m0.005s
sys  0m2.824s
bc 1.06.95
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'. 
1557326586 - 1557326557
29

[Mutluit M. (mutluit)]

Torsten S. schrieb:
> Also ich habe auch noch 2 BPi hier rumzuliegen. Bei Bedarf kann ich beim
> testen helfen.

Ich werde in kürze, wahrscheinlich heute Nacht noch, den Patch für 
ahci_sunxi.c posten.
Tester müssten den Patch in ihren eigenen Kerneltree einbinden und so 
einen neuen Kernel generieren.

Man kann auch einen vorkompilierten Kernel für die (A20-) BPi's zur 
Verfügung stellen, aber da gibt's ja auch viele Varianten (uImage, 
zImage, Overlay, initramfs usw. usw.) Ich glaube ich hätte momentan 
nicht die Zeit dazu, aber vlt. kann es jemand anderes dann machen wenn 
mehr Leute interessiert sind die selber keine Kernel-Hacker sind.

[Mutluit M. (mutluit)]

Noch eine Anmerkung zum letzten Test via /dev/shm :
Ich denke es hat einen gewissen Overhead. Wenn man das selbe Prinzip 
über eine Ramdisk macht, dann könnte das Ergebnis evtl. etwas besser 
ausfallen.
Vlt. sollte ich es gleich mal ausprobieren... :-)

[Mutluit M. (mutluit)]

Mutluit M. schrieb:
> Noch eine Anmerkung zum letzten Test via /dev/shm :
> Ich denke es hat einen gewissen Overhead. Wenn man das selbe Prinzip
> über eine Ramdisk macht, dann könnte das Ergebnis evtl. etwas besser
> ausfallen.
> Vlt. sollte ich es gleich mal ausprobieren... :-)

Hab das eben auch getestet: Ergebnis ist gleich, kein Wunder: sowohl 
/dev/shm als auch ramdisk sind ja via tmpfs realisiert...

[Mutluit M. (mutluit)]

Markus W. schrieb:
>
> /dev/urandom ist für diesen Zweck zu langsam!!!
...
> #! /bin/bash
> STARTT=`date +%s`
> for i in `seq 1 10`
> do
>   echo ${i}
>   dd if=/dev/shm/TEST_FILE of=/<SSD_Mount>/TEST_FILE_${f} bs=1M

BUGFIX:
    dd if=/dev/shm/TEST_FILE of=/<SSD_Mount>/TEST_FILE_${i} bs=1M


Wurde für mein Test schon berichtigt.

[Mutluit M. (mutluit)]

Hier noch die abschliessende Mathe dazu:

Die erwähnten 120 MB/s sind für so ein Board wie meinem mit einem Takt 
von 960MHz wohl das Maximum, weil es pro Takt nur 1 Bit 
schickt/empfängt:

960 * 1000^2 * 1 / 8 / 1000^2 = 120.0 MB/s

Wenn die stattdessen Amplitudenmodulation mittels einer DAC und ADC 
eingesetzt hätten, dann könnten mehr Bits pro Takt übertragen/empfangen 
werden und somit eine grössere Bandbreite und Geschwindigkeit wäre 
realisierbar gewesen.

Das wurde auch im Parallelthread diskutiert:
Beitrag "Re: Marke Eigenbau: SoC-Imitat"

Nachtrag: oder die haben ADC/DAC doch noch eingesetzt, dann aber den Bus 
niedriger getaktet, was im Endeffekt aber zum selben Ergebnis wie oben 
geführt hat.

Nachtrag2:
Hmm. passt was nicht, denn Read-Speed liegt ja bei über 200 MB/s...

[Bananensaft (Gast)]

Mutluit M. schrieb:

> Wenn die stattdessen Amplitudenmodulation mittels einer DAC und ADC

He? ADC?

Sollte das nach Beitrag "CPU 300MHz, aber ADC und DAC schaffen 2MSps. Wie nur?" gehen?

[Mutluit M. (mutluit)]

Bananensaft schrieb:
> Mutluit M. schrieb:
>
>> Wenn die stattdessen Amplitudenmodulation mittels einer DAC und ADC
>
> He? ADC?
>
> Sollte das nach Beitrag "CPU 300MHz, aber ADC und DAC schaffen 2MSps. Wie nur?" gehen?

Ich verstehe deine kryptische Frage, oder was das sein soll, leider 
nicht. Kannst du bischen deutlicher formulieren?

[Torsten S. (tse)]

Zugegeben: bin auch irritiert was ADC/DAC mit SATA gemeinsam haben...

[Mutluit M. (mutluit)]

Torsten S. schrieb:
> Zugegeben: bin auch irritiert was ADC/DAC mit SATA gemeinsam haben...

Die Strecke zwischen SATA-Controller (AHCI) auf der Rechnerseite und der 
angeschlossenen Disk auf der anderen Seite stellt sozusagen ein Bus dar.
Da kann man schon Modulationsverfahren einsetzen. Und wenn man das tut, 
dann benutzt man meistens ein DAC/ADC-Paar an beiden Enden. Das tut man 
um mehr als 1 Bit pro Takt zu übertragen.

[Torsten S. (tse)]

Aha, das wußte ich nicht. Wieder was dazu gelernt - vielen für die 
Erläuterung!

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Mutluit M. schrieb:
> Die Strecke zwischen SATA-Controller (AHCI) auf der Rechnerseite und der
> angeschlossenen Disk auf der anderen Seite stellt sozusagen ein Bus dar.
> Da kann man schon Modulationsverfahren einsetzen. Und wenn man das tut,
> dann benutzt man meistens ein DAC/ADC-Paar an beiden Enden. Das tut man
> um mehr als 1 Bit pro Takt zu übertragen.

Macht man bei SATA aber nicht, das ist ganz normales LVDS.

[Markus W. (dl8mby)]

@all,

mit den 10x 256MB Schreiben in 29 Sek.
komme ich mit dem OS Overhead auf knapp
89MB/Sek.

Markus

PS.: Du kannst auch direkt auf die SSD ohne FS
schreiben und zwar nach /dev/sdX, wobei die SSD
mit lsscsi oder fdisk -l identifiziert werden
kann.

Aber dies löscht alles auf der SSD, deshalb Vorsicht!
Liefert dafür aber die reine Schreibgeschwindigkeit
ohne der FS-Treiber Schicht. ( < 10% Gewinn )

[Mutluit M. (mutluit)]

Markus W. schrieb:
> @all,
>
> mit den 10x 256MB Schreiben in 29 Sek.
> komme ich mit dem OS Overhead auf knapp
> 89MB/Sek.

Hmm. die Berechnung so durchzuführen ist IMO nicht korrekt,
weil da Leerlaufzeiten zwischen den Teilläufen sind.

Wenn schon, dann nimm den Durchschnitt der Einzelergebnisse (also alle 
MB/s addieren und durch die Anzahl der Läufe (hier 10) teilen).

Überhaupt finde ich diese doch etwas komplizierte Methode nicht so 
ratsam.
Ich selber werde bei meiner ursprünglichen Methode bleiben.

[Mutluit M. (mutluit)]

Mw E. schrieb:
> Mutluit M. schrieb:
>> Die Strecke zwischen SATA-Controller (AHCI) auf der Rechnerseite und der
>> angeschlossenen Disk auf der anderen Seite stellt sozusagen ein Bus dar.
>> Da kann man schon Modulationsverfahren einsetzen. Und wenn man das tut,
>> dann benutzt man meistens ein DAC/ADC-Paar an beiden Enden. Das tut man
>> um mehr als 1 Bit pro Takt zu übertragen.
>
> Macht man bei SATA aber nicht, das ist ganz normales LVDS.

Ja, kann in der Tat so sein wie du sagst; mir ging es um das allgemeine 
Verständnis, bzw. wie ich selber es gemacht hätte :-)
Danke für die Richtigstellung.

[Mutluit M. (mutluit)]

Gute Nachrichten: hab es endlich auch mit dem BPi-M1 ausgiebig testen 
können und auch da bekommt man so um die 120 MB/s raus beim Write und 
über 200 MB/s beim Read.

Ich habe aber in all meinen eigenen Tests bs=4k benutzt. Wenn ich bs=1M 
benutzen täte, müsste das Ergebnis noch besser werden.
Ich habe 4k Blockgösse benutzt weil das mir realistischer und 
praxisnaher erschien.

Ich werde da an meiner Testmethode jetzt nix mehr ändern, diese Settings 
sind also meine Baseline.


So, jetzt endlich komme ich dazu diesen Patch in die Mailinglist zu 
posten.
Ich geb dann den Link hier bekannt.

[Mutluit M. (mutluit)]

Eine wichtige "Kleinigkeit" habe ich noch festgestellt:
Wenn man folgendes benutzt, dann ist es nicht ganz korrekt:

dd if=/dev/zero of=test.tmp bs=4k count=512k conv=sync

Korrekt ist folgendes:

dd if=/dev/zero of=test.tmp bs=4K count=512K conv=sync

D.h. k versus K:
bei bs=4k sind es nur 4000 Bytes, bei bs=4K sind es 4096 Bytes.
Und gerade die Blockgrösse sollte exakt passen bei solchen Disk-Tests 
(also ein Vielfaches der Sektorgrösse von 512 Bytes sein).

An der Dateigrösse in Bytes (ls -l) kann man den Unterschied sehen.


Nachtrag:
jetzt ist der Write-Speed von 120 MB/s auf ca. 124 MB/s angestiegen! :-)

[Markus W. (dl8mby)]

@Mutluit M

Korrektur zu meinem Skript (-q: quiet bei bc)
echo "$STOPT - $STARTT" | bc -i -q
Erspart einem den bc panner, spart einige ms ;-)

Ob Du nun 124MB/sec. oder 90MB/sec. gelten lest
ist marginal, da Du ja Den Schreibwert mit Deinen
Modifikationen auf jeden Fall mindestens verdoppelt
hast und dass ist ja schon sehr toll.

Der Overhead bei der Messung innerhalb der loop
ist vernachlässigbar. Solange Du mit dd auf ein
Fielsystem schreibst, was Du ja tust, musst Du
auf den Sync warten, sonst stimmen Deine Werte,
die Du misst nicht.
Das OS liefert Dir ein Feedback, dass alle Daten
im Schreibpuffer sind aber Die Disk hat noch kein
ACK geliefert, dass der Schreibvorgang gefinished ist!

Ich will jetzt aber nicht auf den 30MB zu viel
herumreiten. Dieser Wert kann ja noch bei den einzelnen
SBC Boards M1, R2, Cubi+X ... noch etwas abweichen.

Markus

[Mutluit M. (mutluit)]

foobar schrieb:
>
> Evtl vorher mal mit den Sunxi-Typen sprechen - die waren mal auf'm IRC
> aktiv, keine Ahnung ob immer noch.

Ich warte noch auf eine Antwort von Jagan der ja viele der sunxi-Patches 
postet.

IRC ginge bestimmt schneller, hab aber schon seit vielen Jahren nicht 
mehr benutzt, d.h. bin nicht mehr drin in der Materie.

[Mutluit M. (mutluit)]

Markus W. schrieb:
> @Mutluit M
>
> Korrektur zu meinem Skript (-q: quiet bei bc)
> echo "$STOPT - $STARTT" | bc -i -q
> Erspart einem den bc panner, spart einige ms ;-)

ACK, thx.

> Ob Du nun 124MB/sec. oder 90MB/sec. gelten lest
> ist marginal, da Du ja Den Schreibwert mit Deinen
> Modifikationen auf jeden Fall mindestens verdoppelt
> hast und dass ist ja schon sehr toll.
...
> Ich will jetzt aber nicht auf den 30MB zu viel
> herumreiten. Dieser Wert kann ja noch bei den einzelnen
> SBC Boards M1, R2, Cubi+X ... noch etwas abweichen.

Kann man eigentlich irgendwie feststellen welche der vielen Boards 
betroffen wären von diesem Patch der Datei drivers/ata/ahci_sunxi.c ?

[ich (Gast)]

grep über alle sunxi Device Trees:

$ grep -e "^&ahci" sun*
sun4i-a10-a1000.dts:&ahci {
sun4i-a10-cubieboard.dts:&ahci {
sun4i-a10-itead-iteaduino-plus.dts:&ahci {
sun4i-a10-jesurun-q5.dts:&ahci {
sun4i-a10-marsboard.dts:&ahci {
sun4i-a10-olinuxino-lime.dts:&ahci {
sun7i-a20-bananapi.dts:&ahci {
sun7i-a20-bananapi-m1-plus.dts:&ahci {
sun7i-a20-bananapro.dts:&ahci {
sun7i-a20-cubieboard2.dts:&ahci {
sun7i-a20-cubietruck.dts:&ahci {
sun7i-a20-hummingbird.dts:&ahci {
sun7i-a20-itead-ibox.dts:&ahci {
sun7i-a20-lamobo-r1.dts:&ahci {
sun7i-a20-olimex-som-evb.dts:&ahci {
sun7i-a20-olinuxino-lime2.dts:&ahci {
sun7i-a20-olinuxino-lime.dts:&ahci {
sun7i-a20-olinuxino-micro.dts:&ahci {
sun7i-a20-orangepi.dts:&ahci {
sun7i-a20-orangepi-mini.dts:&ahci {
sun7i-a20-pcduino3.dts:&ahci {
sun7i-a20-pcduino3-nano.dts:&ahci {

Das dürfte eine ziemlich gute Liste sein.

[Mutluit M. (mutluit)]

ich schrieb:
> grep über alle sunxi Device Trees:
>
> $ grep -e "^&ahci" sun*

Ja, das ist ja toll. Danke.

[Mutluit M. (mutluit)]

Also, das folgende hat mit der SATA-Thematik nicht viel zu tun, aber ist 
mir beim Testen dessen halt aufgefallen:

Der Banana Pi M1 ist viel kleiner als der Banana Pi R1, jedoch ist seine 
Leerlauf-Temperatur ca. 12°C höher als beim R1:
  R1 ca. 25°C
  M1 ca. 37°C
Dabei haben beide die selbe Software drauf (1:1 Kopie der SD), bis auf 
die individuelle DTB-Datei die beim Booten durch u-boot geladen wird.
Kühlkörper oder sonstige Kühlung hängt bei keinem der Boards.

Es handelt sich um die folgenden DTB:
  M1: sun7i-a20-bananapi.dtb
  R1: sun7i-a20-lamobo-r1.dtb

Und kernel ist 5.0.5.

Liegt es wohl eher an der HW selbst, oder doch vlt. an der SW?
Wie könnte man da eine entsprechende Diagnose am besten durchführen?

[Mutluit M. (mutluit)]

ich schrieb:
> grep über alle sunxi Device Trees:
>
> $ grep -e "^&ahci" sun*
> sun4i-a10-a1000.dts:&ahci {
...
> sun7i-a20-pcduino3-nano.dts:&ahci {
>
> Das dürfte eine ziemlich gute Liste sein.

Hier auch eine Liste von A10- und A20-Geräten mit SATA:
http://linux-sunxi.org/Category:Devices_with_SATA_port

[Torsten S. (tse)]

Mutluit M. schrieb:
> Der Banana Pi M1 ist viel kleiner als der Banana Pi R1, jedoch ist seine
> Leerlauf-Temperatur ca. 12°C höher als beim R1:

Beim Bananapi M1 ist der SOC dummerweise auf der Platinenunterseite und 
hat deswegen Probleme seine Abwärme abzuführen. Ärgerlich.

[Mutluit M. (mutluit)]

Hier ist ein interessantes YT-Video (engl.) von dem Linux-Guru Greg 
Kroah-Hartman, worin erklärt wird, wie man einen Kernel-Patch formell 
einzureichen hat; man muss sich an einige Regeln halten:
https://www.youtube.com/watch?v=LLBrBBImJt4

[Mutluit M. (mutluit)]

Torsten S. schrieb:
> Mutluit M. schrieb:
>> Der Banana Pi M1 ist viel kleiner als der Banana Pi R1, jedoch ist seine
>> Leerlauf-Temperatur ca. 12°C höher als beim R1:
>
> Beim Bananapi M1 ist der SOC dummerweise auf der Platinenunterseite und
> hat deswegen Probleme seine Abwärme abzuführen. Ärgerlich.

Ja, echt schade. Muss ich dann Kühlkörper draufkleben.
(Aber den M1 hatte ich mir nur zum Testen günstig bei ebay ersteigert.
Ich mach mein Zeugs lieber auf den R1's (hab 2 davon)).

[Torsten S. (tse)]

Dreh' ihn doch einfach um ;)

[Mutluit M. (mutluit)]

Torsten S. schrieb:
> Dreh' ihn doch einfach um ;)

Ja, auf diese brilliante Idee muss man erstmal kommen... :-)

[foobar (Gast)]

Nochmal: bevor du groß anfängst, Patches zu erstellen, frag auf der 
linux-sunxi Mailing-List erstmal nach, ob deine Änderung überhaupt 
sinnvoll ist.  Aus deinen bisherigen Artikeln schließe ich, dass es sich 
eher um ein paar Tweaks handelt und nicht um grundlegende Systemumbauten 
(Details nennst du ja nicht).  Es wird einen Grund geben, warum die 
Sachen so sind, wie sie sind und deine Änderungen evtl nie akzeptiert 
werden.  Sprich es doch vorher einfach mal an - dazu ist die 
Mailing-Liste da!

[Mutluit M. (mutluit)]

foobar schrieb:
> Nochmal: bevor du groß anfängst, Patches zu erstellen, frag auf der
> linux-sunxi Mailing-List erstmal nach, ob deine Änderung überhaupt
> sinnvoll ist.

Ist doch offensichtlich dass es sinnvoll ist: seit Anbeginn vor ca. 5 
Jahren beschweren sich die User über die langsame 
HDD/SSD-Geschwindigkeit bei den Allwinner-SoCs.
Als ich vor einigen Monaten in Berührung kam mit diesen SoCs, dachte ich 
mir sofort dass das ein SW-Problem sein könnte und hatte mich auf die 
Suche gemacht und nach einigen Wochen des Studiums von SATA und AHCI 
habe ich eine Lösung gefunden. Ich habe Allwinner um SATA-Dokumentation 
gebeten (Vendor Specific Ports) und sie auch von meinem Patch und der 
besagten Performancesteigerung informiert, aber bin wohl an ein Paar 
BWL-Hohlköpfe dort geraten, die die Bedeutung gar nicht kapiert haben; 
die meinten lapidar A20 sei nicht mehr aktuell... Ach was soll's.

> Aus deinen bisherigen Artikeln schließe ich, dass es sich
> eher um ein paar Tweaks handelt und nicht um grundlegende Systemumbauten
> (Details nennst du ja nicht).  Es wird einen Grund geben, warum die
> Sachen so sind, wie sie sind und deine Änderungen evtl nie akzeptiert
> werden.

Ach was soll's.
Mit dem Einreichen hätte ich meine Schuldigkeit getan. Das reicht mir.

> Sprich es doch vorher einfach mal an - dazu ist die Mailing-Liste da!

Ist doch auch so angedacht: als "RFC PATCH" (Request for Comments).

[Mutluit M. (mutluit)]

Der Patch geht heute Nacht definitiv raus! Grosses Indianer-Ehrenwort! 
:-)

Ich bin aber sozusagen in allerletzter Minute bevor ich es posten wollte 
auf eine evtl. weitere und interressante Verbesserungsmöglichkeit 
gestossen, und bin gerade dabei das auch noch zu testen.


Und: ich habe mein Kernel-Tree aktualisiert, so dass ich das eben auch 
mit dem allerletzten Kernel in der git-repo (5.1.0-rc7) ebenfalls 
erfolgreich getestet habe:

# uname -a
Linux r1-3 5.1.0-rc7-my15 #3 SMP Fri May 10 19:05:06 CEST 2019 armv7l 
GNU/Linux

[Mutluit M. (mutluit)]

Mutluit M. schrieb:
> Der Patch geht heute Nacht definitiv raus! Grosses Indianer-Ehrenwort!
> :-)

Ok, jetzt ist der Patch endlich veröffentlicht:
https://lkml.org/lkml/2019/5/10/600

Ist im Grunde nur eine einzige Zeile in drivers/ata/ahci_sunxi.c .
Aber um die richtigen Werte zu ermitteln musste ich zuvor viele Werte 
ausprobieren. Es sind 4 Felder, jede davon 4 Bits gross, plus ein 5. 
Feld mit 16 Bits, welches aber Reserved ist.

Die folgende Struktur wird im offiziellen Quellcode nicht benutzt; es 
war für mich nur eine Ersatzdarstellung zum leichteren Testen:

struct AHCI_P0DMACR_t
{
  unsigned TXTS  : 4,
           RXTS  : 4,
           TXABL : 4,  
           RXABL : 4,
           Res1  : 16;
};

Die, die sich für die Internas interessieren, können auf dieser Seite 
einen Beitrag von mir zu SATA PortMultiplier finden und darin einen Link 
zu einem SATA-/AHCI-Dokument von Texas Instruments:
http://forum.banana-pi.org/t/sata-port-multiplier-for-bpi-r1/9130/3

Das o.g. Dokument von Texas Instruments (und auch neuere bei denen) hat 
mir sehr geholfen, auch wenn das Dokument nicht ganz das Richtige für 
den SATA-/AHCI-IP-Core in Allwinner SoCs ist. Einen Dank an TI.

Darin nach "P0DMACR" suchen, und in den SATA-/AHCI-Dokumenten von Intel 
nach "PxDMACR" suchen.

Jo, das war's dann von meiner Seite.
Falls noch Fragen gibt, immer her damit.

Ciao

Uenal Mutlu
mutluit.com

[Mutluit M. (mutluit)]

Mit optimierter Blocksize von 12KiB kann man sogar 132MiB/s 
Schreibgeschwindigkeit erreichen.
Details, ein Test-Script und Ergebnisse kann man hier finden:
http://forum.banana-pi.org/t/new-kernel-patch-brings-120mb-s-sata-write-speed-with-banana-pis/9218