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

Do Dez 10 21:01:50 CET 2020

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