<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Hallo zusammen,</div>
<div> </div>
<div>erstmal ein gutes neues Jahr und Grüße von einem der bisher nur mitgelesen, aber das sollte sich in Zukunft hoffentlich ändern.</div>
<div>Für richtige Hilfe muß ich mich noch ein wenig einlesen und selbst ein wenig rumspielen sobald ich auch eine Bastelstift habe [ Danke @Matthias für das Angebot :-) ].</div>
<div> </div>
<div>Aber vorab kann ich hier bei dem Thema evtl. mit ein paar Grundlagen weiter helfen.</div>
<div> </div>
<div>Ich habe mir auch das Datenblatt mal kurz durchgeschaut und kann folgende Erklärungen beisteuern.</div>
<div> </div>
<div>Der hier angesprochene NAND Flash ist eine etwas aufwändigere (schnellere) Variante und man kann nicht direkt auf den eigentlichen Flash zugreifen sonden wählt durch das READ1 Kommando eine Page aus welche in den schnellen "read cache" geladen wird. Daher kommt auch der recht große Unterschied zwischen random access (25us max) und sequential read (min 25ns = Faktor 1000 schneller).</div>
<div> </div>
<div>Der NAND Flash ist wie alle gängigen Flash Bausteine in Pages und Blocks unterteilt um gewisse Operation (z.Bsp. Löschen) performanter zu gestalten.</div>
<div>Bei dieser Variante hat eine Page 2 kByte und ein Block 128 kByte.</div>
<div> </div>
<div>Da Flash generell ein unsicherer Speicher ist und immer mal wieder eine Zelle kaputt wird hat jede Page noch ein paar (64) zusätzliche Bytes um solche auszugleichen.</div>
<div> </div>
<div>Damit ändert sich die Größe einer Page auf 2112 Byte ( 2 * 1024 + 64 ) was exakt der Cache größe entspricht.</div>
<div> </div>
<div>Das Kommando READ1 "00 cc cc rr rr rr 30" braucht auch column (cc cc) und row (rr rr rr) zum Auswählen der Speicherzelle. Hier erkennt man auch Aufgrund der Tatsache das die Address zwischen den beiden Kommandobytes kommt den Cache Vorgang.</div>
<div> </div>
<div>Solange kein weiteres READ1 Kommando kommt kann man nun durch Toggeln der #RE Leitung nacheinander die gesammten Bytes der Page sequentiell auslesen (das von Matthias angesprochene auto increment), denn mit jedem #RE toggeln wird die column address im 1 oder 2 Byte incrementiert (abhängig ob x8 oder x16 Variante). Und es geht hier noch besser, um die nächste Page zu lesen reicht es ein Kommando READ CACHE (SEQUENTIAL) = 31h zu senden und die nächsten 2112 Byte können gelesen werden, ohne das erneut eine Adresse gesendet werden muß.</div>
<div> </div>
<div>Mit dieser Sequenz kann man also beginnend von der Adresse 0 den ganzen Speicher linear auslesen und muß dafür NUR die einmal eine Adresse angeben.</div>
<div> </div>
<div>Damit ergibt sich für diesen Chip folgende Schlußfolgerung:</div>
<div> </div>
<div>row address = page ID</div>
<div>column addres = byte/word address inside a page</div>
<div> </div>
<div>Ich hoffe das hilft ein wenig zum Verständnis.</div>
<div>
<div>LG Erwin</div>
<div>
<div>
<div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin:0 0 10px 0;"><b>Gesendet:</b> Sonntag, 03. Januar 2021 um 18:20 Uhr<br/>
<b>Von:</b> "Sven A. Huerlimann via tiptoi-hw" <tiptoi-hw@lists.nomeata.de><br/>
<b>An:</b> tiptoi-hw@lists.nomeata.de<br/>
<b>Cc:</b> "Sven A. Huerlimann" <sh@sighup.ch><br/>
<b>Betreff:</b> Re: [Tiptoi-hw] Nochmals-Frage bez. NAND-Access</div>
<div name="quoted-content">
<p>Servus!</p>
<div class="moz-cite-prefix">On 03.01.21 12:35, Matthias Weber via tiptoi-hw wrote:</div>
<blockquote>
<p>Hallo!</p>
<div class="moz-cite-prefix">Sven A. Huerlimann via tiptoi-hw wrote:</div>
<blockquote>
<pre class="moz-quote-pre">Hallo zusammen, ein gutes Neues!
Ich hab nochmals ein Verständnisproblem beim NAND Controller, ev. kann
mir da jemand weiterhelfen:
Ich hab ein halbwegs brauchbares Fundament für die NFC-Emulation. Ein
ungefähres Gespür für die Register und den Ablauf einer Flash-Read
Operation.</pre>
</blockquote>
<p>Uh, war kurz verwirrt. NFC = NAND Flash Controller?</p>
<p>Für mich hat sich NFC als <span>Near Field Communication eingebrannt.</span></p>
</blockquote>
Genau.. Bei mir eigentlich auch, aber irgendwann hab ich kapituliert und das Anyka-Wording übernommen.
<blockquote>
<p> </p>
<blockquote>
<pre class="moz-quote-pre">Was ich jetzt sehe, ist das die FW folgendes macht:
- NAND-Reset (0xff, no cycles)
- NAND-Read (0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x30)
- und dann ein weiteres Command mit dem "Continue" bit gesetzt, aber nur
"ein" write ins command register.</pre>
</blockquote>
<p>Kannst du kurz nochmal erläutern, was du mit der Beschreibung in den Klammern meinst? Beziehst du dich immer auf das Kommando?</p>
</blockquote>
<p>Jup. Der NFC hat ein Register an 0x0404a000 (nennen wir es mal NFC_COMMAND) und darüber (0ffset 0x04 - 0x1C) weitere Register im opensource-treiber nicht explizit benannt sind, aber offenbar die weiteren Cycle abbilden.</p>
<p>Ein Read-Cycle mit Addresse schreibt zum Beispiel (Sorry fürs Spamen und die etwas infantile Formatierung):</p>
<p><font face="monospace">nfc status write<br/>
Command valid bit set<br/>
Chipselect asserted<br/>
NFC_CTRL_REG_CE_SAVE_BIT asserted<br/>
nfc status<br/>
nfc status write<br/>
Start of Command Cyce ///////////////////////////////////////////////<br/>
NFC_COMMAND write (cycle 0): 00000064<br/>
NFC_CMD_REG_CMD_BIT write<br/>
WRITE ENABLE<br/>
COMMAND LATCH ENABLE<br/>
ADDRESSS LATCH DISABLE<br/>
NFC_CMD_REG_CMD_CONF ++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br/>
Commmand Cycle<br/>
NFC_COMMAND write (cycle 1): 00000062<br/>
NFC_CMD_REG_CMD_BIT write<br/>
WRITE ENABLE<br/>
COMMAND LATCH DISABLE<br/>
ADDRESSS LATCH ENABLE<br/>
NFC_CMD_REG_ADD_CONF ========================================================<br/>
00000062<br/>
NFC_COMMAND write (cycle 2): 00000062<br/>
NFC_CMD_REG_CMD_BIT write<br/>
WRITE ENABLE<br/>
COMMAND LATCH DISABLE<br/>
ADDRESSS LATCH ENABLE<br/>
NFC_CMD_REG_ADD_CONF ========================================================<br/>
00000062<br/>
NFC_COMMAND write (cycle 3): 00000062<br/>
NFC_CMD_REG_CMD_BIT write<br/>
WRITE ENABLE<br/>
COMMAND LATCH DISABLE<br/>
ADDRESSS LATCH ENABLE<br/>
NFC_CMD_REG_ADD_CONF ========================================================<br/>
00000062<br/>
NFC_COMMAND write (cycle 4): 00000062<br/>
NFC_CMD_REG_CMD_BIT write<br/>
WRITE ENABLE<br/>
COMMAND LATCH DISABLE<br/>
ADDRESSS LATCH ENABLE<br/>
NFC_CMD_REG_ADD_CONF ========================================================<br/>
00000062<br/>
NFC_COMMAND write (cycle 5): 00000062<br/>
NFC_CMD_REG_CMD_BIT write<br/>
WRITE ENABLE<br/>
COMMAND LATCH DISABLE<br/>
ADDRESSS LATCH ENABLE<br/>
NFC_CMD_REG_ADD_CONF ========================================================<br/>
00000062<br/>
NFC_COMMAND write (cycle 6): 00018064<br/>
NFC_CMD_REG_INFO_POS write: 0030<br/>
NFC_CMD_REG_CMD_BIT write<br/>
WRITE ENABLE<br/>
COMMAND LATCH ENABLE<br/>
ADDRESSS LATCH DISABLE<br/>
NFC_CMD_REG_CMD_CONF ++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br/>
NFC_COMMAND write (cycle 7): 0001dc01<br/>
NFC_CMD_REG_INFO_POS write: 003b<br/>
NFC_CMD_REG_DELAY_BIT write<br/>
WRTIE DISABLE<br/>
COMMAND LATCH DISABLE<br/>
ADDRESSS LATCH DISABLE<br/>
NFC_CMD_REG_DELAY_BIT -------------------------------------------------------<br/>
EEEENNNNNDDDD of TRANSACTION oooooooooooooooooooooooooooooooooooo<br/>
NFC_CMD_REG_LAST_BIT write<br/>
End Cycle<br/>
Got NAND command: 00, Address: 00, 00, 00, 00, 00, End: 30, Delay: 3b<br/>
EEEENNNNNDDDD of TRANSACTION oooooooooooooooooooooooooooooooooooo</font></p>
<blockquote>
<p> </p>
<p>Ich habe gerade das Datenblatt eines HY27UF084G2B und <a class="moz-txt-link-freetext" href="https://github.com/maehw/ftdi-nand-flash-reader/blob/master/bitbang_ft2232.c" target="_blank">https://github.com/maehw/ftdi-nand-flash-reader/blob/master/bitbang_ft2232.c</a> befragt.</p>
<p>0x00 0x30 ist ein Page Read (READ1) Kommando. Zwischen 0x00 und 0x30 kommen 5 Adress-Bytes (2x Spalte, 3x Zeile).</p>
<p>Und dann werden bei einer Page wahrscheinlich <span class="pl-c1">2112 Bytes am Stück gelesen. Vielleicht siehst du das und ein interner Puffer füllt sich?</span></p>
</blockquote>
<p>Ok. Hier ist das Problem, dass ich ja den Puffer füllen muss :)</p>
<p>Ich denk ich schaufel einfach mal 2112 Bytes und sehe was passiert.</p>
<blockquote>
<p> </p>
<blockquote>
<pre class="moz-quote-pre">Meine naive Annahme: Read-Cycle setzt mal auf (Startadresse, etc. etc.)
und danach kann mit diesem "Continue" einfach die nächste
Page?Block?Sector?Huga abgefragt werden?</pre>
</blockquote>
<p>Bei SPI-Flash kenne ich das, dass man keine weiteren Adressen explizit angeben muss. Hier könnte ich mir vorstellen, dass der NAND Flash Controller einen Autoinkrement durchführt.</p>
</blockquote>
Was wird dann inkrementiert? Zeile? Spalte? Da magelts bei mir stark an Durchblick.
<blockquote>
<p> </p>
Gruß<br/>
Matthias</blockquote>
Gruss Sven
<blockquote>
<fieldset class="mimeAttachmentHeader"> </fieldset>
<pre class="moz-quote-pre">_______________________________________________
tiptoi-hw mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tiptoi-hw@lists.nomeata.de" onclick="parent.window.location.href='mailto:tiptoi-hw@lists.nomeata.de'; return false;" target="_blank">tiptoi-hw@lists.nomeata.de</a>
<a class="moz-txt-link-freetext" href="https://lists.nomeata.de/mailman/listinfo/tiptoi-hw" target="_blank">https://lists.nomeata.de/mailman/listinfo/tiptoi-hw</a>
</pre>
</blockquote>
_______________________________________________ tiptoi-hw mailing list tiptoi-hw@lists.nomeata.de <a href="https://lists.nomeata.de/mailman/listinfo/tiptoi-hw" target="_blank">https://lists.nomeata.de/mailman/listinfo/tiptoi-hw</a></div>
</div>
</div>
</div>
</div></div></body></html>