Først og fremst trenger ikke ECC-ordningen nødvendigvis å være den for alle blittsletteblokkene. Det er vanligvis 3 forskjellige typer flash-partisjoner som brukes, og for hver type er metoden for å spesifisere den brukte ECC-koden forskjellig:
- Den som er tilgjengelig av ROM-oppstartkoden
- De som er tilgjengelige av bootloader (vanligvis u-boot)
- De som er tilgjengelige av operativsystemet (forutsatt at du bruker Linux)
Generelt bruken av en bestemt ECC-metode er begrenset av blitsens OOB-størrelse. AM335x_U-Boot_User's_Guide (kan ikke legge ut lenker her på grunn av omdømme) forklarer det i seksjoner BCH Flash OOB Layout og eksemplet samsvarer med flash-brikken du bruker. De 64 byte per 2k-side begrenser effektivt de brukbare ECC-algoritmene til BCH8-, BCH4- eller HAMMING-koder.
BCH Flash OOB Layout
For ethvert ECC-skjema må vi legge til noen ekstra data mens du skriver for å oppdage og korrigere (hvis mulig) feilene som NAND-delen introduserer. I tilfelle BCH-ordning er det behov for noen byte for å lagre ECC-relatert info.
Delen av NAND-minne der tilleggsinformasjon som ECC-data er lagret, kalles Out of Band eller OOB-seksjon.
De to første byte brukes til dårlig blokkmarkør - 0xFFFF => God blokk
Neste 'N' byte brukes til BCH-byte
N = B * Antall av 512-bytesektorer på en side
B = 8 byte per 512 bytesektor i BCH4 B = 14 bytes per 512 bytesektor i BCH8 B = 26 bytes per 512 bytesektor i BCH16
Så for en 2 k sidestørrelse NAND-blits med 64-byte OOB-størrelse, bruker vi BCH8. Dette vil forbruke 2 + (14 * 4) = 58 byte av 64 tilgjengelige byte.
ECC brukt av ROM-startkode
AM335x-prosessorens ROM-startkode bestemmer hvilken ECC-ordning som skal brukes for NAND-blits, avhengig av mekanismen ekspandert i AM335x teknisk referansehåndbok kapittel 26.1 .7.4 NAND
ECC-korreksjon
Standard anvendt ECC-korreksjon er BCH 8b / sektor ved bruk av GPMC og ELM-maskinvaren. For enhets-ID-koder D3h, C3h, D5h, C5h, D7h, C7h, DEh, CEh når produsentkode (første ID-byte) er 98 timer, blir celletypeinformasjonen sjekket i 4. byte med ID-data. Hvis den er lik 10b, er den anvendte ECC-korreksjonen BCH 16b / sektor. I tillegg kan ECC-beregning utført av ROMen slås helt av ved å bruke SYSBOOT [9]. Dette er spesielt nyttig når du grensesnitt med NAND-enheter som har innebygd ECC-motorer.
Andre måter å kontrollere ECC-oppførselen er ONFI eller og I2C EEPROM men H27U1G8F2BTR-databladet nevner ikke ONFI så jeg antar at det ikke støttes av flash-brikken.
Så i utgangspunktet brukes BCH8 eller BCH16 eller ingen ECC-mekanisme for de første 128K, ROM-opplasteren leser fra NAND-flash.
ECC brukt av bootloader
Bootloader bestemmer dette på egen hånd. For eksempel for U-boot blir denne informasjonen samlet i u-boot og bootloader på første nivå (SPL / MLO) også. Informasjonen styres av U-Boot-konfigurasjonsinnstillinger satt til kompileringstid. Nyere versjoner av U-boot kan bytte ecc ved kjøretid ved hjelp av nandecc-kommandoen.
ECC brukt av operativsystemet
Valget er helt OS-spesifikt. For Linux-innebygde systemer som bruker AM335x-prosessorer, vet jeg at denne informasjonen sendes til kjernen ved hjelp av enhetstreet.
Hvilken ECC-metode bruker nandsim
Det er en parameter som heter bch som kan sendes til nandsim-modulen for å velge en ecc-kode. Fra koden antar jeg at den er initialisert til null slik at den ikke bruker noen ECC-kode. Så det ser ut til at nandsim kan bruke BCH8 og BCH16, men bare en for hele blitsen som er simulert. kode>
Hvilken ECC-metode bruker nanddump / nandwrite
Igjen, dette avhenger av operativsystemet / Linux du brukte til å dumpe blitsen. I likhet med nandsim-modulen har ekte mtd-drivere måter å spesifisere det brukte ECC-skjemaet (kjerneparametere, enhetstreet). Men du kan be nanddump om å ignorere ECC-informasjonen også.
Referanser