$35 is Sprint's warranty handling fee for people with no insurance.
Sent from my SPH-D700 using XDA App
[INFO]What is EpicMTD, and what you need to know.
- Thread starter AproSamurai
- Start date
$35 is Sprint's warranty handling fee for people with no insurance.
Sent from my SPH-D700 using XDA App
Thats crazy, I couldnt imagine paying $35 for a replacement. Ive gone through 7 epics, always next day delivered to store if they didnt have them in stock, always free (except for the $8 a month for black tie). I love insurance.
Very nicr write up Apro. I reccomend putting your race track analogy in there. That really made sense.
/sig
/sig
butler360 said:You rooted your wife?
I'm not sure how necessary it'd be, but I could perhaps go about doing so. Hmmmm, maybe.
Thanks for the write-up, AproSamurai. Now if I could just make myself sit through 7:21 of video and see what QBKing77 has to say, I'll be caught up on the major MTD tutorials available in the Epic forums!
Great news on MTD. Hopefully this makes the Cyanogenmod port a little more flexible and easier to maintain. I know it's been a beast.
I've been mostly running ROMs like Syndicate Froyo and lately ACS ICS 5.5. I don't use 4g much so I'm alright leaving that behind (for now) if/when the MTD roms get more solid.
Hopefully we see many/most Epic devs move over to MTD. Once we have more selection on MTD format I'm sure we'll have an easier time getting users to test new builds of Cyanogen and (hopefully) ICS one day.
I've been mostly running ROMs like Syndicate Froyo and lately ACS ICS 5.5. I don't use 4g much so I'm alright leaving that behind (for now) if/when the MTD roms get more solid.
Hopefully we see many/most Epic devs move over to MTD. Once we have more selection on MTD format I'm sure we'll have an easier time getting users to test new builds of Cyanogen and (hopefully) ICS one day.
I know right? I never bricked a phone, but I've came damn close (no boot, no download mode, etc.). I even exploded an LCD but with 35 bux (and *no* warranty) I was able to get a replacement phone. ODIN = Your best friend if you have an EPIC, do not fear it my friend. You can be back on stock in like 5 min.
wow, i totally just quoted the wrong post. this was to the dude who didnt want to odin after going to miui without knowing about MTD
Just to add to this, if you're constantly having trouble with Odin, it's probably your cable causing issues, not Odin. Death to the stock cable!
I know the Odin thing has been covered several times here, but I wanted to know if the Samsung Windows installer for EB13 would restore the partition from MTD to BML if I wanted return to another ROM after trying CM7?
Sorry to rehash the subject but I didn't see any mention of this option & I was curious if it would work.
Really? I've found the stock cable extremely reliable.
---------- Post added at 01:39 AM ---------- Previous post was at 01:28 AM ----------
I actually have a question too. I heard that this would help port roms from other phones like the ns4g. Specifically i want to know about the sense rom that is being worked on on the ns4g. I know how the majority of the community hates sense, but i like it and dont want to downgrade to an evo shift.
http://tinyurl.com/epicfix That will take you back to stock from MTD or corrupt partitions or whatever is wrong with your phone as long as it isn't hard bricked
I understand that being on MTD gives us the same partition control that some other smartphones enjoy, but what are the actual benefits? Does it make coding for CM9, etc easier? Does it allow for simple multi-booting? Can CWM still act as a recovery system for MTD ROM's? If not, then what do we use? I don't quite understand how this new partition mapping is actually useful.
ICS requires more /system space, so this is future proofing our developmental status.
Yes CWM still works as recovery, it just had to be modified for MTD.
/temporary sig
I hope that with 911 and Video Overlay working the official status comes in soon!
I'm curious how the boot up process works with BML/RFS (or EXT4) vs MTD/YAFFS2. I've googled and searched around but couldn't find a good comparison. Is there a resource you know of that outlines the steps after power-on with the BML/RFS and MTD/YAFFS2 - that covers what gets mounted, when, and how?
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 found some background and interesting dialogue in another thread on XDA but it left me with more questions than answers.
Nothing critical, just my curiosity about it really. If you have any suggestions on how to better understand the boot process on MTD and get more transparency there I'd love to hear about it. Thanks!
I hope that with 911 and Video Overlay working the official status comes in soon!
I'm curious how the boot up process works with BML/RFS (or EXT4) vs MTD/YAFFS2. I've googled and searched around but couldn't find a good comparison. Is there a resource you know of that outlines the steps after power-on with the BML/RFS and MTD/YAFFS2 - that covers what gets mounted, when, and how?
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 found some background and interesting dialogue in another thread on XDA but it left me with more questions than answers.
Nothing critical, just my curiosity about it really. If you have any suggestions on how to better understand the boot process on MTD and get more transparency there I'd love to hear about it. Thanks!
I myself have been wondering that, almost a month ago when everyone was discussing moving to MTD(I'm not a member of the EpicCM team) I was curious about how the partitions would work and be mounted and I honestly(personal guess) believe it mirrors how BML handles it. I think that is an essential thing for our phone to function in the way that it does. But I'm not the most aware of how and in what way the mounting is executed upon boot which makes it differ, I honestly think we may be overthinking it and it's exactly the same on both of our parts. Just a few differences in what happens when it's mounted. But I've no shame in answering something I'm not sure about, I just can't say I'm right on it lol.
Damn you for asking me the question I've been trying to figure out myself lol.
Also I believe that is more or less how it's linked to the recovery overall and what the functions within the UI to boot into recovery are looking for. In our boot.imgs we have our init and we also have our recovery(to be simple), which is why the oddness happens with 3 finger boot, you releasing it allows it to know when it needs to switch from init to recovery, if you hold on it's at a standstill, it needs to switch from one to another and I don't believe there is a clear path without it switching from one to the other. So that jump for the meantime is just something that isn't too big of a deal, nor is it broken just handled differently.
I hope that was of some help, I can be wrong in some areas though, so if anyone knows differently feel free to correct me.
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'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.
Last edited:
u, sir, are not a fountain of knowledge, but rather a geyser of intelligence. thank u for sharing
Last edited:
Similar threads
- Locked
Top Liked Posts
-
There are no posts matching your filters.
-
101Getting 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
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'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.4If 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?
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.
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
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
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.
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.
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
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.
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.
New posts
-
[ROM] [UNOFFICIAL] [11] DotOs 5.2.1 [G530FZ/F/H]- Latest: PuszekReksio
-
-