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

Do Dez 10 20:36:32 CET 2020

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
> 