- Downloads and instructions for the Odin/Heimdall recovery tools and images to restore your Epic to stock. You will need this to restore the BML partition layout if you want to return from MTD.
- 100/200/400/800/1000mhz with ondemand cpufreq governeor.
- cfq elevator
Offset Size Name Contents
=============================
0x00000000 262144 bml1 boot.bin
0x00040000 262144 bml2 ries.pit
0x00080000 6553600 stl3 # efs.rfs (unused, radio NV on GSM models)
0x00a80000 1310720 bml4 Sbl.bin
0x00bc0000 1310720 bml5 # Sbl.bin (backup of bml4, unused?)
0x00d00000 1310720 stl6 param.lfs
0x01200000 7864320 bml7 zImage
0x01980000 7864320 bml8 recovery.bin
0x00040000 262144 bml2 ries.pit
0x00080000 6553600 stl3 # efs.rfs (unused, radio NV on GSM models)
0x00a80000 1310720 bml4 Sbl.bin
0x00bc0000 1310720 bml5 # Sbl.bin (backup of bml4, unused?)
0x00d00000 1310720 stl6 param.lfs
0x01200000 7864320 bml7 zImage
0x01980000 7864320 bml8 recovery.bin
0x02100000 272629760 stl9 factoryfs.rfs
0x12d80000 524812288 stl10 datafs.rfs
0x32f80000 176685056 stl11 cache.rfs
0x3de80000 13107200 bml12 # modem.bin (unused?)
0x3eb00000 22020096 hidden partition "reservoir", used as spare blocks by BML to map in place of bad blocks in bml partitions
<mkasick> MTD kernels map "boot" (bml7), "recovery" (bml8), "system" (stl9), "userdata" (stl10), "cache" (stl11), and the reservoir
<mkasick> although we change the size of userdata and cache relative to each other
<mkasick> since they're adjacent, that's easy to do
<mkasick> system/userdata/cache and "blown away" by making yaffs volumes, boot/recovery remain "BML-encoded" using the bml_over_mtd tool to retain compatibility with SBL, all the other partitions are unmapped since we don't use them
Samsung's Proprietary Boot Loader (The Ugly Mess)
- <mkasick> SGS uses a two-stage bootloader, the Primitive Bootloader (PBL) and Secondary Bootloader (SBL). I believe they're built from the same source tree, and as far as I know, they're completely custom. PBL is much smaller, only containing the necessary code to read the larger SBL. SBL, however, is pretty hefty, for example containing all the code for Samsung's proprietary storage stack. I assume that, like Linux, SBL is compiled from modules with board specific configurations. So there's minor differences between an SBL build for the Epic, SGS, and other devices. Particularly notable is the fact that the NS and NS4G also use SBL as their bootloader, but those devices support fastboot and raw/MTD kernels. A lot of the crap we have to do for CM7 is basically working around the fact that our bootloader supports neither fastboot, nor the Android boot.img format. I don't think you can just flash the NS SBL onto our device and expect it to work because it has a different board specific configuration. Since we only have the compiled forms of both, trying to port over the "modules" is "extremely difficult". Fear of bricking is high. Download mode, which is the target-side of Odin/Heimdall, is implemented in SBL, so if you flash a bad SBL you're bricked without soldering and jtag fun
- <mkasick> also, there has been revisions to our bootloader, but they're not mandatory. For example, my Epic originally shipped with DG27 and has been OTA updated through EI22, and still runs the original 7/22 SBL .
<warren> mkasick, the other Galaxy S (like Vibrant) similarly has the proprietary PBL and SBL?Modem Delta Thoughts
<mkasick> for SGS devices, Samsung uses their proprietary storage stack for onenand, which is comprised of a few layers: BML, STL, and RFS
<mkasick> the combination of BML and STL do bad block remapping and wear leveling, so what's exposed is also a standard block device that you can run rfs, ext4, or whatever on, much like if it were an MMC
<mkasick> and yes, all SGS and NS devices use Samsung's PBL and SBL
<warren> STL stands for what?
<mkasick> I _think_ sector translation layer
<mkasick> although I may have just assumed that
<warren> BML and STL are implemented in kernel right?
<mkasick> it's the layer that does wear leveling
<mkasick> BML does bad block mapping
<mkasick> which is a little unusual, they're often combined
<mkasick> warren, BML and STL are implemented as proprietary kernel modules fsr.ko and fsr_stl.ko, but yes
<warren> mkasick, proprietary usually means binary blobs
<mkasick> there's also a "tfsr" driver in the SGS kernel tree to read BML partitions
<mkasick> well, true
<mkasick> however we do have fsr source code, it leaked out in the Indulge source tree
<mkasick> but it's proprietary, doesn't have an open source license
<warren> so fsr.ko and fsr_stl.ko are binary blobs
<mkasick> see, the kernel tree that Samsung build stock kernels from includes both open source and proprietary code, linking the latter as modules, but the abstraction isn't perfect so they have to manually go in and remove their code before shipping the source tarball
<mkasick> occasionally they screw up and remove open source drivers, but in practice the same code can be acquired from a non-botched tree
<mkasick> other times they leak proprietary code, which is great for reverse engineering, but something I don't recommend we ship
<mkasick> it's not linked into the kernel image
<mkasick> they use "non-GPL" symbols and link as external modules only
<mkasick> but the actual source sits in their kernel development tree instead of a separate external module tree
<mkasick> in other words, the final product is the same but their internal development is disorganized which is why they have the occasional problems they do
<mkasick> the traditional samsung proprietary modules, aside from third-party shit like the 3D driver
<warren> question, epicmtd appeared on XDA only recently. How was CM7 epic using BML prior? just including those binary blob .ko's?
<mkasick> are fsr/fsr_stl (BML, STL), rfs/rfs_glue (RFS), j4fs (a more trivial file system, used for /mnt/.lfs to share data with bootlodaer), and param (interacts with /mnt/.lfs/param.blk, to pass variables back and forth with the bootloader)
<mkasick> at this point code has leaked for fsr/fsr_stl and param, and Samsung opensourced j4fs in the SGSII tree to make CM development easier
<mkasick> I don't think we have ever gotten RFS source code, but that doesn't matter much since the bootloader never reads RFS volumes and we can replcae it with ext4 in any situation that matters
<mkasick> and yes, CM7 ran on BML like any other ROM, including the proprietary storage modules in the initramfs
<mkasick> the FSR/STL code is actually pretty reasonable, to the extent I've looked through it
<mkasick> so honestly, the part that I'm most suspicious about is param.ko
<mkasick> arch/arm/mach-s5pv210/mach-victory.c's "victory_power_off" function calls sec_set_param_value to set the device's reboot mode, this is a function that should be defined in built-in code but it's not, being implemented in a proprietary module
<mkasick> so at the top of the file you'll see a stub declaration and symbol export: "void (*sec_set_param_value)(int idx, void *value);<mkasick> EXPORT_SYMBOL(sec_set_param_value);"<warren> mkasick, where is the tree with the leaked param.ko source?<mkasick> SCH-I500 (Mesmerize)'s 2.3.4 GB kernel sources<mkasick> SCH-I500_USCC_Opensource_Update3.zip<mkasick> anyways, that sec_set_param_value crap is bad becuase the kernel shouldn't statically depend on symbols that may not exist at runtime<warren> mkasick, so ... CM relies on param.ko blob?<noobnl> https://github.com/teamhacksung/samsung-kernel-aries/commit/8a8f91fe0c472dbd746e72c964fd8cfa92d2f363
<mkasick> actually no, it doesn't
<warren> what are you doing instead?
<noobnl> look like he did it
<mkasick> really the CM kernel should strip out calls to sec_{set,get}_param_value but as a stop gap I wrote an opensource stub param.ko to implement those functions
<mkasick> it doesn't actually do anything useful, but satisfies the kernel's requirement for them in such a way that the proprietary module isn't needed
<mkasick> which was a prerequisite for us to move away from samsung's storage stack to use MTD
<warren> mkasick, so CM now has an alternative to set the device's reboot mode?
<mkasick> noobnl, hah! =)
<mkasick> yeah sort of
<mkasick> ugh
<mkasick> so here's how it works
<mkasick> there's a partition, in BML terms it's /dev/block/stl6, located between the bootloader and kernel (although I guess that does't matter)
<mkasick> the purpose of that partition is to contain bootloader-specific, or shared Linux-bootloader data
<mkasick> basically, boot-up splash images and this file "param.blk"
<mkasick> param.blk is the persistent-state of param.ko essentially
<mkasick> in other words, the purpose of the param.ko module is to allow Linux to communicate information (really, variables) to the bootloader and back
<warren> by writing to that partition
<mkasick> there's three actually used in the Epic's kernel, switch_sel: controls things like the USB interface mode, debug_level: (no idea), reboot_mode: determines what the bootloader should boot on reboot--normal android (init.rc), recovery (recovery.rc or fota.rc), or battery charge (lpm.rc)
<mkasick> of those, reboot_mode is really the only one we care about since it has to be set in order to reboot into recovery
<mkasick> well, no
<mkasick> honestly, the only reason we care about reboot_mode is because when you three-finger boot an epic into recovery, SBL sets reboot_mode to REBOOT_MODE_ARM11_FOTA and it's Linux's responsibility to clear that, otherwise the phone will always boot into recovery on subsquent reboots/power cycles
<mkasick> that's what our three-finger fix is for
<warren> reboot_mode is what exactly?
<warren> confused, because mtd blows away all the bml's right?
<mkasick> reboot_mode is a variable shared between the bootloader and Linux, persisting in /mnt/.lfs/param.blk, /mnt/.lfs being a j4fs file system (it's only use), located on /dev/block/stl6
<mkasick> doesn't blow away all the bmls, but mtd doesn't make use of stl6
<mkasick> in "traditional Android", basically HTC and Nexus devices
<mkasick> there's two partitions dedicated to "the kenrel"
<mkasick> one is for the boot kernel, or boot.img, the other for the recovery kernel, recovery.img
<mkasick> now, the actual kernel for both of those is typically the same, but they have differing initramfs images
<mkasick> and in, "traditional Android" the actual "img" format is Android-specific, consisting of a header, a kernel zImage, and a gzip-compressed initramfs cpio archive
<noobnl> we did this in mtd also.. but as one boot.img..
<mkasick> right
<mkasick> So Samsung is weird
<mkasick> SBL didn't support Android boot.img format until the NS
<mkasick> on GSM Galaxy S devices, there's one kernel partition
<mkasick> actually there's two, but the second is empty and never used
<mkasick> that partition contains a headerless/raw zImage
<noobnl> no samsung bootloader for galaxy s is weird
<mkasick> which itself contains an embedded initramfs, that's added as part of the kernel compilation process
<mkasick> that initramfs actually supports both normal and recovery boots, "init.rc vs recovery.rc", the right one selected by a "bootmode" kernel commmand line argument that Samsung's modified init intereprets
<mkasick> now, the Epic and Fascinate are "further weird"
<mkasick> because on those devices, _both_ kernel partitions are used
<mkasick> bml7 contains the boot kernel, used for normal android boots; and bml8 contains the recovery kernel, used by three-finger boots to recovery
<mkasick> in stock ROM images, bml7 and bml8 are absolutely identical
<mkasick> so reboot_mode is the trick
<mkasick> in samsung land, there's a bunch of options: NONE, DOWNLOAD, CHARGING, RECOVERY, ARM11_FOTA, and ARM9_FOTA
<mkasick> when you're running Android and do a reboot, the kernel sets reboot_mode to the appropriate value at that point
<mkasick> then on reboot, SBL reads the reboot_mode value and starts executing the right mode (it's internal download mode for DOWNLOAD, lpm.rc for CHARGING, recovery.rc for RECOVERY, fota.rc for ARM11_FOTA, and crazy-modem-shit (modem delta flash?) for ARM9_FOTA
<noobnl> correct mkasick
<mkasick> also, if SBL sees vol-down/camera/power pressed during boot, it _sets_ reboot_mode to ARM11_FOTA and boots bml8/fota.rc (recovery), and if it sees "keypad 1" then boots download mode
<mkasick> so it's nifty right, on our device we actually can have _two_ recoveries, one part of bml7 and the other part of three-finger/bml8
<mkasick> in practice, well
<mkasick> MTD kernels can't do anything with /mnt/.lfs/param.blk since it has no drivers for the underlying file system/storage stack
<mkasick> so if you three-finger boot into recovery, reboot_mode is "permanently set" to ARM11_FOTA which means you always boot into recovery with no way to get out
<mkasick> the fix, which we and the fascinate use, is to have a BML-compatible bml8 kernel reset reboot_mode to NONE, set a flag somewhere else to boot recovery, that's checked by the MTD bml7 kernel
<mkasick> oh, and then reboot right away, so that the MTD recovery is loaded
<mkasick> basically it's hacks on hacks to get around param.blk entirely
<mkasick> yeah, sort of
<mkasick> two-stage boot is actually separate from all of this, sort of
<mkasick> you could have the kernel's embedded initramfs support both normal and recovery boots, and historically that's what we've done in BML kernels
<mkasick> the reason for two-stage boot is to make "Samsung's weird shit" fit into AOSP's (and CM's) build process
<mkasick> where the kernel is just a compiled blob in the device tree, and initramfs images are generated at compile time and attached in boot.img format
<mkasick> where's its related is that we take advantage of the fact that we have two-stage init to figure out which, normal or recovery boot, to do from another indicator than just the command-line bootmode
<mkasick> my _guess_, is that SBL was developed to support booting Linux in the form of Bada first
<mkasick> and I'd guess Bada uses an embedded initramfs zImage format like we do
<mkasick> it's part of standard Linux afterall
<mkasick> so when it came down to build Android devices, they just hacked on SBL _just enough_ to "support" Android in their existing Bada build/prototype/debug framework, and completely eschewed the Android-way of doing stuff
<mkasick> so the Nexus S SBL supports fastboot, boot.img format, all that great stuff
<mkasick> but the SGSII SBL, which post-dates it, doesn't
<mkasick> because it's not necessary right? they don't care, they do their thing their way, and they only did it for the NS because Google requires it
<warren> We apparently have the full EC05 modem binary, and a delta to EI22 modem, nobody figured out how to combine the two outside of the phone?
<mkasick> true
<mkasick> so it's certainly possible to do
<mkasick> i.e., I have DI18 and EB13 stock modems, and the DI18->EB13 modem upgrade delta
<mkasick> so it's a matter of taking the DI18 modem, the update delta, and mashing them together in a way that produces the EB13 modem
<mkasick> nobody's reverse engineered the delta image format to do that, and we don't have any example code, aside from what you might be able to disassemble form the modem firmware, so it'd be guesswork
