[INFO]What is EpicMTD, and what you need to know.

Search This thread

AproSamurai

Inactive Recognized Developer
Jul 4, 2010
1,668
1,183
Van Nuys, CA
github.com
Getting started

Before I get into the thick of this, I've been for a little over a week or maybe even more taking as much time as I can to explain to people what MTD is and the risks of it. And unfortunately most people just by natural human tendencies have an issue comprehending it which believe me is perfectly fine haha, it's a lot to take at once. So I'm going to layout the basic need to knows, and if any more information is needed feel free to pm me and I'll add it into this main post.


I'm going to try to make this as simplistic as I can.:x


What is a partition?

A partition is an area of allocated space, a division of the whole overall area of space. In this case our partitions on the Epic 4G are /System, /Data, as well as /Cache. All with set permanent sizes.

What is a partition map?

A partition map is the configuration of our partitions, it's what in a vagueness sets our required sizes for the divisions of our nand also known as flash memory. A partition or partition map should not be confused with a file system. An example would be BML and MTD.

What is a file system?

A file system resides on the partition map and governs the data being read/wrote/moved/etc by the Operating System, in this case Android. Changing a file system is less complex than an overall change in partition mapping. They again, are not the same thing.

What is MTD?

MTD is an Open Source Partition map. It allows those who are using it control over how their partitions are sized and how much space is allocated here and how much space is taken away from there. Currently on MTD we have 689 megabytes of space allocated to our /data partition allowing more to be downloaded from the market as an example. MTD as a partition config has YAFFS2 as a file system residing on it governing how data is transferred and the speed of which it is done. EXT2 through 4 aren't possible on the MTD platform, just as YAFFS2 may not be possible on the BML proprietary platform.

What is BML?

BML like MTD is a partition map, however it is proprietary in nature, Close Source if you will. The size for /System /Data /Cache is set and permanent and makes opening up space more of a task for Developers. Stock the Epic 4G comes on BML, and is running RFS as it's file system, once rooted you can leave RFS for EXT4 (Journaled or Un-Journaled) as long as the kernel you use allows for EXT4. But in the end, changing a file system on BML does not lessen or enhance the control you have over your partitions.

What do I need to know before flashing a rom with this?

Currently there are two distributions which have moved over to the MTD platform.

One of which and the first inital one being:

[ROM] Epicmtd CM7 SELFKANG (12/10) - 2.3.7

And the second which is a basis of the first:

[ACS] [MTD] [YAFFS2] MIUI 1.12.2 Beta 6 MTD (Updated 12/10/2011)

Within the flashable zips for these two roms there are scripts which completely format your device and move you to MTD. It is required to back up the things you wish to keep with Titanium backup if you have it. Nandroids from RFS/EXT4/BML do not work on MTD/YAFFS2. Alternatively if you have purchased appextractor or titanium back up pro licensing from the Android market you can make a nandroid before your move and then extract the data apps or system apps you want from that backup while on MTD/YAFFS2 without going into recovery.

When flashing one of these ROMS in CWM5 your phone shall reboot during the installation if it finds you're on BML, don't panic it is a natural process of this move.


When booting into recovery on MTD it reacts to how long you hold the 3 button combination. Being Volume down, Camera, and Power. Don't panic if it doesn't pop up, you must let go to let it know which path it goes to. If your phone looks like it's booting again don't do the combination. It's switching from the init to the recovery.

CWM 5 is not broken, on MTD our kernel now has a 2 stage init. And it's part of the process.

How do I go about flashing other roms if they're not MTD?

Flashing a Stock TouchWiz rom can be very problematic, mainly due to the nature of and differences between MTD and BML. Currently there isn't a stock MTD kernel. To return to BML, you have a choice of either using Heimdall or Odin. To do so you require the victory.pit as well as a stock tar of your choice which includes our bootloader so that when you repartition your device all goes well without problem. There is no method to return without using Odin/Heimdall because BML is a proprietary configuration. We lack the tools to replicate Samsung's methods and mannerisms.


What does it mean for me as an end user?

As an End User, MTD is an opening to a new life for the Epic 4G. Things like ICS, more space in data or system, are more within our reach and grasp due to the nature of Open Source MTD is immersed in. We're closer to the Captivate, Fascinate, Vibrant, and Galaxy S international by being on MTD, we've that new freedom they've had for a long time. Not to say things like ICS aren't possible on BML but with this we're at a better standing point.


Stock EI22 on MTD

