However, the kernel itself doesn't define the partition map....I'm not sure what they are using with MTD to set the partition map. It could be set in the conversion script or in a configuration file. I couldn't find it after a cursory skim of the contents of the CWM flashable zip. That has eluded me so far.
If you were to change the mapping (i.e. modify offset or size of a few partitions in samsung_epic.h) - compile and flash your kernel - what would happen? Assuming you didn't change ROM's - just kernels. My guess is nothing if your phone is already converted to MTD. The kernel should mount the partitions just fine without the map, right?
Filesystem Size Used Available Use% Mounted on
/dev/block/mtdblock4 25.0M 2.3M 22.7M 9% /cache
/dev/block/mtdblock3 695.0M 407.0M 288.0M 59% /data
/dev/block/mtdblock2 250.0M 206.2M 43.8M 82% /systemFilesystem Size Used Available Use% Mounted on
/dev/block/mtdblock4 50.0M 2.3M 47.7M 5% /cache
/dev/block/mtdblock2 250.0M 206.2M 43.8M 82% /system
/dev/block/mtdblock3 670.0M 407.0M 263.0M 61% /dataFailed to mount /dev/block/mtdblock2 on /system: Invalid argument# check to see if partition sizes are correct
/tmp/busybox mount -t yaffs2 /dev/block/mtdblock2 /system
/tmp/busybox mount -t yaffs2 /dev/block/mtdblock3 /data
if (! df /dev/block/mtdblock2 | grep "256000") || (! df /dev/block/mtdblock3 | grep "711680"); then
# Our partition sizes are not correct
# unmount, format and mount system
/tmp/busybox umount -l /system
/tmp/erase_image system
# unmount and format cache
/tmp/busybox umount -l /cache
/tmp/erase_image cache
# unmount and format datadata
/tmp/busybox umount -l /data
/tmp/erase_image userdata
# make sure sdcard is mounted
if ! /tmp/busybox grep -q /mnt/sdcard /proc/mounts ; then
/tmp/busybox mkdir -p /mnt/sdcard
/tmp/busybox umount -l /dev/block/mmcblk0p1
if ! /tmp/busybox mount -t vfat /dev/block/mmcblk0p1 /mnt/sdcard ; then
/tmp/busybox echo "Cannot mount sdcard."
exit 1
fi
fi
# remove old log
rm -rf /mnt/sdcard/cyanogenmod_bml.log
# everything is logged into /sdcard/cyanogenmod.log
exec >> /mnt/sdcard/cyanogenmod_bml.log 2>&1
# write the package path to sdcard cyanogenmod.cfg
if /tmp/busybox test -n "$UPDATE_PACKAGE" ; then
PACKAGE_LOCATION=${UPDATE_PACKAGE#/mnt}
/tmp/busybox echo "$PACKAGE_LOCATION" > /mnt/sdcard/cyanogenmod.cfg
fi
# Scorch any ROM Manager settings to require the user to reflash recovery
/tmp/busybox rm -f /mnt/sdcard/clockworkmod/.settings
# write new kernel to boot partition
/tmp/flash_image boot /tmp/boot.img
if [ "$?" != "0" ] ; then
exit 3
fi
/tmp/busybox sync
/sbin/reboot now
exit 0
fiThere is an on-flash partition table, bml2 (not mapped in mtd), and it would certainly make sense to support it under MTD kernels to allow for different partition sizes. It's not done simply becuase there's no MTD-pathway code for reading the on-flash partition table. Partition sizes are hardcoded in the Samsung MTD driver on the Nexus S, and, since that's how the driver was written, was kept for Galaxy S MTD kernels.
To be honest, the main benefit of MTD vs BML is maintenance of the CM port. Since all other supported SGS devices use MTD, for the Epic to use MTD reduces the amount of our device-specific configutation. While a BML-based CM7 port is certainly doable (an has been done), being the sole BML device means there's more configuration junk that we have to maintain.
It's the same process until the kernel and initramfs is loaded. Specifically:
I'm not sure why "reboot to recovery" doesn't work yet. As I understand, executing "reboot recovery" from adb or the command-line does work, although I've not verified that behavior myself. There's some bug that must prevent the command from working properly when executed from the UI, that needs to be investigated yet.
If you were to change the mapping (i.e. modify offset or size of a few partitions in samsung_epic.h) - compile and flash your kernel - what would happen? Assuming you didn't change ROM's - just kernels. My guess is nothing if your phone is already converted to MTD. The kernel should mount the partitions just fine without the map, right?
Filesystem Size Used Available Use% Mounted on
/dev/block/mtdblock4 25.0M 2.3M 22.7M 9% /cache
/dev/block/mtdblock3 695.0M 407.0M 288.0M 59% /data
/dev/block/mtdblock2 250.0M 206.2M 43.8M 82% /systemFilesystem Size Used Available Use% Mounted on
/dev/block/mtdblock4 50.0M 2.3M 47.7M 5% /cache
/dev/block/mtdblock2 250.0M 206.2M 43.8M 82% /system
/dev/block/mtdblock3 670.0M 407.0M 263.0M 61% /dataFailed to mount /dev/block/mtdblock2 on /system: Invalid argument# check to see if partition sizes are correct
/tmp/busybox mount -t yaffs2 /dev/block/mtdblock2 /system
/tmp/busybox mount -t yaffs2 /dev/block/mtdblock3 /data
if (! df /dev/block/mtdblock2 | grep "256000") || (! df /dev/block/mtdblock3 | grep "711680"); then
# Our partition sizes are not correct
# unmount, format and mount system
/tmp/busybox umount -l /system
/tmp/erase_image system
# unmount and format cache
/tmp/busybox umount -l /cache
/tmp/erase_image cache
# unmount and format datadata
/tmp/busybox umount -l /data
/tmp/erase_image userdata
# make sure sdcard is mounted
if ! /tmp/busybox grep -q /mnt/sdcard /proc/mounts ; then
/tmp/busybox mkdir -p /mnt/sdcard
/tmp/busybox umount -l /dev/block/mmcblk0p1
if ! /tmp/busybox mount -t vfat /dev/block/mmcblk0p1 /mnt/sdcard ; then
/tmp/busybox echo "Cannot mount sdcard."
exit 1
fi
fi
# remove old log
rm -rf /mnt/sdcard/cyanogenmod_bml.log
# everything is logged into /sdcard/cyanogenmod.log
exec >> /mnt/sdcard/cyanogenmod_bml.log 2>&1
# write the package path to sdcard cyanogenmod.cfg
if /tmp/busybox test -n "$UPDATE_PACKAGE" ; then
PACKAGE_LOCATION=${UPDATE_PACKAGE#/mnt}
/tmp/busybox echo "$PACKAGE_LOCATION" > /mnt/sdcard/cyanogenmod.cfg
fi
# Scorch any ROM Manager settings to require the user to reflash recovery
/tmp/busybox rm -f /mnt/sdcard/clockworkmod/.settings
# write new kernel to boot partition
/tmp/flash_image boot /tmp/boot.img
if [ "$?" != "0" ] ; then
exit 3
fi
/tmp/busybox sync
/sbin/reboot now
exit 0
fiYes, although I don't think anyone's actually tested it. You'll need a modified initramfs for the TW kernel to mount partitions from the SD card, but otherwise any kernel should work.
The EpicCM (now CM7 victory) kernel was forked from official GB sources very early on before the kexec patches were well-tested, and they just haven't been folded back in. That can be done, folks have just been very busy getting CM7 out the door.
I was looking into this last night. You should be able to kexec a boot.img as long as you extract boot.cpio.gz first and pass it into kexec with the --initrd parameter.
There is an on-flash partition table, bml2 (not mapped in mtd), and it would certainly make sense to support it under MTD kernels to allow for different partition sizes. It's not done simply becuase there's no MTD-pathway code for reading the on-flash partition table. Partition sizes are hardcoded in the Samsung MTD driver on the Nexus S, and, since that's how the driver was written, was kept for Galaxy S MTD kernels.
To be honest, the main benefit of MTD vs BML is maintenance of the CM port. Since all other supported SGS devices use MTD, for the Epic to use MTD reduces the amount of our device-specific configutation. While a BML-based CM7 port is certainly doable (an has been done), being the sole BML device means there's more configuration junk that we have to maintain.
