Some more points: On Friday 08 July 2011 00:37:35 AJ ONeal wrote: > On Wed, Jun 29, 2011 at 11:48 AM, AJ ONeal <coola...@gmail.com> wrote: > I have a few inter-related issues: > Why would one kernel boot a card that another kernel can't?
Possibly the controller is set up in a slightly different way, resulting in bad timings or other problems. > Why would a card's disk geometry matter for boot? The card's geometry is calculated from the partition table, it's not actually a property of the card. If you have identical cards that report different geometry, the reasons may be: * they were partitioned differently * some cards are read incorrectly, if the kernel interprets random data as a partition table, you get random geometry > Who is a good manufacturer for getting hardware-identical cards in bulk? This is hard. I suggest you first start with another equally hard question though: what is a manufacturer that can provide actually working cards? I would recommend using only those that make both the controller chips and the flash chips, which basically leaves * Toshiba * Samsung * Sandisk (cooperating with toshiba) * Lexar (micron/intel) Contact them directly to get a sample, do an extensive test the way I described, document the results and buy a lot from them. There are also companies like swissbit that know what they are doing and charge a lot extra for providing you cards that are actually made for running with Linux. > How can I probe the actual "disk geometry" of an sd card? It's complicated. For 8GB cards and larger, there is only one possible correct geometry: 63/255/1023. fdisk knows that and should do it correctly. On 4 GB cards, there are multiple options. You can either stick with the geometry that was originally used to partition the card, or you also use 63/255/xxx, with xxx being smaller than 1023 in that case. HOWEVER: Do not align partitions to full cylinders, even though that is the default in old versions of fdisk. Doing that will result in low performance and cards breaking faster when writing to them. The only correct way to partition an SD card is to align each partition to 4MB (8192 sectors). Old versions of xloader couldn't deal with that, so you might have to update xloader, or alternatively start the boot partition at sector 63 anyway (and then never write to it). We fixed this in linaro-media-create for the 11.06 release, but the gumstix wiki and many other places list still describe a procedure that *will* *eat* *your* *data*: http://wiki.gumstix.org/index.php?title=Boot_from_MMC#Partition_the_card http://www.gumstix.org/create-a-bootable-microsd-card.html http://fastr.github.com/articles/Partition-MicroSDHC-for-Gumstix-Overo.html http://www.omappedia.org/wiki/Android_Video_Run_From_SD_Tutorial The reason for this is simply that flash pages on the card have a size between 2KB and 32KB dependening on how dumb the controller is. Writing data that is not aligned to the pages requires expensive read-modify-write operations, and a lot of cards just end up doing many extra erase cycles. Someone should really start documenting a correct procedure in all of those places. What you really need to do using fdisk is to disabled compat mode ('c'), set sector addressing mode ('u'), and create the partitions each at a multiple of 8192 sectors. Arnd _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
