[Tiptoi-hw] [Thread-Closed] Re: [SPAM] Re: Request for Rubber-Duck: Qemu UART Model -

Fr Dez 11 20:13:47 CET 2020

Am 11.12.20 um 18:09 schrieb Sven Hürlimann via tiptoi-hw:
> Am 11.12.20 um 17:09 schrieb Björn via tiptoi-hw:
>> Hallo Sven,
>>
>> ich denke langsam wird es klarer.
>>
>> Hier mal der Versuch einer Beschreibung des Ablaufs von getc(dword
>> *ziel):
>>
>> 1. Setze RX_TIMEOUT_EN = 1
>> 2. Warte bis RX_TH_INT_STA gesetzt ist
>> 3. inputaddr = 0x0802fabc + die untersten 4 bits von RX_ADDR
>> 4. Wenn die untersten 4 bits von RX_ADDR = 0 sind:
>>     inputaddr = 0x0802fafc
> Das erschliesst sich mir noch nicht. 0x0802fafc ist ja weiter oben im
> memory als 0x0802fabc.

Ok. These:

Wenn RX_TH_INT_STA (ohne RX_TIMEOUT_EN) gesetzt ist, schlägt der
Threshold an wenn N Words (gesetzt via |RX_TH_CNT[|||16:12|] im Register
UART_BUF_TRSHLD erreicht wird.|
||

|Das heisst nach dem ersten Word ist RX_ADDR bereits 1 (bez. ein Offset
von vier Bytes). Somit ist die inputaddr da bereits 0x802fabc + 4 ->
0x802fac0 (der Anfang des Fifo-Buffers)
|

|Wenn aber RX_TIMEOUTR zuschlägt ist RX_ADDR noch immer 0, dafür
BYT_LEFT >= 0.
|

|Das Konstrukt ist der Wraparound und "eigentlich" wird der Buffer im
TIMEOUT Mode am Ende gefüllt. Der Fifo sieht Sinngemäss so aus:|

|0x|0802fafc (erstes Word, RX_ADDR = 0), |0x802faC0 (zweites Word
RX_ADDR = 1), |||0x802faC4, .... und wieder zurück zum Start.
||
|||0x802fabc wird vom UART gar nie überschrieben sonder ist nur ein
offset von 4 bytes zum Anfang des FiFo, damit die ganze RX_ADDR
rechnerei funktioniert
|||

>> 5. Setze RX_TH_INT_STA
>> 6. Wenn RX_TIMEROUT nicht gesetzt ist:
>>     kopiere 4 Bytes ab inputaddr an das beim Aufruf von getc
>> übergebene Ziel und gib "4" zurück,
>>     sonst setze RX_TIMEROUT, lese aus BYT_LEFT die Anzahl der Bytes
>> aus, kopiere diese Anzahl (max. 4) an das beim Aufruf von getc
>> übergebene Ziel und gib die Anzahl der Zeichen zurück
>>
>>
>> Wofür dient wohl die Fallunterscheidung nach RX_ADDR ? Und warum wird
>> erst auf RX_TH_INT_STA = 1 gewartet und RX_TH_INT_STA dann gleich
>> aktiv auf 1 gesetzt?
> RX_TH_INT_STA ist write to clear.
>> Grüße
>> Björn
>>
>>
>>
>>
>>
>> Am 10.12.2020 um 21:01 schrieb Sven Hürlimann via tiptoi-hw:
>>> Ich versuch mal meine wirren Gedanken zusammen zu fassen (Alle Angaben
>>> ohne Gewähr und viel wildes Raten)
>>>
>>> 1. Es gibt die Bits TIMEOUT_INT_EN und TIMEOUTR_INT, sowie
>>> [RX|TX]_TH_INT_EN und [RX|TX}_TH_INT_STA
>>> 2. Das UART_BUF_TRSHLD Register setzt den Threshold für ..TH_INT_EN.
>>> 3. Wenn TIMEOUT_INT_EN asserted der Controller ein ..TH_INT_STA und das
>>> TIMEOUTR_INT bit sobald eine gewisse Zeit verstrichen ist (da ein
>>> Qemu-Model ist das nicht wirklich realtime - viel zu schnell)
>>> 4. Wenn ein Threshold gesetzt wurde (in Anzahl Words) generiert der
>>> Controller TH_INT wenn dieser erreicht wurde (dieser ist immer 4 byte
>>> aligned)
>>> 5. Das BIOS.bin liest nur über den TIMEOUT-"Modus" und kriegt die Anzahl
>>> Bytes die im Fifo sind über das UART_DATA_CFG Register raus (BYT_LEFT,
>>> bits[24:23]
>>> 6. getc() gibt als return Wert entweder eine 0-4 im Timeout-Mode oder
>>> N*4 im Threshold-Modus
>>> 7. Mit neuerlichem Setzen des TIMEOUT_INT_EN (oder resetten - write to
>>> clear - des RX_TIMEOUT_STA bits?) wird der Zähler vom Fifo wieder zurück
>>> gesetzt (selbiges für write-to-clear bei ..TH_INT_STA)
>>>
>>> Tönt jetzt wahrscheinlich komplett belämmert, aber ich weiss gerade
>>> nicht wie ich das anderst formulieren soll.
>>>
>>> Grüsse Sven
>>>
>>> Am 10.12.20 um 20:36 schrieb Björn via tiptoi-hw:
>>>> Das ist ja eine sehr gute Nachricht. Herzlichen Glückwunsch!
>>>>
>>>> Ich verstehe dich so, dass beim Einlesen von Adressen immer auf 4
>>>> Bytes (Tastendrücke) gewartet wird.
>>>> Wo im Code wird der Threshold auf 4 gesetzt und konnten wir das schon
>>>> mit einem echten Stift verifizieren?
>>>>
>>>> VG
>>>>
>>>>
>>>>
>>>> Am 09.12.2020 um 21:39 schrieb Sven A. Huerlimann via tiptoi-hw:
>>>>> Hallo zusammen
>>>>>
>>>>> Ich hab mein UART Problem jetzt gelöst und das Model macht sowas wie
>>>>> UART.
>>>>>
>>>>> Es gibt zwei "Modi" für die UART: Timeout oder Threshold. Im Fall von
>>>>> Threshold werden immer Blöcke von 4 bytes zurück geliefert sobald der
>>>>> konfigurierte Threshold erreicht wird (und die Anzahl der Blöcke im
>>>>> Register UART_DATA_CFG[17:13] gesetzt). Im Fall von Timeout kuckt der
>>>>> BIOS code auf die BYT_LEFT bits in UART_DATA_CFG[24:23] sobald der
>>>>> Timer gefeuert hat.
>>>>>
>>>>> Die Kommandos: dump/setvalue/go funktionieren jetzt wie sie sollen.
>>>>>
>>>>> Danke nochmals für die Unterstützung und das SVD. Das hat das Leben
>>>>> um einiges erleichtet.
>>>>> Next step: Nand-Flash
>>>>>
>>>>> Grüsse Sven
>>>>>
>>>>> On 08.12.20 01:51, Sven A. Huerlimann via tiptoi-hw wrote:
>>>>>> Woooooooooohhhhh...
>>>>>>
>>>>>> Sehr schön.
>>>>>>
>>>>>> Danke Danke Danke!
>>>>>>
>>>>>> Gruss
>>>>>> Shue
>>>>>>
>>>>>> On 06.12.20 17:39, Björn via tiptoi-hw wrote:
>>>>>>> Hallo,
>>>>>>>
>>>>>>> anbei nochmal die letzte Version des SVDs, z. B. für die Nutzung
>>>>>>> mit Ghidra und als "Notizzettel" als CSV.
>>>>>>> Die Bedeutungen der einzelnen Bits ins SCD einzutragen ist relativ
>>>>>>> aufwendig, daher habe ich mich erstmal auf ein paar wenige
>>>>>>> beschränkt.
>>>>>>>
>>>>>>> Die Infos habe ich aus diversen Sourcecode auf Github
>>>>>>> zusammengesucht, insofern muss nicht immer alles stimmen. ;-)
>>>>>>>
>>>>>>> VG
>>>>>>>
>>>>>>>
>>>>>>> Am 06.12.2020 um 16:50 schrieb Sven A. Huerlimann via tiptoi-hw:
>>>>>>>> Hallo
>>>>>>>>
>>>>>>>> On 06.12.20 16:18, Matthias Weber via tiptoi-hw wrote:
>>>>>>>>> Hallo zusammen,
>>>>>>>>>
>>>>>>>>> ich tue mir immer noch schwer - aber ich stecke gerade auch
>>>>>>>>> nicht zu
>>>>>>>>> tief drin.
>>>>>>>>>
>>>>>>>>> Verstehe ich es richtig, dass ihr/du Hardware-Verhalten aus dem
>>>>>>>>> Boot ROM
>>>>>>>>> Code abgeleitet habt?
>>>>>>>> Halb/Halb.. Gewisse Infos (Register-Bits, etc.) sind im
>>>>>>>> Linux-Kernel und
>>>>>>>> der Firmware für den AK10XX ersichtlich (Wobei diese Infos mit
>>>>>>>> Vorsicht
>>>>>>>> zu geniessen sind) - Beides auf Github verfügbar.
>>>>>>>>> Oder gibt es eine Referenz-Peripherie, die jetzt doch zu passen
>>>>>>>>> scheint?
>>>>>>>> Eben leider nicht. Daher hab ich den ganzen Block neu geschrieben.
>>>>>>>> Der
>>>>>>>> UART ist einfach zu spezifisch.
>>>>>>>>> Und der "Debugger" läuft jetzt zwischen Ghidra und Qemu? Das
>>>>>>>>> heißt reine
>>>>>>>>> Hardware ist nicht im Spiel, oder?
>>>>>>>> Genau.. Qemu macht die Emulation, gdb connected zu Qemu und Ghidra
>>>>>>>> und
>>>>>>>> stepped das Model und gibt den aktuellen Zustand an Ghidra weiter.
>>>>>>>> Ghidra zeigt lediglich an.
>>>>>>>>> Ich kann nur anbieten Experimente auf der echten Hardware
>>>>>>>>> durchzuführen.
>>>>>>>>> Aus dem UART Boot Kontext können wir ja beliebigen Code
>>>>>>>>> ausführen. Aus
>>>>>>>>> den GMEs habe ich ja auch Probleme mit dem UART - der scheint
>>>>>>>>> sich da
>>>>>>>>> anders zu verhalten, vielleicht aber auch, weil die Pins zu
>>>>>>>>> normalen
>>>>>>>>> GPIOs umkonfiguriert und nur noch so benutzt werden.
>>>>>>>> Interessant wäre auf der HW mal zu schauen was passiert wenn:
>>>>>>>>
>>>>>>>> 1. Nach dem BIOS Prompt:
>>>>>>>>
>>>>>>>> - Einfach eine Taste gedrückt wird (und dann warten)
>>>>>>>> - Schnell!!! hintereinander Tasten gedrückt werden (also
>>>>>>>> SchnellSchnell... müsste man wohl via Python/Script machen)
>>>>>>>>
>>>>>>>> 2. Nach akzeptiertem Kommando (z.B: "dump")
>>>>>>>> - Einfach eine Taste gedrückt wird (und dann warten) - wird diese
>>>>>>>> geechoed auf der Konsole oder erst nach vier Tastendrücken?
>>>>>>>> - Schnell hintereintander Tasten gedrückt werden..
>>>>>>>>
>>>>>>>> Da mal ein paar Tests machen wär super!
>>>>>>>>
>>>>>>>> Gruss Sven
>>>>>>>>
>>>>>>>>> Grüße
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Sven A. Huerlimann via tiptoi-hw wrote:
>>>>>>>>>> Auf die Gefahr hin euch zu nerven:
>>>>>>>>>>
>>>>>>>>>> Ich bau ein Simulations-Model für Qemu. Damit liesse sich
>>>>>>>>>> jeglicher Code
>>>>>>>>>> in einer Emulation ausführen, es kann ein Debugger angeflanscht
>>>>>>>>>> werden
>>>>>>>>>> und es gibt eine Bridge zu Ghidra.
>>>>>>>>>>
>>>>>>>>>> Im Moment arbeite ich am UART (offensichtlich).. Das heisst ich
>>>>>>>>>> versuche
>>>>>>>>>> den "Chip"/den Controller in Software abzubilden. Als Testcase
>>>>>>>>>> dient mir
>>>>>>>>>> das unveränderte Chomptech-Bootrom (BIOS.bin).
>>>>>>>>>>
>>>>>>>>>> Und da hab ich jetzt das Verhalten:
>>>>>>>>>>
>>>>>>>>>> Wärend des command prompts ruft die Software getc(uint32_t*
>>>>>>>>>> data) auf um
>>>>>>>>>> einzelne Bytes abzufragen und ignoriert den Return-Wert.
>>>>>>>>>>
>>>>>>>>>> Wenn aber ein Kommando akzeptiert wurde (go/dump/etc..) erwartet
>>>>>>>>>> der
>>>>>>>>>> Parser plötzlich ein ganzes Word (4 bytes) und der Return-Wert
>>>>>>>>>> ist
>>>>>>>>>> relevant.
>>>>>>>>>>
>>>>>>>>>> Ich sehe nicht wo die Unterscheidung gemacht wird und wie, dass
>>>>>>>>>> getc(..)
>>>>>>>>>> bereits nach einem Byte empfangen returned (Controller hat
>>>>>>>>>> Interrupt
>>>>>>>>>> gefeuert) oder bis vier Bytes wartet (Controller feuert erst
>>>>>>>>>> wenn Buffer
>>>>>>>>>> 4 bytes gross)
>>>>>>>>>>
>>>>>>>>>> Ich sehe bei der Initialisierung des UART durch BIOS.bin-Code
>>>>>>>>>> keinen
>>>>>>>>>> Unterschied und daher weiss ich nicht wie ich das im Model
>>>>>>>>>> abbilden soll.
>>>>>>>>>>
>>>>>>>>>> Grüsse
>>>>>>>>>> Shue
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 05.12.20 18:48, Matthias Weber via tiptoi-hw wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> ich kann glaube ich auch nicht ganz folgen, leider.
>>>>>>>>>>>
>>>>>>>>>>> Aber kannst du nicht Delays einfügen zwischen jedem Zeichen?
>>>>>>>>>>>
>>>>>>>>>>> Stimmt schon, ich entsinne mich grob, dass ich die Zeichen aus
>>>>>>>>>>> einem
>>>>>>>>>>> Terminal-Fenster glaube ich auch einzeln schicken musste,
>>>>>>>>>>> dass es
>>>>>>>>>>> funktioniert.
>>>>>>>>>>>
>>>>>>>>>>> https://github.com/maehw/snowbirdopter/blob/master/snowbirdopter.py#L74
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Wartet auch nach jedem Zeichen auf das Echo, bevor es weiter
>>>>>>>>>>> geht.
>>>>>>>>>>> Möglicher Workaround?
>>>>>>>>>>>
>>>>>>>>>>> VG
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> tiptoi-hw mailing list
>>>>>>>>>>> tiptoi-hw at lists.nomeata.de
>>>>>>>>>>> https://lists.nomeata.de/mailman/listinfo/tiptoi-hw
>>>>>>>>>> _______________________________________________
>>>>>>>>>> tiptoi-hw mailing list
>>>>>>>>>> tiptoi-hw at lists.nomeata.de
>>>>>>>>>> https://lists.nomeata.de/mailman/listinfo/tiptoi-hw
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> tiptoi-hw mailing list
>>>>>>>>> tiptoi-hw at lists.nomeata.de
>>>>>>>>> https://lists.nomeata.de/mailman/listinfo/tiptoi-hw
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> tiptoi-hw mailing list
>>>>>>>> tiptoi-hw at lists.nomeata.de
>>>>>>>> https://lists.nomeata.de/mailman/listinfo/tiptoi-hw
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> tiptoi-hw mailing list
>>>>>>> tiptoi-hw at lists.nomeata.de
>>>>>>> https://lists.nomeata.de/mailman/listinfo/tiptoi-hw
>>>>>> _______________________________________________
>>>>>> tiptoi-hw mailing list
>>>>>> tiptoi-hw at lists.nomeata.de
>>>>>> https://lists.nomeata.de/mailman/listinfo/tiptoi-hw
>>>>> _______________________________________________
>>>>> tiptoi-hw mailing list
>>>>> tiptoi-hw at lists.nomeata.de
>>>>> https://lists.nomeata.de/mailman/listinfo/tiptoi-hw
>>>>>
>>>>
>>>> _______________________________________________
>>>> tiptoi-hw mailing list
>>>> tiptoi-hw at lists.nomeata.de
>>>> https://lists.nomeata.de/mailman/listinfo/tiptoi-hw
>>> _______________________________________________
>>> tiptoi-hw mailing list
>>> tiptoi-hw at lists.nomeata.de
>>> https://lists.nomeata.de/mailman/listinfo/tiptoi-hw
>>>
>>
>> _______________________________________________
>> tiptoi-hw mailing list
>> tiptoi-hw at lists.nomeata.de
>> https://lists.nomeata.de/mailman/listinfo/tiptoi-hw
> _______________________________________________
> tiptoi-hw mailing list
> tiptoi-hw at lists.nomeata.de
> https://lists.nomeata.de/mailman/listinfo/tiptoi-hw
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://lists.nomeata.de/pipermail/tiptoi-hw/attachments/20201211/ef9e8866/attachment.htm>