Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

memory-onfi applet should use IOB registers to improve reliability #116

Open
whitequark opened this issue Mar 18, 2019 · 1 comment
Open

memory-onfi applet should use IOB registers to improve reliability #116

whitequark opened this issue Mar 18, 2019 · 1 comment
Labels
memory-onfi Applet: memory-onfi

Comments

@whitequark
Copy link
Member

There were some spurious errors while reading ONFI-like NAND with revB, it's unclear if they were caused by FXMAs or something else.
@whitequark whitequark added revC Hardware revision: C qualification Lifecycle stage: qualification memory-onfi Applet: memory-onfi labels Mar 18, 2019
@whitequark
Copy link
Member Author

I've did a lot of experimenting and it looks like the spurious errors observed on revB are gone. But I'm still not sure where to attribute the random-ish bit errors. Sure, these could be just the flash unreliability, but I feel like that's not the only reason.

Specifically, I've tried reading out the same 1 GiB flash a few times, then XOR'd them together, then looked at the difference. Mostly, I was interested in whether there are lots of missed pages (no, I think there aren't any?) but I've noticed that the bit errors aren't that random. In fact most of the non-zero XOR'd bytes were 01 or 08... and IO1 and IO4 had the longest wires in my wiring harness. This doesn't look like a coincidence at all.

xor.rs 
use std::fs::File;
use std::env::args;
use std::io::prelude::*;

fn main() {
    let mut args = args();
    args.next().unwrap();
    let in1 = args.next().unwrap();
    let in2 = args.next().unwrap();
    let out = args.next().unwrap();

    let mut data1 = Vec::new();
    File::open(in1).unwrap().read_to_end(&mut data1).unwrap();
    let mut data2 = Vec::new();
    File::open(in2).unwrap().read_to_end(&mut data2).unwrap();

    let mut datao = Vec::new();
    for (x1, x2) in data1.iter().zip(data2.iter()) {
        datao.push(x1 ^ x2);
    }

    let mut fout = File::create(out).unwrap();
    fout.write(&mut datao[..]).unwrap();
}

Sorry, something went wrong.

@whitequark whitequark removed qualification Lifecycle stage: qualification revC Hardware revision: C labels Apr 6, 2019
@whitequark whitequark changed the title Verify NAND programming on revC memory-onfi applet should use IOB registers to improve reliability Apr 6, 2019
whitequark added a commit that referenced this issue Apr 6, 2019
@whitequark
applet.memory.onfi: mark as preview-quality again.
c581656 
The applet works decently enough, but the parallel bus should really
use IOB registers. It is not completely clear but this might be
the cause of read errors that manifest as single bit flips.

The reason I suspect these errors aren't inherent to the memory
itself is because they seem to correlate with the wire length in
my wiring harness. See #116 for details.

In principle, these single bit flips aren't too bad as the flash is
supposed to be read with ECC anyway, but we don't implement any ECC,
and moreover I don't feel comfortable signing off on an applet with
known data corruption issues. (It'd be much worse if the bit flip
happened in the command or address phase, too.)

Also, this applet misses ONFI signature readout (since I can't find
any ONFI-compliant flash) and/or some other way to detect page size
(yet to be discovered), which is a serious usability impediment.
Though it's less bad than the bit flips.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
memory-onfi Applet: memory-onfi
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@whitequark