[Tiptoi-hw] Nochmals-Frage bez. NAND-Access

Mo Jan 4 00:28:55 CET 2021

Sehr geil! Danke! Das hilft immens.

Column == Page und Row == Block? Da steh ich noch auf dem Schlauch.

Gruss und vielen Dank

Sven

On 03.01.21 19:27, Erwin Pschernig via tiptoi-hw wrote:
> Hallo zusammen,
>  
> erstmal ein gutes neues Jahr und Grüße von einem der bisher nur
> mitgelesen, aber das sollte sich in Zukunft hoffentlich ändern.
> 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 :-) ].
>  
> Aber vorab kann ich hier bei dem Thema evtl. mit ein paar Grundlagen
> weiter helfen.
>  
> Ich habe mir auch das Datenblatt mal kurz durchgeschaut und kann
> folgende Erklärungen beisteuern.
>  
> 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).
>  
> 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.
> Bei dieser Variante hat eine Page 2 kByte und ein Block 128 kByte.
>  
> 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.
>  
> Damit ändert sich die Größe einer Page auf 2112 Byte ( 2 * 1024 + 64 )
> was exakt der Cache größe entspricht.
>  
> 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.
>  
> 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ß.
>  
> 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.
>  
> Damit ergibt sich für diesen Chip folgende Schlußfolgerung:
>  
> row address = page ID
> column addres = byte/word address inside a page
>  
> Ich hoffe das hilft ein wenig zum Verständnis.
>  
> LG Erwin
>  
>  
> *Gesendet:* Sonntag, 03. Januar 2021 um 18:20 Uhr
> *Von:* "Sven A. Huerlimann via tiptoi-hw" <tiptoi-hw at lists.nomeata.de>
> *An:* tiptoi-hw at lists.nomeata.de
> *Cc:* "Sven A. Huerlimann" <sh at sighup.ch>
> *Betreff:* Re: [Tiptoi-hw] Nochmals-Frage bez. NAND-Access
>
> Servus!
>
> On 03.01.21 12:35, Matthias Weber via tiptoi-hw wrote:
>
>     Hallo!
>
>     Sven A. Huerlimann via tiptoi-hw wrote:
>
>         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.
>
>     Uh, war kurz verwirrt. NFC = NAND Flash Controller?
>
>     Für mich hat sich NFC als Near Field Communication eingebrannt.
>
> Genau.. Bei mir eigentlich auch, aber irgendwann hab ich kapituliert
> und das Anyka-Wording übernommen.
>
>      
>
>         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.
>
>     Kannst du kurz nochmal erläutern, was du mit der Beschreibung in
>     den Klammern meinst? Beziehst du dich immer auf das Kommando?
>
> 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.
>
> Ein Read-Cycle mit Addresse schreibt zum Beispiel (Sorry fürs Spamen
> und die etwas infantile Formatierung):
>
> nfc status write
> Command valid bit set
> Chipselect asserted
> NFC_CTRL_REG_CE_SAVE_BIT asserted
> nfc status
> nfc status write
> Start of Command Cyce ///////////////////////////////////////////////
> NFC_COMMAND write (cycle 0): 00000064
> NFC_CMD_REG_CMD_BIT write
> WRITE ENABLE
> COMMAND LATCH ENABLE
> ADDRESSS LATCH DISABLE
> NFC_CMD_REG_CMD_CONF
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Commmand Cycle
> NFC_COMMAND write (cycle 1): 00000062
> NFC_CMD_REG_CMD_BIT write
> WRITE ENABLE
> COMMAND LATCH DISABLE
> ADDRESSS LATCH ENABLE
> NFC_CMD_REG_ADD_CONF
> ========================================================
> 00000062
> NFC_COMMAND write (cycle 2): 00000062
> NFC_CMD_REG_CMD_BIT write
> WRITE ENABLE
> COMMAND LATCH DISABLE
> ADDRESSS LATCH ENABLE
> NFC_CMD_REG_ADD_CONF
> ========================================================
> 00000062
> NFC_COMMAND write (cycle 3): 00000062
> NFC_CMD_REG_CMD_BIT write
> WRITE ENABLE
> COMMAND LATCH DISABLE
> ADDRESSS LATCH ENABLE
> NFC_CMD_REG_ADD_CONF
> ========================================================
> 00000062
> NFC_COMMAND write (cycle 4): 00000062
> NFC_CMD_REG_CMD_BIT write
> WRITE ENABLE
> COMMAND LATCH DISABLE
> ADDRESSS LATCH ENABLE
> NFC_CMD_REG_ADD_CONF
> ========================================================
> 00000062
> NFC_COMMAND write (cycle 5): 00000062
> NFC_CMD_REG_CMD_BIT write
> WRITE ENABLE
> COMMAND LATCH DISABLE
> ADDRESSS LATCH ENABLE
> NFC_CMD_REG_ADD_CONF
> ========================================================
> 00000062
> NFC_COMMAND write (cycle 6): 00018064
> NFC_CMD_REG_INFO_POS write: 0030
> NFC_CMD_REG_CMD_BIT write
> WRITE ENABLE
> COMMAND LATCH ENABLE
> ADDRESSS LATCH DISABLE
> NFC_CMD_REG_CMD_CONF
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> NFC_COMMAND write (cycle 7): 0001dc01
> NFC_CMD_REG_INFO_POS write: 003b
> NFC_CMD_REG_DELAY_BIT write
> WRTIE DISABLE
> COMMAND LATCH DISABLE
> ADDRESSS LATCH DISABLE
> NFC_CMD_REG_DELAY_BIT
> -------------------------------------------------------
> EEEENNNNNDDDD of TRANSACTION oooooooooooooooooooooooooooooooooooo
> NFC_CMD_REG_LAST_BIT write
> End Cycle
> Got NAND command: 00, Address: 00, 00, 00, 00, 00, End: 30, Delay: 3b
> EEEENNNNNDDDD of TRANSACTION oooooooooooooooooooooooooooooooooooo
>
>      
>
>     Ich habe gerade das Datenblatt eines HY27UF084G2B und
>     https://github.com/maehw/ftdi-nand-flash-reader/blob/master/bitbang_ft2232.c
>     befragt.
>
>     0x00 0x30 ist ein Page Read (READ1) Kommando. Zwischen 0x00 und
>     0x30 kommen 5 Adress-Bytes (2x Spalte, 3x Zeile).
>
>     Und dann werden bei einer Page wahrscheinlich 2112 Bytes am Stück
>     gelesen. Vielleicht siehst du das und ein interner Puffer füllt sich?
>
> Ok. Hier ist das Problem, dass ich ja den Puffer füllen muss :)
>
> Ich denk ich schaufel einfach mal 2112 Bytes und sehe was passiert.
>
>      
>
>         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?
>
>     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.
>
> Was wird dann inkrementiert? Zeile? Spalte? Da magelts bei mir stark
> an Durchblick.
>
>      
>
>     Gruß
>     Matthias
>
> Gruss Sven
>
>      
>      
>
>     _______________________________________________
>     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
> <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
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://lists.nomeata.de/pipermail/tiptoi-hw/attachments/20210104/150be742/attachment.htm>