Originally Posted by mkasick

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.

`reboot recovery` from adb/shell and rebooting to recovery from ROM Manager doesn't work for some reason. It just reboots. Right now, the only way I've been able to get into recovery while on MTD is to do the three finger salute.


Thanks for your post BTW. It helped me figure out what parts I needed to get my kernel working with MTD.

Is there anything that needs to be done to make a theme work on MTD/YAFFS2?

And what determines the partition sizes? Kernel, ROM, or other?

Originally Posted by theduce102

Is there anything that needs to be done to make a theme work on MTD/YAFFS2?

And what determines the partition sizes? Kernel, ROM, or other?

You need to go into CWM and into Mounts and mount system. To be able to flash a theme.

Originally Posted by theduce102

And what determines the partition sizes? Kernel, ROM, or other?

Partition sizes are set in the kernel. I imagine this can lead to all kinds of hilarity if someone flashes a ROM/kernel with one set of partition sizes and then flashes another MTD kernel with different partition sizes.

Originally Posted by toadlife

Partition sizes are set in the kernel. I imagine this can lead to all kinds of hilarity if someone flashes a ROM/kernel with one set of partition sizes and then flashes another MTD kernel with different partition sizes.

Wow, that does not sound cool. Maybe all the DEVs can agree on size standard for that.

Originally Posted by theduce102

Is there anything that needs to be done to make a theme work on MTD/YAFFS2?

And what determines the partition sizes? Kernel, ROM, or other?

Assuming the recovery kernel has the drivers loaded and can mount the mtd partition flashing filesystem changes and overwrites should be the same, as I understand theming pushes work.

Other. Neither the ROM or kernel would set the initial size. The partition map would. It's not clear to me if the values (for size, location, and order) are set in a config file or script during conversion from BML to MTD.

The best visual tool I could use as an analogy would be gparted in linux or disk management (microsoft management console snapin) in windoze. Once you set partitions with said tools of various sizes, start points, end point, format types (ext, fat, ntfs, etc), you can load any number of OS's on each respectively (or ROM's in our case) assuming they are compatible with the filesystem types and have a common unifying bootloader that understands them all (that can read each fs and call the respective bootloader). Sorry for the poor anaology but trying to put it all in more familiar terms.

Sent via Decadent Epic 4G CM7

Originally Posted by kennyglass123

Wow, that does not sound cool. Maybe all the DEVs can agree on size standard for that.

In testing with my ROM, I modified the updater script to check the /system and /data partition sizes and if they don't match up, flash the kernel and reboots before flashing the ROM.

A standard partition size would be easiest, but a checking partition sizes would also work.

---------- Post added at 02:51 PM ---------- Previous post was at 02:44 PM ----------

Originally Posted by codest3r

Other. Neither the ROM or kernel would set the initial size. The partition map would. It's not clear to me if the values (for size, location, and order) are set in a config file or script during conversion from BML to MTD

I don't think that's true. I'm pretty sure the partition map is defined in the kernel...period. So if you write data to your partitions to the nand and then load a kernel with a different partition map, the device will not boot because it won't be able to read the partitions.

I'm not 100% sure about this...only 98%, so if someone wants to correct me, please do.

Originally Posted by toadlife

I don't think that's true. I'm pretty sure the partition map is defined in the kernel...period. So if you write data to your partitions to the nand and then load a kernel with a different partition map, the device will not boot because it won't be able to read the partitions.

You do need the proper drivers in the kernel to interact with the OneNAND, it's partitions, and data formats (e.g. the storage memory or ROM in this case). However, the kernel itself doesn't define the partition map. Without the proper kernel (and associated drivers) we can't mount the filesystems in storage memory, that's for sure!

With BML the partitions are sized and created from the Partition Information Table during flash (e.g. ODIN, Samsung Upgrade Tool, Heimdall). More information on PIT specifics can be found (with good links too) in a post from the SGS i9000 forum: [GUIDE] [INFO] The reality of PIT files

Notice in his post the PIT is not part of the kernel - it has it's own parition. Which is likely why you don't have to specify the PIT file when flashing BML ROM's on our Epic because it just uses the PIT on the device! Pretty genius idea to keep it stored here in it's own space.

START
PBL (256KB: Primary Boot Loader: boot.bin)
PIT (*256KB: .pit )
EFS (5.9MB: efs.rfs )
SBL (1.25MB: Secondary Boot Loader: Sbl.bin)
SBL2 (1.25MB: Backup Secondary Boot Loader: Sbl.bin)
PARAM (*640KB: param.lfs)
KERNEL (7.5MB: Primary Kernel: zImage)
RECOVERY (7.5MB: Backup Kernel: zImage)
FACTORYFS (276.3MB: factoryfs.rfs)
DBDATAFS (126.7MB, 117.2MB, 107.2MB (depends on pit file): dbdata.rfs)
CACHE (30.1MB: cache.rfs)
MODEM (12MB: modem.bin)
END
*=Assumed


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.

Originally Posted by codest3r

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.

The reason you couldn't find it is because it's defined by the kernel. Specifically, the partition layout is defined in the file Kernel/drivers/mtd/onenand/samsung_epic.h

See: https://github.com/toadlife/CleanGB-...samsung_epic.h

Originally Posted by toadlife

The reason you couldn't find it is because it's defined by the kernel. Specifically, the partition layout is defined in the file Kernel/drivers/mtd/onenand/samsung_epic.h

See: https://github.com/toadlife/CleanGB-...samsung_epic.h

Ahhh... ha. Thanks for that! I'm surprised to see that there.

Leads me to more questions!

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?

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?

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?

Debunk my guesses. Thanks for the learning opportunity. Please excuse the ignorance and dumb questions - I'm trying to figure out how this works and missed the instruction manual.