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

Fr Dez 11 17:09:19 CET 2020

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
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?

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
> 