[Tiptoi-hw] Request for Rubber-Duck: Qemu UART Model
Sven A. Huerlimann
sh at sighup.ch
Sa Dez 5 15:29:21 CET 2020
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
Mehr Informationen über die Mailingliste tiptoi-hw