noobnl as well as Tortel have worked together to put a stock EI22 rom for the MTD platform which can be found here.

[EI22] Stock-ish MTD Build

This is for a stock experience and for those want to use MTD as well as make use of the stock features our phone has, nothing out of the ordinary or custom, just as a basic point. Rom Developers can go on towards moving their roms over to this platform now with the use of the boot.img but for now kernel developers will still have an issue nonetheless.



Those responsible for this in no specific order: Decad3nce, noobnl, jt1134, mkasick, nullghost, nubecoder, DRockstar, UberPinguin, Rodderik, wtogami, as well as countless others.



All things within this thread are subject to change if a need for correction is to be met.
 
Last edited:

roddygonzo17

Senior Member
Nov 11, 2011
117
25
Too bad this wasn't up before I flashed the MIUI update.... It looks like MTD=FML for me. I now have no choice on if i want 4g or not because the only 2 ROMs with MTD are CM7 and MIUI which dont support 4g. Grrrr. I hope someone can make something to get back to EXT4 or RFS W/O odin or heimdall. Last time I used odin to go to a stock ROM it ended up hard bricking my phone and i had to pay $600 for a new one.

I hope other users read this post before making the ssame mistake I did. Thank you AproSamurai.
 

MДЯCЦSДИT

Inactive Recognized Developer
Nov 21, 2010
6,563
4,616
No. Those are proprietary. You need to use Odin because it has the Samsung code that we don't have.

Edit: make sure you use a pit and make sure you check repartition and auto reboot. Nothing else.

Sent from my SPH-D700 using XDA App
 
Last edited:
  • Like
Reactions: Jumpshotjrh

AproSamurai

Inactive Recognized Developer
Jul 4, 2010
1,668
1,183
Van Nuys, CA
github.com
Too bad this wasn't up before I flashed the MIUI update.... It looks like MTD=FML for me. I now have no choice on if i want 4g or not because the only 2 ROMs with MTD are CM7 and MIUI which dont support 4g. Grrrr. I hope someone can make something to get back to EXT4 or RFS W/O odin or heimdall. Last time I used odin to go to a stock ROM it ended up hard bricking my phone and i had to pay $600 for a new one.

I hope other users read this post before making the ssame mistake I did. Thank you AproSamurai.

I apologize I couldn't have gotten it out sooner. Been a bit busy as of late, my apologies. Things are being worked on now regarding overlay and 911 by the CM team. And then CM will be official and we'll begin to see work on ICS and beyond, if that's of any consolation.:x
 

|| Acer ||

Senior Member
Oct 21, 2010
3,518
528
Chicago
Too bad this wasn't up before I flashed the MIUI update.... It looks like MTD=FML for me. I now have no choice on if i want 4g or not because the only 2 ROMs with MTD are CM7 and MIUI which dont support 4g. Grrrr. I hope someone can make something to get back to EXT4 or RFS W/O odin or heimdall. Last time I used odin to go to a stock ROM it ended up hard bricking my phone and i had to pay $600 for a new one.

I hope other users read this post before making the ssame mistake I did. Thank you AproSamurai.


You're gonna have to Odin, sorry. There's absolutely no way and there most likely will never be a way without it.

By the way, $600? I've bricked my phone a few times, and when I went to sprint I got a replacement for $35. Not sure what you did there.

Sent from my Samsung Epic using CM7!
 

roddygonzo17

Senior Member
Nov 11, 2011
117
25
Thanks for a quick reply marcusant. If its not too much of a hassle would you mind making a video and possibly post links for the .tar and .pit to use unless the .pit is the same as for froyo. I just really need my phone and dont want to have to buy another one.

---------- Post added at 07:31 PM ---------- Previous post was at 07:22 PM ----------

You're gonna have to Odin, sorry. There's absolutely no way and there most likely will never be a way without it.

By the way, $600? I've bricked my phone a few times, and when I went to sprint I got a replacement for $35. Not sure what you did there.

Sent from my Samsung Epic using CM7!

The representative from sprint told me that the only way i would have been able to brick it like that (would not turn on, no recovery mode, and no download mode and when plugged the charger in it wouldnt charge or be recognized by the computer) is if i rooted it which voided my warranty and wouldnt be covered by insurance.
 

onilink67

Senior Member
Nov 23, 2008
298
48
Austin
The representative from sprint told me that the only way i would have been able to brick it like that (would not turn on, no recovery mode, and no download mode and when plugged the charger in it wouldnt charge or be recognized by the computer) is if i rooted it which voided my warranty and wouldnt be covered by insurance.

