<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hallo zusammen</p>
    <p>Ich hab mein UART Problem jetzt gelöst und das Model macht sowas
      wie UART.</p>
    <p>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.</p>
    <p>Die Kommandos: dump/setvalue/go funktionieren jetzt wie sie
      sollen.</p>
    <p>Danke nochmals für die Unterstützung und das SVD. Das hat das
      Leben um einiges erleichtet.<br>
      Next step: Nand-Flash<br>
    </p>
    <p>Grüsse Sven</p>
    <div class="moz-cite-prefix">On 08.12.20 01:51, Sven A. Huerlimann
      via tiptoi-hw wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:49c1c28e-60e8-5452-67f2-dd4ba2768f34@sighup.ch">
      <p>Woooooooooohhhhh...</p>
      <p>Sehr schön.</p>
      <p>Danke Danke Danke!</p>
      <p>Gruss<br>
        Shue</p>
      <div class="moz-cite-prefix">On 06.12.20 17:39, Björn via
        tiptoi-hw wrote:<br>
      </div>
      <blockquote type="cite"
        cite="mid:d7cf45c1-990d-75cb-6e1d-098ec9254c93@online.de">Hallo,
        <br>
        <br>
        anbei nochmal die letzte Version des SVDs, z. B. für die Nutzung
        mit Ghidra und als "Notizzettel" als CSV. <br>
        Die Bedeutungen der einzelnen Bits ins SCD einzutragen ist
        relativ aufwendig, daher habe ich mich erstmal auf ein paar
        wenige beschränkt. <br>
        <br>
        Die Infos habe ich aus diversen Sourcecode auf Github
        zusammengesucht, insofern muss nicht immer alles stimmen. ;-) <br>
        <br>
        VG <br>
        <br>
        <br>
        Am 06.12.2020 um 16:50 schrieb Sven A. Huerlimann via tiptoi-hw:
        <br>
        <blockquote type="cite">Hallo <br>
          <br>
          On 06.12.20 16:18, Matthias Weber via tiptoi-hw wrote: <br>
          <blockquote type="cite">Hallo zusammen, <br>
            <br>
            ich tue mir immer noch schwer - aber ich stecke gerade auch
            nicht zu <br>
            tief drin. <br>
            <br>
            Verstehe ich es richtig, dass ihr/du Hardware-Verhalten aus
            dem Boot ROM <br>
            Code abgeleitet habt? <br>
          </blockquote>
          Halb/Halb.. Gewisse Infos (Register-Bits, etc.) sind im
          Linux-Kernel und <br>
          der Firmware für den AK10XX ersichtlich (Wobei diese Infos mit
          Vorsicht <br>
          zu geniessen sind) - Beides auf Github verfügbar. <br>
          <blockquote type="cite"> <br>
            Oder gibt es eine Referenz-Peripherie, die jetzt doch zu
            passen scheint? <br>
          </blockquote>
          Eben leider nicht. Daher hab ich den ganzen Block neu
          geschrieben. Der <br>
          UART ist einfach zu spezifisch. <br>
          <blockquote type="cite"> <br>
            Und der "Debugger" läuft jetzt zwischen Ghidra und Qemu? Das
            heißt reine <br>
            Hardware ist nicht im Spiel, oder? <br>
          </blockquote>
          Genau.. Qemu macht die Emulation, gdb connected zu Qemu und
          Ghidra und <br>
          stepped das Model und gibt den aktuellen Zustand an Ghidra
          weiter. <br>
          Ghidra zeigt lediglich an. <br>
          <blockquote type="cite"> <br>
            Ich kann nur anbieten Experimente auf der echten Hardware
            durchzuführen. <br>
            Aus dem UART Boot Kontext können wir ja beliebigen Code
            ausführen. Aus <br>
            den GMEs habe ich ja auch Probleme mit dem UART - der
            scheint sich da <br>
            anders zu verhalten, vielleicht aber auch, weil die Pins zu
            normalen <br>
            GPIOs umkonfiguriert und nur noch so benutzt werden. <br>
          </blockquote>
          <br>
          Interessant wäre auf der HW mal zu schauen was passiert wenn:
          <br>
          <br>
          1. Nach dem BIOS Prompt: <br>
          <br>
          - Einfach eine Taste gedrückt wird (und dann warten) <br>
          - Schnell!!! hintereinander Tasten gedrückt werden (also <br>
          SchnellSchnell... müsste man wohl via Python/Script machen) <br>
          <br>
          2. Nach akzeptiertem Kommando (z.B: "dump") <br>
          - Einfach eine Taste gedrückt wird (und dann warten) - wird
          diese <br>
          geechoed auf der Konsole oder erst nach vier Tastendrücken? <br>
          - Schnell hintereintander Tasten gedrückt werden.. <br>
          <br>
          Da mal ein paar Tests machen wär super! <br>
          <br>
          Gruss Sven <br>
          <br>
          <blockquote type="cite"> <br>
            Grüße <br>
            <br>
            <br>
            Sven A. Huerlimann via tiptoi-hw wrote: <br>
            <blockquote type="cite">Auf die Gefahr hin euch zu nerven: <br>
              <br>
              Ich bau ein Simulations-Model für Qemu. Damit liesse sich
              jeglicher Code <br>
              in einer Emulation ausführen, es kann ein Debugger
              angeflanscht werden <br>
              und es gibt eine Bridge zu Ghidra. <br>
              <br>
              Im Moment arbeite ich am UART (offensichtlich).. Das
              heisst ich versuche <br>
              den "Chip"/den Controller in Software abzubilden. Als
              Testcase dient mir <br>
              das unveränderte Chomptech-Bootrom (BIOS.bin). <br>
              <br>
              Und da hab ich jetzt das Verhalten: <br>
              <br>
              Wärend des command prompts ruft die Software
              getc(uint32_t* data) auf um <br>
              einzelne Bytes abzufragen und ignoriert den Return-Wert. <br>
              <br>
              Wenn aber ein Kommando akzeptiert wurde (go/dump/etc..)
              erwartet der <br>
              Parser plötzlich ein ganzes Word (4 bytes) und der
              Return-Wert ist <br>
              relevant. <br>
              <br>
              Ich sehe nicht wo die Unterscheidung gemacht wird und wie,
              dass getc(..) <br>
              bereits nach einem Byte empfangen returned (Controller hat
              Interrupt <br>
              gefeuert) oder bis vier Bytes wartet (Controller feuert
              erst wenn Buffer <br>
              4 bytes gross) <br>
              <br>
              Ich sehe bei der Initialisierung des UART durch
              BIOS.bin-Code keinen <br>
              Unterschied und daher weiss ich nicht wie ich das im Model
              abbilden soll. <br>
              <br>
              Grüsse <br>
              Shue <br>
              <br>
              <br>
              On 05.12.20 18:48, Matthias Weber via tiptoi-hw wrote: <br>
              <blockquote type="cite">Hi, <br>
                <br>
                ich kann glaube ich auch nicht ganz folgen, leider. <br>
                <br>
                Aber kannst du nicht Delays einfügen zwischen jedem
                Zeichen? <br>
                <br>
                Stimmt schon, ich entsinne mich grob, dass ich die
                Zeichen aus einem <br>
                Terminal-Fenster glaube ich auch einzeln schicken
                musste, dass es <br>
                funktioniert. <br>
                <br>
                <a class="moz-txt-link-freetext"
