<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Am 11.12.20 um 18:09 schrieb Sven
      Hürlimann via tiptoi-hw:<br>
    </div>
    <blockquote type="cite"
      cite="mid:f8b35571-e227-06c4-8c68-5772f1dc4133@sighup.ch">
      <pre class="moz-quote-pre" wrap="">Am 11.12.20 um 17:09 schrieb Björn via tiptoi-hw:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">Hallo Sven,

ich denke langsam wird es klarer.

Hier mal der Versuch einer Beschreibung des Ablaufs von getc(dword
*ziel):

1. Setze RX_TIMEOUT_EN = 1
2. Warte bis RX_TH_INT_STA gesetzt ist
3. inputaddr = 0x0802fabc + die untersten 4 bits von RX_ADDR
4. Wenn die untersten 4 bits von RX_ADDR = 0 sind:
    inputaddr = 0x0802fafc
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">Das erschliesst sich mir noch nicht. 0x0802fafc ist ja weiter oben im
memory als 0x0802fabc.</pre>
    </blockquote>
    <p>Ok. These:</p>
    Wenn RX_TH_INT_STA (ohne RX_TIMEOUT_EN) gesetzt ist, schlägt der
    Threshold an wenn N Words (gesetzt via <code>RX_TH_CNT[</code><code><code>16:12</code>]
      im Register UART_BUF_TRSHLD erreicht wird.</code><br>
    <code></code>
    <p><code><font size="+1">Das heisst nach dem ersten Word ist RX_ADDR
          bereits 1 (bez. ein Offset von vier Bytes). Somit ist die
          inputaddr da bereits 0x802fabc + 4 -> 0x802fac0 (der Anfang
          des Fifo-Buffers)<br>
        </font></code></p>
    <p><code><font size="+1">Wenn aber RX_TIMEOUTR zuschlägt ist RX_ADDR
          noch immer 0, dafür BYT_LEFT >= 0. <br>
        </font></code></p>
    <p><code><font size="+1">Das Konstrukt ist der Wraparound und
          "eigentlich" wird der Buffer im TIMEOUT Mode am Ende gefüllt.
          Der Fifo sieht Sinngemäss so aus:</font></code></p>
    <p><code><font size="+1">0x</font></code>0802fafc (erstes Word,
      RX_ADDR = 0), <code><font size="+1">0x802faC0 (zweites Word
          RX_ADDR = 1), </font></code><code><font size="+1"><code><font
              size="+1">0x802faC4, .... und wieder zurück zum Start.<br>
            </font></code></font></code><br>
      <code><font size="+1"><code><font size="+1"><code><font size="+1">0x802fabc
                  wird vom UART gar nie überschrieben sonder ist nur ein
                  offset von 4 bytes zum Anfang des FiFo, damit die
                  ganze RX_ADDR rechnerei funktioniert<br>
                </font></code></font></code></font></code></p>
    <p> </p>
    <blockquote type="cite"
      cite="mid:f8b35571-e227-06c4-8c68-5772f1dc4133@sighup.ch">
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">5. Setze RX_TH_INT_STA
6. Wenn RX_TIMEROUT nicht gesetzt ist:
    kopiere 4 Bytes ab inputaddr an das beim Aufruf von getc
übergebene Ziel und gib "4" zurück,
    sonst setze RX_TIMEROUT, lese aus BYT_LEFT die Anzahl der Bytes
aus, kopiere diese Anzahl (max. 4) an das beim Aufruf von getc
übergebene Ziel und gib die Anzahl der Zeichen zurück


Wofür dient wohl die Fallunterscheidung nach RX_ADDR ? Und warum wird
erst auf RX_TH_INT_STA = 1 gewartet und RX_TH_INT_STA dann gleich
aktiv auf 1 gesetzt?
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">RX_TH_INT_STA ist write to clear.
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">Grüße
Björn





Am 10.12.2020 um 21:01 schrieb Sven Hürlimann via tiptoi-hw:
</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">Ich versuch mal meine wirren Gedanken zusammen zu fassen (Alle Angaben
ohne Gewähr und viel wildes Raten)

