vfat partition file system reports size is 0.99GB
We met problem when using Mfgtools to update android image to 4GB SD card on MX53 SMD board.I got Mfgtools-Rel-11.03.00_ER_MX53_UPDATER.tar.gz, extract it and select "MX53SMD-Android-SD" config to burn Android image to SD card. Mfgtools use "Profiles\MX53 Linux Update\OS Firmware\ucl.xml" to control burning operation. It will fdisk 5 partitions on SD card. First partition is vfat, and others are EXT4. We can look at part of the code:
"push" body="$ mkfs.vfat /dev/mmcblk0p1">Formatting sd partition
"push" body="$ mkfs.ext4 /dev/mmcblk0p2">Formatting system partition
"push" body="$ mkfs.ext4 -O^extent /dev/mmcblk0p4">Formatting recovery partition
"push" body="$ mkfs.ext4 /dev/mmcblk0p5">Formatting data partition
"push" body="$ mkfs.ext4 -O^extent /dev/mmcblk0p6">Formatting cache partition
My SD card is 4GB, in this case, vfat partition assigned 3.3GB. But after burn image complete, I found fat partition file system only 0.99GB. I checked update log message, found vfat partition information is correct, 3.3GB size. and format that partition with tool "mkfs.vfat", the problem should comes from this tool. Normally, it should be such as word length issue,32 bits variable has limitation to access GB space size. And from the log, it shows that "mkfs.vfat" version is 2.11, date is 2005. It is six years old.
Found patch via google.
find a bug report in debian, it is known issue that mkfs.vfat 2.11 has bug that will limit fat format size smaller than 1GB. Got the patch, it is very simple, Just add specific CFLAGS in debian/rules.
ifeq ($(ARCH),alpha)
-OPTFLAGS="-fomit-frame-pointer -fno-strict-aliasing"
+OPTFLAGS="-fomit-frame-pointer -fno-strict-aliasing $(shell getconf LFS_CFLAGS)"
else
-OPTFLAGS="-O2 -fomit-frame-pointer"
+OPTFLAGS="-O2 -fomit-frame-pointer $(shell getconf LFS_CFLAGS)"
endif
What is LFS_CFLAGS?
$ getconf LFS_CFLAGS
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
OK, that is key point, it tells mkfs.vfat to support LARGEFILE_SOURCE and FILE_OFFSET_BITS is 64, that make sense.
Get LTIB1101, extract dosfstools package
$./ltib -m prep -p dosfstools
It extract source code in directory rpm/BUILD/dosfstools-2.11/, check debian/rules, but it already contains that patch. Oh, now we suppose that Mfstools default mkfs.vfat has problem, I need generate new mkfs.vfat to replace it.
Generate new Mfgtools ram rootfs.
Mfgtool use initramfs.cpio.gz.uboot as it rootfs when burning image.
execute ./ltib --selectype, select Mfgtools profile, and also select dosfstools and util-linux in package list, mkfs.vfat in dosfstools, sfdisk in util-linux. After building done, copy initramfs.cpio.gz.uboot to Mfgtools directory "Profiles\MX53 Linux Update\OS Firmware". Run Mfgtools to burn image into SD card, but unfortunately, vfat partitin file system report 0.99GB! Why?
Get latest dosfstools_3.0.11.orig.tar.gz
Just suppose this fix doesn't work at all, get latest dosfstools from
http://ftp.debian.org/debian/pool/main/d/dosfstools/dosfstools_3.0.11.orig.tar.gz. Put it in /opt/freescale/pkgs/. Modify "ltib/dist/lfs-5.1/dosfstools/dosfstools.spec" to support this new package. Regenerate initramfs.cpio.gz.uboot, testing. Oh, the vfat partition size changed, it change to 2GB size! Oh, that is not my desire... 2GB size normally is FAT16 limitation, but it shows that is FAT32.Must something wrong. I doubt SD card driver has problem to access 2GB size, something like SDHC issue. I want to use "mkfs.ext4 /dev/mmcblk0p1" it shows 3.3GB. SD card driver has no problem, problem comes from mkfs.vfat.
Debug dosfstools_3.0.11 mkdosfs.
I choose ltib environment for debuging, use mx53 SMD board with NFS. Extract dosfstool package.
$./ltib -m prep -p dosfstools
$ cd rpm/BUILD/dosfstools_3.0.11
$ make -j2
We got mkfsdos, it link to mkfs.vfat. Copy it to /tftpboot/sbin. In mx53 smd console, excute "mkfs.vfat", but it report error and cannot run. And then I want to try use ltib to build.
$./ltib -m scbuild -p dosfstools
Copy mkdosfs to /tftpboot/sbin, it can run, but vfat partition size still not correct. What is the difference between LTIB scbuild and directly make under dosfstools directory? Compare the build process message, found when use ltib scbuild it will pass CFLAGS in it, that is to say, CFLAG in mkdosfs Makefile will has no use. Here is the command line when execute ltib scbuild.
arm-none-linux-gnueabi-gcc -c -Dllseek=lseek64 -D_LARGEFILE64_SOURCE mkdosfs
I think that is the root cause, the CFLAG definition for ltib scbuild in "dist/lfs-5.1/dosfstools.spec", modified it:
%Build
-make CC="${TOOLCHAIN_PREFIX}gcc" CFLAGS="-Dllseek=lseek64 -D_LARGEFILE64_SOURCE"
+make CC="${TOOLCHAIN_PREFIX}gcc"
Build mkdosfs, copy it to /tftpboot/sbin, in mx53 SMD console
$ mkfs.vfat /dev/mmcblk0p1
$ mount -t vfat /dev/mmcblk0p1 /mnt
$ df
It shows 3.3GB.
We locate the root cause!
LTIB default dosfstools 2.11 also works
Turn back to LTIB default dosfstools 2.11, with same modification, mkfs.vfat make format the whole partition to correct size 3.3GB. Now, we known, the CFLAG in "dist/lfs-5.1/dosfstools.spec" cause the problem.
几年前，英国作家帕特里克•弗兰奇（Patrick French）造访了位于印度古吉拉特邦艾哈迈达巴德市郊的甘地纪念馆（Sabarmati ashram）。1930年，圣雄甘地（Mahatma Gandhi）领导的"食盐长征"正是从这里出发，向大海前进。让弗兰奇大为震惊的是，纪念馆的公共厕所竟然秽气熏天，于是他就去质问纪念馆秘书由谁负责打扫厕所。