NTC improving NAND-on-Linux


#1

Apparently NAND has not been well supported on Linux because several layers of its driver support depend on hidden (not open sourced) software. Linux and the rest of the GPL ecosystem depend on open sources, and should not depend on hidden code, because no one can vouch for what it is doing to your system. There are alternatives, since eMMC and SD card memory are now well supported on Linux, though more expensive. I learned about this from conversation with a Debian configuration developer. I’m sorry I do not have deep knowledge of it myself.

Now reread NTC’s statement about NAND bugs and shipping delays:

Implying NTC has an admirable strategy of trying to improve ongoing problems of NAND on Linux. They are getting help from Free Electrons, who seem to have a good reputation for getting source-code changes reintegrated “up-stream”. That means appropriate FLOS (free libre and open source) project groups can integrate those changes into well-vetted development streams such as Debian’s. If this is so, then to whatever extent NTC and Free Electrons succeed, NAND becomes that much easier for everyone to use with Linux.

Not very expert on this, but I thought it might be useful to add to the conversation. It’s interesting stuff from lots of angles.


PAL woes, 'setenv' command not found
PocketC.H.I.P.s Shipping On-Time & NAND Software Delays C.H.I.P.s Until Mid-October
Why C.H.I.P. has its own kernel fork?
#2

SD memory is not a real alternative to NAND flash, because it’s much slower. I’ve added an sd-slot to my pocketchip (thanks to @JKW for the Tzatziki dip) and best it can do is around 15MB/s, which is already more than most laptops can do. But the nand on the chip is much faster than that.

I think eMMC is about equally fast as nand flash, but more expensive. However, I’m not sure about both statements :wink: Anyway, nand flash is more like a ROM replacement, where eMMC acts more like an SSD drive. Again, I’m not sure if I worded it correctly…


#3

Thanks for adding that @Squirrel61. It reminds me I was told we could only run straight Debian from a thumb drive or other card because eMMC and SD drives have good Linux drivers. But from what you are saying, at least the SD drive installation would run slow.


#4

Some other NAND on CHIP discussions in alphabetic order:


#5

You’ve done a great job with the explanation.

Although I’m NOT familiar with the particular part in CHIP, I do design embedded systems for a living and sometimes have to design in external memory. In my experience the two main reasons why built-in Flash memory is almost always faster than SD are:
Faster clock, SD being external to the PCB has to be slower because the transmission characteristics of the signal lines can’t be tightly controlled.
8 bit interface, SD is either 4 bit or with SPI 1 bit so built-in is 2 or 8 times faster because it has 2 or 8 times more data handled per cycle.


#6

I put Debian on the fastest USB 3.0 thumb drive I own and it is slow to start the OS and applications. Once everything is loaded into RAM the performance is good as long as you only work with small files (< 1Meg).

I only did it because I can’t setup a proper hard disk based system at that moment but wanted to test some Python code on RasPI, Win7, Win8.1, Win10 and Debian Jessie. I’m loving the cross platform capabilities of Python.


#7

@paul_hutch I love Python for the same reasons. Pretty everything can run Python, even an esp8266. I also don’t have any issues with packages or dependencies, everything just works.


#8

I find the result of 15MB/s interesting… do you know if that is because the bandwidth of the CHIP has been saturated, or is it actually the microSD/controller that is the bottleneck? I’ve been doing some performance tests with a USB3 flash drive on a pine64 (which has USB2 ports) and have been able to get read and write speeds of 32.9-34.5MB/s with iozone, which was near enough to saturating the 40MB bandwidth of the pine64s usb ports as I expect I’ll get. I do seem to remember seeing a reference to the bandwith of the microSD being lower, but I can’t see it again. I’m just wondering if that is what’s happening here with the CHIP - bandwith of the microSD port, or the microSD itself being reached. There is a frequent recommendation for use of Samsung EVO microSDs due to higher random read/write and overall performance, so that may be worth looking into?


#9

That would be the SD card limiting the speed. There is 25MB/s of bandwidth available. It’s possible to get around 21-22MB/s of actual throughput from it.


#10

Thanks for that @cmnybo… those were the exact numbers I was trying to remember (21-22MB/s)! :wink: Now, if I could remember where I saw them! :open_mouth:


#11

Another link to discussion related to "NTC improving NAND-on-Linux:


#12

Hi all. I have been doing some experimenting for read and write speeds to a MicroSD card via a usb adapter, and via the SD interface that is hooked up via GPIO. I am wondering how we may be able to improve the performance. Thoughts?


#13

Thanks chrisvollo, for adding this discussion to the list.