Wiki is written by people and people tend to make errors. I never take Wiki for granted. My entire looking into UBI was a discovery that things were not documented well. For some things I had to go as deep as examine UBI source code. I will stick to my findings because of a couple things: 1- I still believe you can allocate one partition to UBI and a second partition to a different filesystem such as jffs2, which means UBI can't use the entire NAND, otherwise it will corrupt the jffs2 partition. And 2 - I have looked at the NAND dump that I downloaded and I found no data being spread out all over the NAND space, the data was perfectly sequentially written, with each partition having its respective data within the address space allocated to each individual partition. It is possible that UBI will start reallocating blocks as they become bad later, but on a brand new NAND the data blocks are sequential and is within its respective partition (just interleaved with UBI headers).
It should be easy to prove one way or the other by using NAND simulator in Linux by instantiating a NAND device and creating two partitions, one allocate to UBI and second one to , say, JFFS2. Fill JFFS one with data, then UBIFS one with data, and see if UBIFS corrupted data on JFFS2 partition, which what should happen if UBI uses the entire NAND. I do not anticipate that to happen.
Anyway, this is not my focus at the moment. It seems that liberating 1200X is not a question anymore, the question is how to do it in a way with minimum writes to NAND, as NAND corruption appears to be Keysight scope's specialty. This is why I wanted to understand organization of data storage, how UBI works, etc. In general, after gaining access there are so many ways that I am not even sure yet which one to use. In this regard 1200X with its Linux appears to be easier to work with than 1000X with its Windows Embedded OS. I'll post details later, just being busy at work.
Home
Help
Search
Login
Register