href="https://github.com/maehw/snowbirdopter/blob/master/snowbirdopter.py#L74"
                  moz-do-not-send="true">https://github.com/maehw/snowbirdopter/blob/master/snowbirdopter.py#L74</a>
                <br>
                Wartet auch nach jedem Zeichen auf das Echo, bevor es
                weiter geht. <br>
                Möglicher Workaround? <br>
                <br>
                VG <br>
                <br>
                <br>
                _______________________________________________ <br>
                tiptoi-hw mailing list <br>
                <a class="moz-txt-link-abbreviated"
                  href="mailto:tiptoi-hw@lists.nomeata.de"
                  moz-do-not-send="true">tiptoi-hw@lists.nomeata.de</a>
                <br>
                <a class="moz-txt-link-freetext"
                  href="https://lists.nomeata.de/mailman/listinfo/tiptoi-hw"
                  moz-do-not-send="true">https://lists.nomeata.de/mailman/listinfo/tiptoi-hw</a>
                <br>
              </blockquote>
              <br>
              <br>
              _______________________________________________ <br>
              tiptoi-hw mailing list <br>
              <a class="moz-txt-link-abbreviated"
                href="mailto:tiptoi-hw@lists.nomeata.de"
                moz-do-not-send="true">tiptoi-hw@lists.nomeata.de</a> <br>
              <a class="moz-txt-link-freetext"
                href="https://lists.nomeata.de/mailman/listinfo/tiptoi-hw"
                moz-do-not-send="true">https://lists.nomeata.de/mailman/listinfo/tiptoi-hw</a>
              <br>
              <br>
            </blockquote>
            <br>
            _______________________________________________ <br>
            tiptoi-hw mailing list <br>
            <a class="moz-txt-link-abbreviated"
              href="mailto:tiptoi-hw@lists.nomeata.de"
              moz-do-not-send="true">tiptoi-hw@lists.nomeata.de</a> <br>
            <a class="moz-txt-link-freetext"
              href="https://lists.nomeata.de/mailman/listinfo/tiptoi-hw"
              moz-do-not-send="true">https://lists.nomeata.de/mailman/listinfo/tiptoi-hw</a>
            <br>
          </blockquote>
          <br>
          <br>
          <br>
          _______________________________________________ <br>
          tiptoi-hw mailing list <br>
          <a class="moz-txt-link-abbreviated"
            href="mailto:tiptoi-hw@lists.nomeata.de"
            moz-do-not-send="true">tiptoi-hw@lists.nomeata.de</a> <br>
          <a class="moz-txt-link-freetext"
            href="https://lists.nomeata.de/mailman/listinfo/tiptoi-hw"
            moz-do-not-send="true">https://lists.nomeata.de/mailman/listinfo/tiptoi-hw</a>
          <br>
          <br>
        </blockquote>
        <br>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <pre class="moz-quote-pre" wrap="">_______________________________________________
tiptoi-hw mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tiptoi-hw@lists.nomeata.de" moz-do-not-send="true">tiptoi-hw@lists.nomeata.de</a>
<a class="moz-txt-link-freetext" href="https://lists.nomeata.de/mailman/listinfo/tiptoi-hw" moz-do-not-send="true">https://lists.nomeata.de/mailman/listinfo/tiptoi-hw</a>
</pre>
      </blockquote>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <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>