I would have fought that by playing stupid and asking what he was talking about. Sprint also came out last year stating rooting does not void warranty but did require being noted on your account IIRC. I can give at least 1 scenario where that could have happened without rooting ... go drop your phone in the bathtub.

Memory modules and other ICs can easily go bad as well so sprint employee was playing a jumping to conclusion game and a manager would have been called over quickly.
 

roddygonzo17

Senior Member
Nov 11, 2011
117
25
I would have fought that by playing stupid and asking what he was talking about. Sprint also came out last year stating rooting does not void warranty but did require being noted on your account IIRC. I can give at least 1 scenario where that could have happened without rooting ... go drop your phone in the bathtub.

Memory modules and other ICs can easily go bad as well so sprint employee was playing a jumping to conclusion game and a manager would have been called over quickly.

You know I wasn't really thinking of that at that point, i was just worried about getting my phone back but that would have been a great idea. That way the little stickers that turn red when they get wet would have changed colors since water damage is covered.
 

MДЯCЦSДИT

Inactive Recognized Developer
Nov 21, 2010
6,563
4,616
I need to make a tutorial to restore... I'm really busy right now but will try to put up a simple guide without pictures. When I have time I will do pictures or a video. *qbking77 may beat me.

Sent from my SPH-D700 using XDA App
 
  • Like
Reactions: Jumpshotjrh
Thanks for a quick reply marcusant. If its not too much of a hassle would you mind making a video and possibly post links for the .tar and .pit to use unless the .pit is the same as for froyo. I just really need my phone and dont want to have to buy another one.


http://db.tt/Pf4qPUIV

This is the tar and pit file.
 
  • Like
Reactions: flastnoles11

cavey8500

Senior Member
Apr 29, 2008
268
6
edgewood, WA
very usefull info, im allready on one before this was posted, but i knew most of what i needed, you should ask qbking to put his video in the op. it has alot of good info in it for those people who dont read anything.....
 

duce102

Senior Member
Feb 4, 2011
1,535
507
North Carolina
Samsung Galaxy S20 FE
If I,

1.) make a nand backup in CWM5 of MTD CM7, would I be able to Odin back to stock, then restore the nand backup?

Or,

2.) would I have to reflash the ROM then advanced restore data?

Im leaning toward option 2 since CWM5 wont preserve the partition map, only the filesystem. I just want to be sure.


Thank you Apro :D
vvvvvvvvvvvvvvvvvv
 
Last edited:

AproSamurai

Inactive Recognized Developer
Jul 4, 2010
1,668
1,183
Van Nuys, CA
github.com
If I,

1.) make a nand backup in CWM5 of MTD CM7, would I be able to Odin back to stock, then restore the nand backup?

Or,

2.) would I have to reflash the ROM then advanced restore data?

Im leaning toward option 2 since CWM5 wont preserve the partition map, only the filesystem. I just want to be sure.

2 would be the correct answer to your question. :)
 
  • Like
Reactions: duce102

migmartinez

Member
Aug 23, 2011
41
8
I installed the miui and didn't realize that I would have oden back to stock but I just followed qbking's video and I after that I was able to restore my nandroid backup. I got freaked out because i couldnt restore my backup at 1st but in the end it was my fault for not reading before l did it.

Sent from my SPH-D700 using XDA App
 

I Brick Phones

Senior Member
Sep 14, 2008
741
380
KC
You're gonna have to Odin, sorry. There's absolutely no way and there most likely will never be a way without it.

By the way, $600? I've bricked my phone a few times, and when I went to sprint I got a replacement for $35. Not sure what you did there.

Sent from my Samsung Epic using CM7!

only $35? I haven't had to send my Epic in for replacement yet but every phone i've sent to Asurion in the past is always $100 per incident... are you on a different insurance plan or something?
 

