New info on filesystem, flashing, and the future

First, let me start off by thanking peeps for his help and guidance. He is the real brains here.


We have solved the problem of not being able to read the RFS filesystem, say /dev/bml5 where /system is mounted. If you dump /dev/stl5, you get a FAT16 filesystem stripped of RFS completely. It can be mounted under linux and read with no problems. RFS is no longer a big issue, it's still an issue, but not a huge one.

The next item up for bids is custom kernels. As peeps allready posted, anything can be changed and built in. I flashed a kernel that has the following changes to default.prop


This basically removes all security from the phone, and enables adb in places not normally accessible. This is dangerous and shouldn't be used on phones that are in the wild, as any program or script could do anything with you phone, against your will.


The last, and possibly most harmful news is that from what I can tell from hex editing the SBL (secondary boot loader) is that odin DOES NOT come into contact with the linux kernel at all. The serial data connection (google gadget 1.0) is built into the SBL, and listens for odin.

This in itself wouldn't be bad, except the SBL (in my opinion) is the ONLY way to remove the "LockTight" on the Samsung ONENAND. This is why we can write to /dev/bml* and not get anywhere. Once LockTight is set, there can be NO direct writing to the nand, period, until it is unlocked by proprietary Samsung code in the SBL. Thats why there is no 'recovery' or 'fastboot' or any of the normal Android emergency reflashing modes.

My theory, is that Sprint is forced to not release OTA updates because the Moment CANT be written to while the kernel is running, because there is no program that can remove the 'LockTight" setting other than the SBL. In the ONENAND documents, you see that the nand has to be reset with the LockTight setting removed to be able to be written to, this would mean taking the entire filesystem offline during an OTA update which just isn't feasible. I honestly believe that there is no way to write to the onenand without going through the SBL.

This doesn't doom us, we could disassemble the SBL and find ways to unlock the nand and leave it that way, but messing with the SBL is bad news, as it contains the only way to restore the phone. Without source it is basically too risky to edit, and we will never have its source.

But even this doesn't doom the whole thing either! We can still (in theory) make our own yaffs2 images and have odin burn them to the phone, but this means we need to know what odin, and more specifically the SBL are doing with these files. More investigation into the SBL is needed.

Well yes, but I don't think they could push a complete android update (unless they don't update the kernel maybe?). I don't think /system is locked tight (need to try and dd overwrite its stl/bml), but the others certainly are.

Hopefully I'm completely wrong but I don't think so.

Yeah, if all that you're concerned about is your inability to write to the /boot partition ... that's no different than many other phones.

Also they generated ota-keys and such for the release... The notes are in the source code.

Here's how an OTA update would work:

1. download update and check if it's valid against public keys.
2.  reboot with download flag set.
3.  now it boots from the proprietary rom and updates the system with the OTA update

We already have all the tools necessary and most of the information to load our own custom ROM.  What remains:

1.  Do we have match the stock MD5? or will ODIN load anything we give it?
2.  We need to figure out how to make a valid RFS image out of a FAT32 (/dev/stl5 are FAT32 with some extra sauce packaged in to make it 'RFS' ... MS should be all over this shortly unless Samsung made a deal) image.
  OR
3.  Will the boot-loader allow us to just flash anything we give it to the respective partitions... if so, all we have to do is package a release as YAFFS2 ... and bob's your uncle.


"could they do an OTA update that gets downloaded/stored somewhere?"

/cache/recovery maybe ... seems like a logical place, as that's where you download your .apk files to... and there's already a directory named /cache/recovery.


Brain idea regarding FAT32 vs. RFS ... are the BML5,6,7 images RFS ... and STL5,6,7 FAT32? If so we can do bindiffs and try and figure out what the headers look like.

We should make a tar with YAFFS2 images in place of the RFS images.  We can either turn YAFFS support on in the kernel or use the modules/kernel they have already supplied and change the .rc files.  It looks like they had the MTD drivers working first, then switched to the YAFFS + XSR, then RFS + XSR.  We should first try to get the YAFFS + XSR working, then later maybe try and compile MTD-OneNAND support into the kernel if we want better access/documentation for the NAND chips.

There's no reason that won't work ... assuming that the boot-loader is just doing a straight copy over to the partitions.  There might be meta-data or something in the .rfs partitions though, so who knows.

MS owns patents on the FAT32 system, and just recently went after another device manufacturer I believe.


The RFS file is just a FAT32 image prepended with a custom header that includes the journaling data.  I can almost guarantee that.  I'd even wager that FAT32 -> RFS is seemless ... where-as RFS -> FAT32 breaks because the journaling data breaks from the regular formating.

Yeah that's the plan...

Going to try and load just the /cache first as a YAFFS2 partition tonight... to make sure the YAFFS2 kernel module works.  Edit the .rc files and comment out the RFS stuff for just /cache and uncomment the YAFFS lines... also insmod the yaffs2.ko

If that works we can probably start making our first distribution ... and expect it to work.