This article has come about due to several emails and reading numerous chat groups as they relate to the current flood of small ARM based netbooks and tablets. It all relates to using SD devices and my overall approach to using the netbook or tablets. There are a few personal opions that I need to get out of the way before I give you the few facts I know about SD devices. The main topic of this section is what do we and do we not know about these netbooks and tablets that is causing so much traffic about them.
I guess I need to start out by reminding my readers that we know very little about these units. Unlike previous laptops or small systems that were designed and built by a single group, these units are coming from many places and factories in China. It seems to me, and I have seen plenty of comments to support my guess, that what we are getting is a wide range of real and fake products. I have read of people getting models missing cameras, failing outright, and just not being what the buyer thought they were getting. I suspect that some of the cheap items are from real sources, but yet there is certainly a number of units out there made from item that we used to say "fell off the truck in delivery".
The issue as I see it is trying to make a usable working systems out of this mess of unknown products. I think the only way to handle the unknowns is to develop a set of processes and procedures that should work over a range of unknowns. In the case of the netbooks and tablets they seem to be using a common structure and thus there are some steps you can follow that will help you be successful. The SD device is one example of how we can approach these units and get some form of success every time. I focus on using only 2GB devices for any first attempt, as part of this approach.
The why behind using only 2GB devices goes something like. When I worked on the Atmel NGW100 board, it used version 1.4 of Uboot and did not support anything larger than 2GB SD devices. At the time we had the entire souce to the version of Uboot being used and could work on it if needed. We also had all the driver code and buildable kernels at the time. Since it was all based on Linux and covered by the GPL, so that source and support was somewhat available for it.
This group of netbooks and tablets however is a different situation all together. The plants in China are building systems in which I doubt anyone in the plant knows anything about the code that went into the products. Their mission is to take boards, components and create a product that sells. The design might consist of mutliple vendors from many different locations and languages and I suspect from legal as well as non-legal sources. The results for us the users is a stream of products that we can't get the information we really need, if any at all. Clearly the fake products don't want you to know too much as that might open them to legal action.
For me that means I have to accept what little information and code I can get, use steps and processes that puts this small amount of data into a working system. Let us look at some of what we do know. Typically the systems and software work when we get it. Most units are using linux kernels, Uboot processes, and some are now coming with Android that runs on top of debian. The WinCE units are getting fewer and can be upgraded in most cases to Linux right off, as they have been around long enough to already be supported.
My procedure then is to assume I can use the existing Uboot scriptcmd VFAT structure to boot into another system. In the case of Android units, I can just copy a runnig kernel and its drivers from the existing Android system and point it at a new file system. Do I want to keep the old system untouched - normally yes, as I find it helpful to be able to go back and check previous operations or code incase I or someone else missed something. I currently am trying to get the hardwired networking going instead of the wifi and discovered the version of debian I am using didn't bring the network driver over.
I have been reading up on the deices and found some time ago a web site that provided lots of good information. The problem I had during the Atmel NGW100 work was a corrupted device. The information at the beinging of the device had become corrupted. The solution was to take a new SD devices from the same manufacturer and a do "dd" of the entire device and do a "dd" on the old device. It worked just fine and I was able to re-use the old device after a overwrite of the entire device. Knowing this of course makes me concerned that people are providing SD images of debian setups with instructions to do a "dd" of their image over the whole device. That operation will then overwite the manufacturers data with whatever data on the orginal device.
Since the previous user's SD device worked with the intended target, doing this may in fact improve your changes of it working in your case. If your SD device for some reason has a different interface say, and the manufactures information on the device is now changed it may become corrupted and never work again - I just can't say for sure. I think however that the design of these devices is now so standard, that most likely the only difference is the manufactures name and nothing more. I will do some checking and see.
What is the difference between the SD and SDHC devices other than one always works and the other might not? Check out the Wikipedia for a good answer: WikiPedia Secure Digital Card . The article is very long and thus to summarize; we need to consider the fact that the cards all have a controller chip; that it has a protocol; the SD protocol is slow and limited to only support 2GB; while the SDHC internal flags and protocol support upto 32GB. The format of SD is normally VFAT16, while the SDHC is FAT32. There can also be hardware speed and one bit, 4 bit, or SPI transfers, again a hardware difference that might not be supported.
So the short of all this is that the hardware and Uboot must support the reading of the protocol header in the SD device, and if it only supports a certain type of file structure or transfer method that the card doesn't support, it will not work. I think we can circumvent these by changing the data structure that define what the device is when we do a "dd" of a different protocol over the entire device. This is strickly not a good idea, but it might make it possbile to use a device that normally would not work.
I have received numerous emails about how poeple have used larger sizes with these netbooks and tablets. I believe these new units are using a newer version of Uboot and the devices hardware we know, will support the larger sizes once the unit are running the full OS. It appears the process for using larger sizes, starts by repartitioning the SD card with a smaller vfat16 partition and using the rest of the card as a ext2 partiton, both of which we know for sure the Uboot can read and support. I saw similar success with the Atmel NGW100, but do not believe the Uboot can do as much as these newer netbooks and tablets can.
I have gotten a few emails - which prompted all of the above, but also gave some help for those still having problems. Here is a good email for helping you with larger than 2GB SD and a few Linux commands to make it happen. Please note the use of sdc# my not be the same on your system and you might want to try doing:
cat /proc/partitonsto see what your system sees the devices as, and then remember to use "/dev/sdc" for the whole device, and "/dev/sdc1" for the first partition. In some cases you may need to do the "dmesg" command to see if the system even reconized your device. If the SD device is corrupt, you will see the failure message in the dmseg ouput.
Bill, Actually, I am now using a 4GB SDHC to effectively boot my Sylvania 7" netbook, model SYNET7WID, with Debian-Lenny kernel 2.6.29 for the arm5tejl I found such 4GB SDHC cards at Staples. I purchased 2 x 4GB SDHC cards listed on page 5 of this week's Staples catalog. On sale this week for less than $14ea I believe. As root, 1st, partitioned the SDHC in a card-reader as follows with Linux fdisk: >/sbin/fdisk /dev/sdc sdc1 16MB type-4 <32MB fat16 , set as 'a' for actively-booting partition sdc2 3.7GB+ type-83 Linux sdc3 356MB type-82 Linux swap As root, 2nd, formatted the SDHC in the same card-reader in Linux by >/sbin/mkdosfs -ccvv /dev/sdc1 >/sbin/mke2fs -cvvj /dev/sdc2 >/sbin/badblocks -svvn /dev/sdc3 ; /sbin/mkswap -c /dev/sdc3 As root, 3rd, copied and expanded the fatpart.tgz and extpart.tgz onto the SDHC using the same card-reader in Linux by >mount -t msdos /dev/sdc1 /mnt/sdc1 ; mount -t ext3 /dev/sdc2 /mnt/sdc2 >cp source-folder/fatpart.tgz /mnt/sdc1 ; cp source-folder/extpart.tgz /mnt/sdc2 >tar -xzvf /mnt/sdc1/fatpart.tgz ; tar -xzvf /mnt/sdc2/extpart.tgz >sync >rm -f /mnt/sdc1/fatpart.tgz ; rm -f /mnt/sdc2/extpart.tgz >umount /mnt/sdc1 ; umount /mnt/sdc2 These steps worked great to get a SD-bootable Debian onto the Sylvania netbook! The reasoning for the oversized 356MB swap partition is that if I ever figure out how to upgrade the 108MB usable-RAM by adding an extra 128MG physical RAM, I'll then already have a 1.5 x pRAM swap-performance gain. Your links and the Bento-Linux Debian wiki have been very helpful for me. So thanks! goossbearsThanks goossbears! However I need to make a few comments on your very good email. I noticed your ID is different than mine - ending in WID, while mine ends in 526-R. Wonder what is the difference other than yours probably being WHITE and mine being RED. I noticed a few "-ccvv" options on your commands which I normally don't do. Thinking I might be missing something, I did a "man" on each one and suspect you have the two options swapped. "mke2fs" will accept a "-cc" and do the "check for bad block" step using a slower read-write process other than the normal fast-read/write. The "mkdosfs" man page only says the "-c" "does a bad block check" before doing any actual formatting.Bill, Seems that at least several corrections are in order: 1) sdc2 is actually 3.5GB or 3600+ MB. This HAS TO be true if the swap-part alone is 356MB! 2) Bento-Linux Debian does NOT create /dev/mmcblk0p3 by default--- mmcblk0p3 is the SDHC equivalent of /dev/sdc3 Once the SDHC is properly booting Debian, one has to issue a 'mknod /dev/mmcblk0p3 b 179 3' command as user root before carrying out 'mkswap -c /dev/mmcblk0p3' and 'swapon /dev/mmcblk0p3' -A
This brings me to one of my favorite comments and my personal way of doing things. One of the reasons I like using Linux, is the on-line "man" pages. Any command your not sure of, and this is really true when going from one version of linux to another (say x86 to ARM), you can check or in my case refresh your understanding of what happens by simply doing a "man command" at the prompt. In most cases this will show you just what the command does and what are the correct options for that command. It is way too easy to simply get confused, mis-type a command, or get your fingers crossed and not get the results you expected. When that happens, just do a "man" and see if you goofed in some way. I have noticed too that commands do change over time and distros will have some options that an other doesn't. So be warned, it never hurts to check first before following any commands you see listed here or anywhere else.
I hope this helps some of you understand the issues surrounding the use of SD devices with the ARM based netbooks and tablets. I am sure there is more that I could have said, but there are sites that will explain the finer points better. What I want to cover here was just a few points that seem to crop up regulary. I use the 2GB device because I know it will almost always. Keep in mind however that even these devices can not work always due to variations in vendor brands. Use of bigger than 2GB may or may not work and one reason is simply the vendors design that will be different than another one that worked for some one else.
The whole idea for this article was to point out a few simple facts that work for me. 2GB devices work for me almost always. I have had some luck with larger sizes, but the results is more luck than skill. Doing "dd" is not necessarily a good idea - you can corrupt the device if not careful. I recommend before doing anything, you do a "dd" of the stock or unchanged device first, so that if it becomes corrupted, you can try to restore it to the same format it was from the manufacturer. Please checkout my other articles for more about my experiences with both netbooks and tablets.
Here are some formats for SD device I happen to have on hand.
> hexdump -C crucial1gb.img 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 |................| 000001c0 04 00 06 04 c4 c8 81 00 00 00 7f c7 1d 00 00 00 |................| 000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.| 00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00010200 eb 00 90 20 20 20 20 20 20 20 20 00 02 20 01 00 |... .. ..| 00010210 02 00 02 00 00 f8 ef 00 3f 00 20 00 81 00 00 00 |........?. .....| 00010220 7f c7 1d 00 80 00 29 a9 3d 30 fc 4e 4f 20 4e 41 |......).=0.NO NA| 00010230 4d 45 20 20 20 20 46 41 54 31 36 20 20 20 00 00 |ME FAT16 ..| 00010240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| > hexdump -C kingston2gb.img 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 |................| 000001c0 0c 00 06 38 f8 b8 89 00 00 00 77 9f 3a 00 00 00 |...8......w.:...| 000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.| 00000200 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00011200 eb 00 90 20 20 20 20 20 20 20 20 00 02 40 01 00 |... ..@..| 00011210 02 00 02 00 00 f8 eb 00 3f 00 40 00 89 00 00 00 |........?.@.....| 00011220 77 9f 3a 00 80 00 29 37 2f e2 12 4e 4f 20 4e 41 |w.:...)7/..NO NA| 00011230 4d 45 20 20 20 20 46 41 54 31 36 20 20 20 00 00 |ME FAT16 ..| 00011240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| > hexdump -C patriot2gb.img 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 |................| 000001c0 04 00 06 0a ca ca 81 00 00 00 7f af 3b 00 00 00 |............;...| 000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.| 00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00010200 eb 00 90 20 20 20 20 20 20 20 20 00 02 40 01 00 |... ..@..| 00010210 02 00 02 00 00 f8 ef 00 3f 00 40 00 81 00 00 00 |........?.@.....| 00010220 7f af 3b 00 80 00 29 97 50 40 40 00 00 00 00 00 |..;...).P@@.....| 00010230 00 00 00 00 00 00 46 41 54 31 36 20 20 20 00 00 |......FAT16 ..| 00010240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| > hexdump -C sandisk2gb.img 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 |................| 000001c0 04 00 06 3f ff c9 81 00 00 00 ff ac 3b 00 00 00 |...?........;...| 000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.| 00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00010600 40 bc 03 00 9f 75 07 00 7b 5f 00 00 9e 94 04 00 |@....u..{_......| 00010610 61 bb 03 00 00 00 00 00 02 00 00 00 02 00 00 00 |a...............| 00010620 00 80 00 00 00 80 00 00 c0 3f 00 00 0f ce 9c 47 |.........?.....G| 00010630 f8 f2 ce 49 20 00 21 00 53 ef 00 00 01 00 00 00 |...I .!.S.......| 00010640 d7 83 9a 47 00 4e ed 00 00 00 00 00 01 00 00 00 |...G.N..........| 00010650 00 00 00 00 0b 00 00 00 80 00 00 00 30 00 00 00 |............0...| 00010660 02 00 00 00 03 00 00 00 fa a8 25 5c a4 40 48 61 |..........%\.@Ha| 00010670 ba 61 c2 ea 72 b9 b3 50 00 00 00 00 00 00 00 00 |.a..r..P........| 00010680 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| > hexdump -C patriot4gb.img 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 |................| 000001c0 03 01 0b 59 d9 cc 00 20 00 00 00 90 77 00 00 00 |...Y... ....w...| 000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.| 00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00400000 eb 00 90 20 20 20 20 20 20 20 20 00 02 40 88 18 |... ..@..| 00400010 02 00 00 00 00 f8 00 00 3f 00 80 00 00 20 00 00 |........?.... ..| 00400020 00 90 77 00 bc 03 00 00 00 00 00 00 02 00 00 00 |..w.............| 00400030 01 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00400040 80 00 29 97 50 42 51 00 00 00 00 00 00 00 00 00 |..).PBQ.........| 00400050 00 00 46 41 54 33 32 20 20 20 00 00 00 00 00 00 |..FAT32 ......| 00400060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| > hexdump -C pqi8gb.img 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 82 |................| 000001c0 03 00 0b e8 d4 d4 00 20 00 00 00 54 f0 00 00 00 |....... ...T....| 000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.| 00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00400400 a0 0a 0f 00 80 0a 1e 00 86 80 01 00 5f f5 1c 00 |............_...| 00400410 6f 0a 0f 00 00 00 00 00 02 00 00 00 02 00 00 00 |o...............| 00400420 00 80 00 00 00 80 00 00 20 3f 00 00 38 9f 9a 47 |........ ?..8..G| 00400430 e0 10 31 4d 06 00 1f 00 53 ef 02 00 01 00 00 00 |..1M....S.......| 00400440 5f 9d 9a 47 00 4e ed 00 00 00 00 00 01 00 00 00 |_..G.N..........| 00400450 00 00 00 00 0b 00 00 00 80 00 00 00 30 00 00 00 |............0...| 00400460 02 00 00 00 03 00 00 00 62 2a 75 96 bc 03 44 b1 |........b*u...D.| 00400470 b8 f8 06 31 20 d9 9a b2 00 00 00 00 00 00 00 00 |...1 ...........| 00400480 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
More later. Under Dev....
Till then enjoy!
Links
The SYNET07526-R on-line - see web pages from the netbook.