On Tue, Oct 12, 2010 at 11:15 AM, Loïc Minier <loic.min...@linaro.org> wrote: > On Tue, Oct 12, 2010, Dave Martin wrote: >> 32 sectors * 16 heads is what I usually use -- this gives a 256KB >> cylinder size, which should be an integral number of underlying erase >> blocks on pretty much any flash device, and has divided exactly into >> the size of every SD card of flash stick I have ever seen. If we >> really want to be clever, we could use factor /sys/block/<dev>/size, >> to choose head and sector counts, but I doubt that it's worth it. > > Unfortunately, OMAP's boot ROM imposes the current head/sector counts > we're using > > However, Linux never uses CHS, but always LBA; so we could arrange to > use proper CHS and still align the partition properly
Yes, Linux 100% does not care about the CHS junk in the partition table, or the head and sector counts (since when talking to an SD card or similar, the interface has no concept of heads or sectors ... just LBA offsets or something) So we can make the /boot partition look like it has 63*255 geometry, and we can make it start at sector offset 63. Everything else can be determined based on sane absolute sector offsets. > I don't know of any tool which allows doing that properly; I trust > parted, but I never managed to force chs geometry with it. Not sure > whether we can convince fdisk to do it, don't really like driving this > thing sfdisk seems to works: e.g. device=<target device or image file> sector_size=512 device_total_sectors=<total sectors, from sysfs, built-in default (for --image_file) or command line> boot_partition_MB=64 # approximate size in MB for the root partition # number of sectors per partitioning unit; should be a multiple of the rootfs block size (4KiB) and the underlying flash erase block size (256KiB): # 512 (256KiB) is probably a good choice. partition_unit_sectors=512 target_fake_spt=63 # sectors-per-track to fake for the boot partition geometry target_fake_heads=255 # heads to fake for the boot partition geometry boot_start_sectors=$target_fake_spt boot_size_sectors=$((boot_partition_MB/(sector_size*partition_unit_sectors)*partition_unit_sectors - boot_start_sectors)) boot_type=0xC # FAT32 LBA root_start_sectors=$((boot_start_sectors + boot_size_sectors)) root_size_sectors=$((device_total_sectors - root_start_sectors)) root_type=0x83 # Linux filesystem cat <<EOF | sfdisk --force -S$target_fake_spt -H$target_fake_heads -us "$device" $boot_start_sectors,$boot_size_sectors,$boot_type,* $root_start_sectors,$root_size_sectors,$root_type EOF # --force is needed so that sfdisk accepts the non-cylinder aligned partition boundaries. One advantage is that we can set up the partition table without ever needing to parse the output of any partitioner (which I view as being very fragile...) With a bit of luck, we can also lose the dependencies on parted and fdisk. I don't yet know whether this approach will actually boot in Beagle though. > >> Disabling the journal (for ext4, use -onoload / for ext3, mount with >> -text2 instead) and/or mounting with noatime (-onoatime) would also >> make sense when mounting the rootfs to populate it, especially when >> using --mmc; this might improve performance a little. > > I think relatime is the default already, it's probably good enough; > isn't it? dunno, you may be right. I guess on atimes will get updated except on directories anyway -- the files are only written, not read. It would be interesting to benchmark whether disabling the journal makes any difference; I think it might improve things a little, but I haven't measured it. -obarrier=0 would also be sensible for ext3/4, since the only atomicity we care about it at filesystem unmount. [...] > > Oh ok; so can you arrange for CHS to look like 63 sectors and 255 > heads, and use rounded up LBA addresses with some tool of your choice? > > Probably the boot partition needs to really start at a CHS address, not > a LBA address Probably - the CHS fields in the partition table for everything except the boot partition can be (and on many disks actually are) complete garbage. Cheers ---Dave _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
