Tiago Marques wrote: > Trying to find datasheets of the flash chips to know what their erase > block size and page size(and number of erase cycles) has been a > nightmare for me, the manufacturer just doesn't care if your > partitioning choice ends up sending the SSD/SD/MMC sooner than the > warranty expires. > Have you had the same experience? >
It depends on who "you" are. If "you" is Quanta (the manufacturer of OLPC machines), chip vendors will tell you whatever you ask, because it determines whether or not they sell tens of thousands of parts per month. Quanta can pass that information on to us at OLPC under certain conditions. So the answer is that OLPC can get the information with some amount of effort, at least for parts that are actual candidates for use in our machines. As an invidual or small-scale manufacturer, getting information can be very difficult bordering on impossible. There is just no incentive for chip vendors to spend the time to talk to individuals. The way that the distribution model works, by the time you get out near the edges of the distribution channel graph, the detailed knowledge has dispersed too much. "This one is blue and it says 4 GB. The price is $14.95. Are you going to buy it or not? Would you like to buy our extended warranty for an extra $10? Next customer, please." One way to get a clue is to look at the factory partition map and use what As regards partitioning choice, my current thinking is: a) If you can, don't repartition it - use the factory format b) If you must repartition and you have some flexibility, look at the factory partition map and align your partitions on the granularity of the existing first partition's starting block number. As an extra clue, look to see where the primary and secondary FATs start; their alignment granularity is likely to be important. b) If you must construct a fixed partition layout for use on multiple different devices, align each partition on at least a 4MiB boundary. That means that you "waste" 4M for the partition map (one 512-byte sector padded out to a 4 MiB boundary, but oh well). For devices 2 GiB or less - the previous generation - maybe 1 MiB alignment would be okay, as such devices are likely to have smaller erase blocks. Those numbers seem "safe" to me. Perhaps you could use smaller alignment granularity with knowledge of specific parts, but as we have noted, such knowledge can be hard to obtain. _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel