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

[Sven A. Huerlimann]

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