[Tiptoi-hw] Nochmals-Frage bez. NAND-Access
Sven A. Huerlimann
sh at sighup.ch
Di Jan 5 01:18:11 CET 2021
Hallo Erwin
Vielen Dank für die Infos. Ich brauch wohl etwas länger um das zu begreifen.
Ich meld mich wieder sobald ich glaube, dass ich es verstanden habe. Mit
Sicherheit mit neuen Fragen :)
Gruss
Sven
On 04.01.21 13:42, Erwin Pschernig via tiptoi-hw wrote:
>
> *Noch eine Ergänzung zum Verständnis von "Page", "Block", "Row" und
> "Column".*
>
> Aus den bisherigen Infos gehe ich jetzt mal von der x8 Variante des
> Flash aus (also 8 Datenleitungen).
>
> Außerdem sagt ein Bild mehr als 1000 Worte, aber ein paar gibts trotzdem:
>
> Jede Page hat 2k + 64 Bytes = 2048 + 64 = 2112, das ist die "column
> address"
> Da 2112 = 0x0840 erklärt sich warum bei 8 Datenleitungen zum Flash 2
> cyles zum senden der Spaltenadresse notwendig sind.
>
> Der hier verwendete Chip hat 4096 Blocks à 64 Pages = 4096 * 64 =
> 262144 Pages
> Da 262144 = 0x040000 erklärt das auch die 3 cyles zum senden der
> Zeilenadresse.
>
> Jedes 'X' steht für 64 Byte
>
> col 0 ------------> col 2111
> | |
> +- Page 0: XXXX XXXX XXXX XXXX X <-- row 0
> | Page 1: XXXX XXXX XXXX XXXX X <-- row 1
> | Page 2: XXXX XXXX XXXX XXXX X <-- row 2
> |
> Block 0: -+ . . .
> |
> | Page 61: XXXX XXXX XXXX XXXX X <-- row 61
> | Page 62: XXXX XXXX XXXX XXXX X <-- row 62
> +- Page 63: XXXX XXXX XXXX XXXX X <-- row 63
> +- Page 64: XXXX XXXX XXXX XXXX X <-- row 64
> | Page 65: XXXX XXXX XXXX XXXX X <-- row 65
> | Page 66: XXXX XXXX XXXX XXXX X <-- row 66
> |
> Block 1: -+ . . .
> |
> | Page 125: XXXX XXXX XXXX XXXX X <-- row 125
> | Page 126: XXXX XXXX XXXX XXXX X <-- row 126
> +- Page 127: XXXX XXXX XXXX XXXX X <-- row 127
> . . .
> +- Page 262080: XXXX XXXX XXXX XXXX X <-- row 262080
> | Page 262081: XXXX XXXX XXXX XXXX X <-- row 262081
> | Page 262081: XXXX XXXX XXXX XXXX X <-- row 262081
> |
> Block 4095: -+ . . .
> |
> | Page 262141: XXXX XXXX XXXX XXXX X <-- row 262143
> | Page 262142: XXXX XXXX XXXX XXXX X <-- row 262143
> +- Page 262143: XXXX XXXX XXXX XXXX X <-- row 262143
>
> Die Einteilung in Pages und Blocks ist den physikalischen
> Eigenschaften von Flash Speichern geschuldet. Löschen bedeutet
> normalerweise alle Bits des Speichers auf '1' zu setzen und das geht
> durch anlegen einer Programmierspannung auf großen Speicherbereichen
> recht schnell (da identisches Bitmuster). Daher sind Blöcke eher für
> Löschoperationen relevant.
>
> Schreiben des Speichers (Programmieren) bedeutet fast immer
> vereinzelte Bits auf '0' zu setzen und benötigt bei Flash Speichern
> meistens mehrere Programmierpulse hintereindander. Das ist deutlich
> aufwändiger weil auch Spannung und Strom bei den einzelnen Pulsen
> variiert wird um die Lebensdauer der Flash Zelle zu schonen. Deswegen
> und auch wegen der Performance beim lesen/Schreiben mit Caches ist für
> Programmieren und Lesen meist die Page Größe interessant.
>
> *Und um nochmal auf den Beginn der Frage zurückzukommen:*
>
> /- NAND-Reset (0xff, no cycles)/
>
> Damit wird der Flash Controller un einen Default Zustand versetzt und
> alle evlt. noch nicht beendeten Lese-/Programmier-/Löschzyklen
> abgebrochen und die Status Register auf 0xCO gesetzt.
>
> /- NAND-Read (0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x30)/
>
> Mit diesem Kommando (READ1 = 0x00 cc cc rr rr rr 0x30) wird ein Lesen
> (Laden in den Page Cache) der Page 0
> angetriggert (col = 0, row = 0)
>
> /- und dann ein weiteres Command mit dem "Continue" bit gesetzt,
> aber nur "ein" write ins command register./
>
> Da passiert vermutlich ein READ CACHE (SEQUENTIAL) = 0x31 um ohne
> erneutes schreiben einer Adresse die nächste
> Page lesen zu können. Diese Kommando setzt den column index
> automatisch auf 0 und durch triggern der #RE kann dann
> die diese Page wieder von Beginn an Byte für Byte gelesen werden.
>
> *Wegen der "Register" ab Adresse 0x0404A000 würde ich noch ein paar
> Wetten abgeben:*
>
> Ich gehe davon aus das an (min.) zwei dieser Adressen die beiden
> Status Register des Flash Controllers gemapped sind:
>
> Status Register:
> Mode / Bit: | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
> Page Program | WP | R/B | R/B | - | - | - | - | P/F |
> Blocke Erase | WP | R/B | R/B | - | - | - | - | P/F |
> Read | WP | R/B | R/B | - | - | - | - | - |
> Cache Read | - | R/B | P/E/R | - | - | - | - | - |
> WP ...... Write Protect ( '0' = protected, '1' = not protected )
> R/B ..... Ready / Busy ( Bit 6: '0' = busy, '1' = ready | Bit 5:
> '0' = active, '1' = idle )
> P/F ..... Pass / Fail ( '0' = pass, '1' = fail )
> P/E/R ... P/E/R Controler Bit ( '0' = active, '1' = idle )
>
> EDC Status Register:
> Mode / Bit: | 7 | 6 | 5 | 4 | 3 | 2 | 1 |
> 0 |
> Copy Back Program | WP | R/B | R/B | - | - | EDC_V | EDC_S |
> P/F |
> WP ...... Write Protect ( '0' = protected, '1' = not protected )
> R/B ..... Ready / Busy ( '0' = busy, '1' = ready )
> EDC_V ... EDC Validity ( '0' = invalid, '1' = valid )
> EDC_S ... EDC status ( '0' = no error, '1' = error )
> P/F ..... Pass / Fail ( '0' = pass, '1' = fail )
>
> Das die restlichen 5 Register was mit den Adresszyklen zu tun haben
> glaube ich eher nicht. Ich würde fast von der folgenden Variante
> ausgehen, wobei die Zuordnung zu den Adressen willkürlich ist.
>
> 0x0404A000 = COMMAND (1st cycle) <= scheint ja verifiziert zu sein
> 0x0404A004 = COMMAND (2nd cycle) ???
> 0x0404A008 = COMMAND (3rd cycle) ???
> 0x0404A00C = COMMAND (4th cycle) ???
> 0x0404A010 = ROW ???
> 0x0404A014 = COLUMN ???
> 0x0404A018 = STATUS REGISTER ???
> 0x0404A01C = EDC STATUS REGISTER ???
>
> Das ist mein Tipp, da bei allen Kommandos mit mehr als einem Byte die
> Zeilen und Spalten Adressen immer zwischen den Kommando Bytes gesendet
> werden.
>
>
> *Gesendet:* Montag, 04. Januar 2021 um 00:28 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
>
> 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
>
> _______________________________________________ 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/20210105/45bc9ef3/attachment.htm>
Mehr Informationen über die Mailingliste tiptoi-hw