Top Liked Posts

  • There are no posts matching your filters.
  • 101
    Getting started

    Before I get into the thick of this, I've been for a little over a week or maybe even more taking as much time as I can to explain to people what MTD is and the risks of it. And unfortunately most people just by natural human tendencies have an issue comprehending it which believe me is perfectly fine haha, it's a lot to take at once. So I'm going to layout the basic need to knows, and if any more information is needed feel free to pm me and I'll add it into this main post.


    I'm going to try to make this as simplistic as I can.:x


    What is a partition?

    A partition is an area of allocated space, a division of the whole overall area of space. In this case our partitions on the Epic 4G are /System, /Data, as well as /Cache. All with set permanent sizes.

    What is a partition map?

    A partition map is the configuration of our partitions, it's what in a vagueness sets our required sizes for the divisions of our nand also known as flash memory. A partition or partition map should not be confused with a file system. An example would be BML and MTD.

    What is a file system?

    A file system resides on the partition map and governs the data being read/wrote/moved/etc by the Operating System, in this case Android. Changing a file system is less complex than an overall change in partition mapping. They again, are not the same thing.

    What is MTD?

    MTD is an Open Source Partition map. It allows those who are using it control over how their partitions are sized and how much space is allocated here and how much space is taken away from there. Currently on MTD we have 689 megabytes of space allocated to our /data partition allowing more to be downloaded from the market as an example. MTD as a partition config has YAFFS2 as a file system residing on it governing how data is transferred and the speed of which it is done. EXT2 through 4 aren't possible on the MTD platform, just as YAFFS2 may not be possible on the BML proprietary platform.

    What is BML?

    BML like MTD is a partition map, however it is proprietary in nature, Close Source if you will. The size for /System /Data /Cache is set and permanent and makes opening up space more of a task for Developers. Stock the Epic 4G comes on BML, and is running RFS as it's file system, once rooted you can leave RFS for EXT4 (Journaled or Un-Journaled) as long as the kernel you use allows for EXT4. But in the end, changing a file system on BML does not lessen or enhance the control you have over your partitions.

    What do I need to know before flashing a rom with this?

    Currently there are two distributions which have moved over to the MTD platform.

    One of which and the first inital one being:

    [ROM] Epicmtd CM7 SELFKANG (12/10) - 2.3.7

    And the second which is a basis of the first:

    [ACS] [MTD] [YAFFS2] MIUI 1.12.2 Beta 6 MTD (Updated 12/10/2011)

    Within the flashable zips for these two roms there are scripts which completely format your device and move you to MTD. It is required to back up the things you wish to keep with Titanium backup if you have it. Nandroids from RFS/EXT4/BML do not work on MTD/YAFFS2. Alternatively if you have purchased appextractor or titanium back up pro licensing from the Android market you can make a nandroid before your move and then extract the data apps or system apps you want from that backup while on MTD/YAFFS2 without going into recovery.

    When flashing one of these ROMS in CWM5 your phone shall reboot during the installation if it finds you're on BML, don't panic it is a natural process of this move.


    When booting into recovery on MTD it reacts to how long you hold the 3 button combination. Being Volume down, Camera, and Power. Don't panic if it doesn't pop up, you must let go to let it know which path it goes to. If your phone looks like it's booting again don't do the combination. It's switching from the init to the recovery.

    CWM 5 is not broken, on MTD our kernel now has a 2 stage init. And it's part of the process.

    How do I go about flashing other roms if they're not MTD?

    Flashing a Stock TouchWiz rom can be very problematic, mainly due to the nature of and differences between MTD and BML. Currently there isn't a stock MTD kernel. To return to BML, you have a choice of either using Heimdall or Odin. To do so you require the victory.pit as well as a stock tar of your choice which includes our bootloader so that when you repartition your device all goes well without problem. There is no method to return without using Odin/Heimdall because BML is a proprietary configuration. We lack the tools to replicate Samsung's methods and mannerisms.


    What does it mean for me as an end user?

    As an End User, MTD is an opening to a new life for the Epic 4G. Things like ICS, more space in data or system, are more within our reach and grasp due to the nature of Open Source MTD is immersed in. We're closer to the Captivate, Fascinate, Vibrant, and Galaxy S international by being on MTD, we've that new freedom they've had for a long time. Not to say things like ICS aren't possible on BML but with this we're at a better standing point.


    Stock EI22 on MTD

    noobnl as well as Tortel have worked together to put a stock EI22 rom for the MTD platform which can be found here.

    [EI22] Stock-ish MTD Build

    This is for a stock experience and for those want to use MTD as well as make use of the stock features our phone has, nothing out of the ordinary or custom, just as a basic point. Rom Developers can go on towards moving their roms over to this platform now with the use of the boot.img but for now kernel developers will still have an issue nonetheless.



    Those responsible for this in no specific order: Decad3nce, noobnl, jt1134, mkasick, nullghost, nubecoder, DRockstar, UberPinguin, Rodderik, wtogami, as well as countless others.



    All things within this thread are subject to change if a need for correction is to be met.
    10
    I'm curious how the boot up process works with BML/RFS (or EXT4) vs MTD/YAFFS2.
    It's the same process until the kernel and initramfs is loaded. Specifically:
    • SoC ROM code loads and boots the Primitive Bootloader (PBL, boot.bin).
    • PBL searches the device partitions for the Secondary Bootloader (SBL, Sbl.bin), loads, and boots that.
    • SBL checks the "reboot mode" in param.blk (on stl6) and on a normal boot, loads the kernel stored in bml7 with init.rc, and on a recovery boot, loads the kernel stored in bml8. It also checks if the vol-down, camera, and power buttons are presed, and if so, sets the reboot mode for a recovery boot and loads the kernel stored in bml8.
    • The loaded kernel (stored on bml7 or bml8) also contains a initramfs, or root file system image. /init, in the initramfs checks the kernel command-line for a "bootmode" parameter set by SBL, which determines whether init.rc (normal boot) or recovery.rc/fota.rc (recovery boot) should be loaded.
    • As part of executing init.rc (or recovery.rc/fota.rc), the appropriate storage modules are loaded (fsr.ko, fsr_stl.ko, rfs.ko, rfs_glue.ko, j4fs.ko, and param.ko for a BML kernel), and various file-systems are mounted (stl6 as /mnt/.lfs, stl9 as /system, stl10 as /data, and stl11 as /cache for BML).

    An MTD kernel differs by the storage drivers used in Linux. Instead of the Samsung proprietary modules, we use the open-source OneNAND MTD driver. Now, our OneNAND chip is different/newer than the one used in other SGS devices, so we actually had to backport the "samsung_audi" driver from the SGSII kernel source tree. Amusingly, the SGSII doesn't use MTD either, but some SGSII development prototype devices did, so somewhere along the line Samsung added that driver to the kernel tree to support their newer OneNAND chips. This is one of the reasons why it took a while to support MTD on our device as the driver that ships with SGS and Nexus S kernels doesn't work for us.

    One of the takeaways from the earlier description of the Samsung boot chain is that both PBL and SBL must support I/O to the OneNAND chip, the OneNAND partition table, and the BML partition encoding. Additionally SBL must support STL for flashing via download mode, and for reading/writing param.blk. So, for MTD support, it's critical that retain compatibility with the partition table format, and use BML-encoded partitions for the kernel. Actually, the fact that we're running MTD is essentially invisible to the bootloader, it does the exact same booting sequence until the point that the kernel is booted and "we" have control.

    Where MTD differs is in the format of the /system, /data, and /cache partitions. Instead of using RFS (or ext4) on STL, on BML, we use yaffs2 straight on top of MTD. To flash the kernel, CyanogenMod uses a user-space tool, bml_over_mtd, to BML-encode a kernel and write it to the raw MTD device. That's basically it.

    I was hoping it would help me understand why reboot to recovery doesn't work on MTD yet and also why the 3 finger causes loops until you release it.
    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.

    As for the three-finger issue, that's an artifact of a fix that we have to use in order to boot into recovery on MTD kernels. The Fascinate, which has the same problem, uses a very similar fix.

    Earlier I mentioned that a normal vs recovey boot is determined by the "reboot mode" setting in param.blk. Specifically, when you do a three-finger boot, SBL sets "reboot mode" to boot recovery before loading bml8. Now, it's the responsibility of the recovery kernel to reset the reboot mode in parma.blk back to normal, otherwise SBL will always load bml8 and boot recovery on subsequent reboots/powerups, whether the vol-down, camera, and power buttons are held or not.

    Now, the problem is that param.blk is stored on a partition, stl6, that must remain BML/STL/j4fs encoded for bootloader compatibility, and so MTD kernels lack the driver support to mount that partition. Thus, we can't reset the reboot mode setting.

    So, the three-finger fix consists of a kernel with a stub initramfs installed to bml8. It's actually a BML kernel, that is, it supports Samsung's storage modules and not MTD. The sole job of this kernel is to reset the reboot mode in param.blk, poke a magic value into persistent memory, and reboot. On reboot, the MTD kernel in bml7 is loaded, checks for our magic value in persistent memory, and boot into recovery. The caveat is that, if you keep the vol-down, camera, and power buttons held, SBL will continue to boot bml8 repeatedly, which continues to reset the reboot mode and reboot the device.

    Hope that helps.
    4
    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? :confused:

    I just tested it out. I flashed my ROM using this kernel with this partition layout...

    Code:
    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% /system

    I then flashed a kernel with the following partition layout...

    Code:
    Filesystem                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% /data

    ...and the partitions mounted just fine, with different sizes!

    Unfortunately, after flashing Tortell's MTD kernel which has the "stock" partition layout (a different size for /system), I got this message when trying to mount system partition:

    Code:
    Failed to mount /dev/block/mtdblock2 on /system: Invalid argument

    /data and /cache still mounted.

    Flashing back the original kernel allowed my to mount to all partitions again.


    However, if your device wasn't converted to MTD yet the flashable ZIP for a ROM (with kernel) would contain the script instruction to check and if not converted -> execute conversion... at which point it would look for these values in the kernel. Right?

    No, it just checks to see if the device is MTD or BML. If it is BML, it flashes the MTD kernel and reboots. I added a part to that script which checks the partition sizes and if they don't match up with what they should be, it does the same thing - flashes the kernel and reboots. I inserted the code into updater.sh. This could be put into a seperate shell script. Here is the code. It's adapted from the code that checks for BML/MTD.

    Code:
    # 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
    fi

    Taking that a step further, each ROM maker could choose whether to check the sizes of MTD partitions and if in tolerance (some predefined range of acceptable) it would flash ROM package on existing partition sizes, OR if not acceptable it could wipe out the partition (and all data on it) and start over with preferred sizes. Right?

    Exactly.

    ---------- Post added at 12:14 PM ---------- Previous post was at 12:04 PM ----------

    Let me add one very important note. After flashing those different kernels and mounting partitions with them, when I finally booted my phone, it booted fine, but my home screen layout has reverted to stock layout, which suggests that some of my data was munched when I mounted /data using different sizes. My downloaded apps still show up in my launcher, so some of my data is still there, but obviously some of it was lost.

    I think it's safe to say that if partition layouts are changed, partitions will need to be erased and recreated.
    3
    If I install the new CM 7.2 RC0 MTD on my phone, then is there any way I can still dual-boot a TW rom from my SD card?
    Yes, 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.

    I prepared an EI22 almost-stock kernel (as in, bug-compatible with stock) for Warren and he posted some notes on his blog (see "Multiboot Android for Debugging/Testing" section) for getting a TW ROM on SD. The patch archive has a README with some better instructions, although I threw the whole thing together rather quickly.

    The tricky part is you'll have to flash back to EI22 first and make tar of /system (a .tar system dump, not an Odin-flashable .tar). Otherwise it works essentially same as the CM7 SD ROM I posted for the 1022 version a while back.

    I wonder why there's no kexec support in the MTD kernel.
    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'm guessing other MTD kernels are based off the CM7 one and so are missing the patches for that reason. There's nothing inherent about MTD that precludes the ability to patch in kexec support.

    but kexecing a boot.img is rather different than a zImage.
    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.

    However, I don't recommend using unmodified boot.img kernels as they contain stage1 in their embedded initramfs which, while shouldn't be executed, it's never removed either, and so takes up extra memory. For whichever boot.img kernel you're using, I recommend rebuilding it from source with CONFIG_INITRAMFS_SOURCE="" to force it to build with a stub embedded initramfs, then use boot.cpio.gz or recovery.cpio.gz with --initrd to avoid stage1 entirely.

    If you can't rebuild the boot.img kernel from source, you can repack it with a stub initramfs, but that's almost always harder to do.
    3
    Seems like a risky approach to map the partitions in the kernel and not have it fixed elsewhere, but I assume this is best solution for employing MTD. Wonder if any other approaches are available or were considered?
    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.

    It's possible to add on-flash partition table support for MTD, but would require some amount of code. I'd guess it's a reasonably-sized project for someone sufficiently ambitious. The format is known for the relevant portion of the partition table, plus there's code in the tfsr driver for reading it also--which I wouldn't copy, but might help in making sense of it.

    Honestly there is NO point to using MTD/Yaffs2 if we don't make use of the ability to change partition sizes.
    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.

    The other major benefit of MTD would be the ability to forward port victory (Epic) support to a Nexus S-derived (S5PV210) ICS kernel, i.e., for CM9. With Samsung's proprietary storage stack, we're stuck on our present kernel version unless newer modules leak out somewhere. Given that Samsung appears uninterested in porting ICS to the SGS, those might be hard to come by, especially timely.

    Personally I don't think MTD is particularly advantageous to TW kernels, aside from where basing on the EpicCM kernel makes such kernels easier to maintain.