1. Es gibt die Bits TIMEOUT_INT_EN und TIMEOUTR_INT, sowie
[RX|TX]_TH_INT_EN und [RX|TX}_TH_INT_STA
2. Das UART_BUF_TRSHLD Register setzt den Threshold für ..TH_INT_EN.
3. Wenn TIMEOUT_INT_EN asserted der Controller ein ..TH_INT_STA und das
TIMEOUTR_INT bit sobald eine gewisse Zeit verstrichen ist (da ein
Qemu-Model ist das nicht wirklich realtime - viel zu schnell)
4. Wenn ein Threshold gesetzt wurde (in Anzahl Words) generiert der
Controller TH_INT wenn dieser erreicht wurde (dieser ist immer 4 byte
aligned)
5. Das BIOS.bin liest nur über den TIMEOUT-"Modus" und kriegt die Anzahl
Bytes die im Fifo sind über das UART_DATA_CFG Register raus (BYT_LEFT,
bits[24:23]
6. getc() gibt als return Wert entweder eine 0-4 im Timeout-Mode oder
N*4 im Threshold-Modus
7. Mit neuerlichem Setzen des TIMEOUT_INT_EN (oder resetten - write to
clear - des RX_TIMEOUT_STA bits?) wird der Zähler vom Fifo wieder zurück
gesetzt (selbiges für write-to-clear bei ..TH_INT_STA)

Tönt jetzt wahrscheinlich komplett belämmert, aber ich weiss gerade
nicht wie ich das anderst formulieren soll.

Grüsse Sven

Am 10.12.20 um 20:36 schrieb Björn via tiptoi-hw:
</pre>
          <blockquote type="cite">
            <pre class="moz-quote-pre" wrap="">Das ist ja eine sehr gute Nachricht. Herzlichen Glückwunsch!

Ich verstehe dich so, dass beim Einlesen von Adressen immer auf 4
Bytes (Tastendrücke) gewartet wird.
Wo im Code wird der Threshold auf 4 gesetzt und konnten wir das schon
mit einem echten Stift verifizieren?

VG



Am 09.12.2020 um 21:39 schrieb Sven A. Huerlimann via tiptoi-hw:
</pre>
            <blockquote type="cite">
              <pre class="moz-quote-pre" wrap="">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:
</pre>
              <blockquote type="cite">
                <pre class="moz-quote-pre" wrap="">Woooooooooohhhhh...

Sehr schön.

Danke Danke Danke!

Gruss
Shue

On 06.12.20 17:39, Björn via tiptoi-hw wrote:
</pre>
                <blockquote type="cite">
                  <pre class="moz-quote-pre" wrap="">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:
</pre>
                  <blockquote type="cite">
                    <pre class="moz-quote-pre" wrap="">Hallo

On 06.12.20 16:18, Matthias Weber via tiptoi-hw wrote:
</pre>
                    <blockquote type="cite">
                      <pre class="moz-quote-pre" wrap="">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?
</pre>
                    </blockquote>
                    <pre class="moz-quote-pre" wrap="">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.
</pre>
                    <blockquote type="cite">
                      <pre class="moz-quote-pre" wrap="">Oder gibt es eine Referenz-Peripherie, die jetzt doch zu passen
scheint?
</pre>
                    </blockquote>
                    <pre class="moz-quote-pre" wrap="">Eben leider nicht. Daher hab ich den ganzen Block neu geschrieben.
Der
UART ist einfach zu spezifisch.
</pre>
                    <blockquote type="cite">
                      <pre class="moz-quote-pre" wrap="">Und der "Debugger" läuft jetzt zwischen Ghidra und Qemu? Das
heißt reine
Hardware ist nicht im Spiel, oder?
</pre>
                    </blockquote>
                    <pre class="moz-quote-pre" wrap="">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.
</pre>
                    <blockquote type="cite">
                      <pre class="moz-quote-pre" wrap="">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.
</pre>
                    </blockquote>
                    <pre class="moz-quote-pre" wrap="">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

</pre>
                    <blockquote type="cite">
                      <pre class="moz-quote-pre" wrap="">Grüße


Sven A. Huerlimann via tiptoi-hw wrote:
</pre>
                      <blockquote type="cite">
                        <pre class="moz-quote-pre" wrap="">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:
</pre>
                        <blockquote type="cite">
                          <pre class="moz-quote-pre" wrap="">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.

<a class="moz-txt-link-freetext" href="https://github.com/maehw/snowbirdopter/blob/master/snowbirdopter.py#L74">https://github.com/maehw/snowbirdopter/blob/master/snowbirdopter.py#L74</a>


Wartet auch nach jedem Zeichen auf das Echo, bevor es weiter
geht.
Möglicher Workaround?

VG


_______________________________________________
tiptoi-hw mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tiptoi-hw@lists.nomeata.de">tiptoi-hw@lists.nomeata.de</a>
<a class="moz-txt-link-freetext" href="https://lists.nomeata.de/mailman/listinfo/tiptoi-hw">https://lists.nomeata.de/mailman/listinfo/tiptoi-hw</a>
</pre>
                        </blockquote>
                        <pre class="moz-quote-pre" wrap="">
_______________________________________________
tiptoi-hw mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tiptoi-hw@lists.nomeata.de">tiptoi-hw@lists.nomeata.de</a>
<a class="moz-txt-link-freetext" href="https://lists.nomeata.de/mailman/listinfo/tiptoi-hw">https://lists.nomeata.de/mailman/listinfo/tiptoi-hw</a>

</pre>
                      </blockquote>
                      <pre class="moz-quote-pre" wrap="">_______________________________________________
tiptoi-hw mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tiptoi-hw@lists.nomeata.de">tiptoi-hw@lists.nomeata.de</a>
<a class="moz-txt-link-freetext" href="https://lists.nomeata.de/mailman/listinfo/tiptoi-hw">https://lists.nomeata.de/mailman/listinfo/tiptoi-hw</a>
</pre>
                    </blockquote>
                    <pre class="moz-quote-pre" wrap="">

_______________________________________________
tiptoi-hw mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tiptoi-hw@lists.nomeata.de">tiptoi-hw@lists.nomeata.de</a>
<a class="moz-txt-link-freetext" href="https://lists.nomeata.de/mailman/listinfo/tiptoi-hw">https://lists.nomeata.de/mailman/listinfo/tiptoi-hw</a>

</pre>
                  </blockquote>
                  <pre class="moz-quote-pre" wrap="">
_______________________________________________
tiptoi-hw mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tiptoi-hw@lists.nomeata.de">tiptoi-hw@lists.nomeata.de</a>
<a class="moz-txt-link-freetext" href="https://lists.nomeata.de/mailman/listinfo/tiptoi-hw">https://lists.nomeata.de/mailman/listinfo/tiptoi-hw</a>
</pre>
                </blockquote>
                <pre class="moz-quote-pre" wrap="">_______________________________________________
tiptoi-hw mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tiptoi-hw@lists.nomeata.de">tiptoi-hw@lists.nomeata.de</a>
<a class="moz-txt-link-freetext" href="https://lists.nomeata.de/mailman/listinfo/tiptoi-hw">https://lists.nomeata.de/mailman/listinfo/tiptoi-hw</a>
</pre>
              </blockquote>
              <pre class="moz-quote-pre" wrap="">_______________________________________________
tiptoi-hw mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tiptoi-hw@lists.nomeata.de">tiptoi-hw@lists.nomeata.de</a>
<a class="moz-txt-link-freetext" href="https://lists.nomeata.de/mailman/listinfo/tiptoi-hw">https://lists.nomeata.de/mailman/listinfo/tiptoi-hw</a>

</pre>
            </blockquote>
            <pre class="moz-quote-pre" wrap="">

_______________________________________________
tiptoi-hw mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tiptoi-hw@lists.nomeata.de">tiptoi-hw@lists.nomeata.de</a>
<a class="moz-txt-link-freetext" href="https://lists.nomeata.de/mailman/listinfo/tiptoi-hw">https://lists.nomeata.de/mailman/listinfo/tiptoi-hw</a>
</pre>
          </blockquote>
          <pre class="moz-quote-pre" wrap="">
_______________________________________________
tiptoi-hw mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tiptoi-hw@lists.nomeata.de">tiptoi-hw@lists.nomeata.de</a>
<a class="moz-txt-link-freetext" href="https://lists.nomeata.de/mailman/listinfo/tiptoi-hw">https://lists.nomeata.de/mailman/listinfo/tiptoi-hw</a>

</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">

_______________________________________________
tiptoi-hw mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tiptoi-hw@lists.nomeata.de">tiptoi-hw@lists.nomeata.de</a>
<a class="moz-txt-link-freetext" href="https://lists.nomeata.de/mailman/listinfo/tiptoi-hw">https://lists.nomeata.de/mailman/listinfo/tiptoi-hw</a>
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
_______________________________________________
tiptoi-hw mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tiptoi-hw@lists.nomeata.de">tiptoi-hw@lists.nomeata.de</a>
<a class="moz-txt-link-freetext" href="https://lists.nomeata.de/mailman/listinfo/tiptoi-hw">https://lists.nomeata.de/mailman/listinfo/tiptoi-hw</a>
</pre>
    </blockquote>
  </body>
</html>