[Tiptoi-hw] Request for Rubber-Duck: Qemu UART Model
Sven A. Huerlimann
sh at sighup.ch
Sa Dez 5 16:29:09 CET 2020
Kaffee hat geholfen (ein bisschen)
Im Fall von read_addr:
uint32_t data;
uint32_t bytes_read = getc(&data); // returns always 4
uint32_t counter = 0;
while (counter < bytes_read) {
uint8_t c = (data >> (counter * 8)) & 0xFF;
...
count += 1;
}
Im Fall vom Einlesen des Kommands wird der Return-Wert von getc einfach
ignoriert und nur ein Byte angeschaut.
Damit lässt sich meine Frage erneut umformulieren:
Wie wird entschieden, ob bereits nach einem Byte oder erst nach einem
ganzen Wort (4 bytes) RX_TH_INT_STA gezündet wird und getc returned? Das
muss irgendwie mit diesen Timeout Flags zusammenhängen.
Gruss Sven
On 05.12.20 15:29, Sven A. Huerlimann via tiptoi-hw wrote:
> Da klickts bei mir eben genau noch nicht...
>
> Ich kriegs nicht hin. Bei character = data >> ((counter & 0x1f) << 3) &
> 0xff; (~0x1698) wird doch irgendwas gestückelt?
>
> Ich brauch nochmals einen Kaffee.
>
>
> uint32_t getc(uint32_t *puParm1)
> {
> undefined4 *local_24;
>
> _DAT_04036000 = _DAT_04036000 | 0x800000; // Set RX_TIMEOUT_EN
> do {
> } while ((_DAT_04036004 & 0x40000000) == 0); // Wait for RX_TH_INT_STA
> local_24 = (undefined4 *)(&DAT_0802fabc + (_DAT_04036008 >> 0xd & 0xf)
> * 4);
> if (local_24 == (undefined4 *)&DAT_0802fabc) {
> local_24 = (undefined4 *)&DAT_0802fafc;
> }
> _DAT_04036004 = 0x40000000; // Clear RX_TH_INT_STA
> *puParm1 = *local_24;
> return 4; // TADAA!!!! return number of bytes read?
> }
>
> Und jup:
>
> undefined4 read_addr(uint32_t default,uint32_t *dest)
>
> {
> uint uVar1;
> undefined4 uVar2;
> int intvalue;
> uint character;
> uint result;
> uint counter;
> uint local_28;
> uint nibble_counter;
> uint data;
>
> data = 0;
> nibble_counter = 0;
> local_28 = 0;
> result = 0;
> do {
> uVar1 = getc(&data);
> counter = 0;
> while (counter < uVar1) {
> /* c = value >> ((count & 0x1f) * 8)) & 0xff
> if(c == '\r') {
> .. */
> character = data >> ((counter & 0x1f) << 3) & 0xff;
> /* carriage return */
> if (character == 0xd) {
> if (nibble_counter == 0) {
> putc(0xd);
> /* on simple enter pressed -> return default */
> *dest = default;
> uVar2 = 1;
> }
> else {
> putc(0xd);
> if (local_28 == 0) {
> *dest = result;
> uVar2 = 1;
> }
> else {
> uVar2 = 0;
> }
> }
> return uVar2;
> }
> /* backspace */
> if (character == 8) {
> /* remove last result */
> if (nibble_counter != 0) {
> local_28 = local_28 & ~(1 << (nibble_counter & 0xff));
> nibble_counter = nibble_counter - 1;
> result = result & ~(0xf << ((7 - nibble_counter) * 4 & 0xff));
> }
> /* clean out character by sending bs, space, bs */
> putc(8);
> putc(0x20);
> putc(8);
> }
> else {
> intvalue = ascii2int(character);
> if (intvalue == 0xff) {
> local_28 = 1 << (nibble_counter & 0xff);
> }
> result = result | intvalue << ((7 - nibble_counter) * 4 & 0xff);
> putc(character);
> nibble_counter = nibble_counter + 1;
> if (8 < nibble_counter) {
> return 0;
> }
> }
> counter = counter + 1;
> }
> } while( true );
> }
>
>
> On 05.12.20 15:15, Björn via tiptoi-hw wrote:
>> Zu 2:
>> Was genau meinst Du mit "die FW"? Die Routine zur Eingabe einer
>> Addresse (ab 0x1628) liest meiner Meinung nach mittels getc ganz
>> normal die Tastendrücke ein und setzt sie einen nach dem anderen zu
>> einem Gesamtwert zusammen (im Bereich von 0x17cc).
>>
>> RX_TH_INT_STA verhält sich also nicht anders als sonst.
>>
>> Viele Grüße
>> Björn
>>
>>
>> Am 05.12.2020 um 14:32 schrieb Sven A. Huerlimann via tiptoi-hw:
>>> Sorry, war schon spät, gestern..
>>>
>>> Ich versuch die Frage/das Problem genauer zu beschreiben:
>>>
>>> 1.
>>>
>>> Genau: Die getc impl wartet auf RX_TH_INT_STA und returned dann. Der
>>> aufrufende Code nimmt dann die Daten aus dem RAM-Buffer. Das funzt für
>>> die Eingabe der "Kommandos", da diese immer nur ein Byte lesen per
>>> Aufruf (wie man es von getc erwarten würde)
>>>
>>> Das lässt sich einfach modelieren: Sobald im Qemu ein Tastendruck
>>> daherkommt -> RX_TH_INT_STA = 1 und Position im Fifo immer 0
>>>
>>> 2.
>>>
>>> Die Parameter werden jedoch anders eingelesen. Der Code läuft immernoch
>>> über getc, jedoch erwartet die FW diesesmal 4 bytes an Daten. Also
>>> RX_TH_INT_STA erst high nach vier Tastendrücken und RX_ADDR/BYT_LEFT in
>>> REG_UART_DATA_CONFIG wird hochgezählt.
>>>
>>> Problem:
>>>
>>> Wenn ich RX_TH_INT_STA erst nach 4 bytes asserte, funktioniert die
>>> Kommandoeingabe nicht mehr, da diese Byte-Wise reingestückelt
>>> bekommen will.
>>> Wenn ich RX_TH_INT_STA bereits beim ersten Byte asserte, funktioniert
>>> das lesen der Parameter nicht, da diese dann Blöcke von 4bytes abbekommt
>>> wo nur ein byte gesetzt ist -> Parse Err.
>>>
>>> Verdacht:
>>>
>>> Es gibt die Register: RX_TIMEROUT (in CFG2) und RX_TIMEOUT_EN (CFG1),
>>> die scheinen etwas damit zu tun zu haben, wann RX_TH_INT_STA (unabhängig
>>> von der Datenmenge) gezündet wird.
>>>
>>> Ich kann mir das alles noch nicht ganz zusammensetzen.
>>>
>>> Gruss Sven
>>>
>>> On 05.12.20 12:28, Björn via tiptoi-hw wrote:
>>>> Gruezi Shue,
>>>>
>>>> ich bin nicht sicher, ob ich deine Frage richtig verstanden habe, aber
>>>> wird bei der Eingabe nicht einfach auf einen UART-Interrupt gewartet
>>>> (RX_TH_INT_STA (Bit 30) = 1 in REG_UART_CONFIG_2 (0x4036004) und dann
>>>> aus dem RAM der eingegebene Wert geholt? Oder welche Timeouts meinst
>>>> du?
>>>>
>>>>
>>>> Am 05.12.2020 um 02:21 schrieb Sven A. Huerlimann via tiptoi-hw:
>>>>> Gruezi
>>>>>
>>>>> Ich bin ein bisschen am verzweifeln mit dem UART. (Steinigt mich: Im
>>>>> letzten Mail noch grosskotzig: "Die Register kennen wir.. blah blah..
>>>>> Fingerübung")
>>>>> Leider nein.
>>>>>
>>>>> Was ich habe (wieder mit Video) https://youtu.be/hXsxpUkm0ag ... ich
>>>>> werd noch zum Vlogger *facepalm*
>>>>>
>>>>> Probleme:
>>>>>
>>>>> - Der verflixte UART Controller hat seine FIFO im L2-Mem, die UART
>>>>> RX/TX
>>>>> Daten gehen also einmal durch 0x080XXXXX Addressen und werden dann vom
>>>>> Controller geschaufelt.
>>>>> - Es gibt eine Art "Timeout"-Modus, wo der Controller nach einer
>>>>> gewissen Zeit ein (oder kein?) Wert zurückmeldet.
>>>>>
>>>>> Die Kommandos (dump/go/setvalue/...) werden einfach byte für byte
>>>>> eingelesen (mit Timer gesetzt), aber die Addressen in den Parametern
>>>>> sind dann wieder Blöcke von 4 bytes (bez. dem ganzen Fifo - und ohne
>>>>> Timeout)
>>>>>
>>>>> Fragen:
>>>>>
>>>>> - Was ist dieser Timeout? Warum?
>>>>> - Wie weiss die CPU ob da jetzt Daten sind im Fifo oder nicht?
>>>>>
>>>>> Ich schnalls nicht.. Hat jemand schonmal so einen UART Controller
>>>>> unter
>>>>> den Fingern gehabt? Kann ja nicht irgend ein neuartiges Konzept sein.
>>>>> Für jeden Ratschlag dankbar.
>>>>>
>>>>> Grüsse
>>>>>
>>>>> Shue
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
Mehr Informationen über die Mailingliste tiptoi-hw