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

Mi Dez 9 21:39:26 CET 2020

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
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://lists.nomeata.de/pipermail/tiptoi-hw/attachments/20201209/3cdb81fb/attachment.htm>