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

[Sven A. Huerlimann]

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