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

Fr Dez 11 18:09:32 CET 2020

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