Database Develop

Misc partition: Why does it die? How do I fix it?

This is a long thread because I'm trying to provide the maximum detail possible in the hopes of luring some experts to assist. I am a developer with 30+ years experience, though with little *nix experience, since I hitched my wagon to WinTel when people stopped hiring assembly programmers and the term "GUI" began appearing in help wanted ads.
Yesterday, based upon my experience with one phone that I successfully upgraded to CM6-RC1 and another one that failed, I posted a new thread in the G1 General section, which was probably the wrong place for it. Both phones are US TMo G1's purchased within a few days of each other, around December 2009.
During the subsequent 12 hours I read everything I could find about the dreaded "E: Can't find MISC: / (No space left on device)" problem, which I eventually determined was preventing me from proceeding further.
I found many, many examples of people on all types of hardware who were (and many still are) stuck with a hosed-up misc with no idea how to proceed. This was somewhat alarming to me.
I found a few people who were apparently able to fix it by simply doing a flash_image of a misc.img copied from elsewhere. I found a few who seemed to have fixed it with dd. I found others who went through various combinations of installing other things until the problem mysteriously vanished. I found great info about what the misc partition is and how it's used.
What I did not find is:
(a) any clear explanation of how it gets hosed in the first place,
(b) any clear explanation of how to troubleshoot it,
and most importantly (c) any clear explanation of ways to fix it.
This thread is a request for an expert to step in and fill those gaps. Maybe if we can get some "misc lore" in a single place, other people who encounter the problem won't be left hanging.
So first the back story:
Two days ago I decided to install CM6-RC1 on my own G1. It went very smoothly. I was already on Cupcake, so I formatted the card, downgraded back to RC29, I installed Cupcake, formatted again from the phone, used flashrec to install RA 1.7 (which is amazing, by the way; I may be a n00b to phone-guts but that is already apparent), verified the radio version, installed DangerSPL, installed CM6-RC1, and installed the Google Apps. Flawless process.
Loved it. CM6 is great. So the next morning I had my wife leave her phone at home with me. I had seen a thread which led me to believe that the card didn't necessarily have to be formatted twice. I was under the impression I could format it once and drop all the files out there -- only Cupcake needed to be named update.zip for the process outlined above.
So I connected her phone to my laptop, reformatted to FAT32 over USB from Win7, copied all 211 MB of files over, disconnected and went into flashboot. The RC29 downgrade worked fine. I restarted and logged in just to be sure RC29 was on there. I powered off and restarted in recovery mode -- and the misc problem was already there.
In the stock /!\ recovery screen, ALT+L showed the misc error. I couldn't remember if I had seen that previously (having only done this once before), so I hit ALT+S and hoped for the best. The progress bar went about halfway then bombed on an assert in line 4. And that's as far as I got updating my wife's phone: in theory my story could stop here, but being a lifelong geek-type, I decided to forge ahead. I didn't yet know the importance of misc or even recognize it as my main problem, so bear with me.
I rebooted and rooted via telnet and used flashrec to install RA, and tried installing Cupcake that way. I get a different error from RA: No signature, verification failed. I thought I might have a bad file, somehow, despite having used the same update.zip that went into my G1 just fine, so I downloaded it again from megaupload. Then I downloaded the other one named signed-kila-ota. Then I did a file compare and confirmed they're identical. That won't load through RA. Not sure what's up with that.
But after thinking about it and doing more reading, I concluded I probably didn't need Cupcake for CM6-RC1, I just needed the correct radio image to support DangerSPL. So I grabbed the G1 2.22.23 radio image and tried installing that through RA. It extracts and installs ok, then dumps the Can't read Misc error, then tells me to reboot to complete. So I reboot -- and it goes back into the running OS, of course. And then the light goes on, since I did clearly remember on my own G1 it went back into RA, not into Android.
More digging uncovers the radio/SPL thread that explains how misc is used to control reboots, and I finally clearly realize that misc is my problem. (Actually I still don't know why Cupcake won't load from RA, but I still suspect if I can just load the right radio image, it shouldn't matter.)
During the following six hours I have tried a huge variety of things to fix misc, primarily working through an adb connection.
First I tried making a nandroid backup from my working G1. Took me awhile to figure out I had to do it from the command line to force it to backup misc, then I wasted time trying to get the command line to restore that backup, then I finally made another backup on the non-working G1 and copied the "good" misc over -- and still couldn't get it to restore (kept telling me something about being the current version, which I interpreted to mean it wasn't restoring because it thought the backup already matched the live filesystem).
Again, not knowing much about *nix, at this point I was convinced misc was simply dead and gone. I know what a disk partition is, but I didn't see misc (or the others like recovery) in parted, so I don't think I even understand what it means to say misc is a partition. But I didn't see it anywhere, so I thought it had been erased or overwritten or something along those lines.
Then I ran across a thread in which someone suggested doing a "cat /proc/mtd" which yielded the following:
Code:
dev: size erasesize name
mtd0: 00040000 00020000 "misc"
mtd1: 00500000 00020000 "recovery"
mtd2: 00280000 00020000 "boot"
mtd3: 04380000 00020000 "system"
mtd4: 04380000 00020000 "cache"
mtd5: 04ac0000 00020000 "userdata"
I don't know what it means, but at least I see the system still knows something about misc.
Someone else asked for "dump_image misc /dev/zero" for diagnostic purposes, which yields:
Code:
mtd: ECC errors (0 soft, 1 hard) at 0x00000000
mtd: ECC errors (0 soft, 1 hard) at 0x00020000
Someone suggested "cat /dev/zero > /dev/mtd/mtd0" which results in the error message "cat: write error: No space left on device".
I tried copying misc.img out of the backup folder to the sdcard root and doing "flash_image misc /sdcard/misc.img" and was rewarded with the following lines which I can't interpret, although they're clearly related to the output shown above (I assume flash_image is probably a script or something, which is just doing those same steps internally?):
Code:
mtd: ECC errors (0 soft, 1 hard) at 0x00000000
mtd: ECC errors (0 soft, 1 hard) at 0x00020000
mtd: erase failure at 0x00000000 (I/O error)
mtd: erase failure at 0x00000000 (I/O error)
mtd: skipping write block at 0x00000000
error writing misc: No space left on device
I ran across another thread which suggested the command "dd if=/sdcard/misc.img of=/dev/block/mtd0"... that produced this initially encouraging-looking output, though I don't know what it means and it didn't fix misc:
Code:
512+0 records in
512+0 records out
I also saw a few steps and suggestions relating to fastboot. I didn't try any of these since the only instructions I could find for setting up fastboot (in that stickied noob thread) requires a version 2 radio image, which I can't install because misc is fried.
So, in short, searching xda and the Internet in general hasn't helped much, except perhaps to better prepare me to follow somebody else's instructions . In reality I have gone through several different sets of instructions multiple times and tried a variety of other things, but it always comes back to not being able to complete a radio image installation because of that problem with misc.
I'm willing to try just about anything... and I know there are quite a few others out there with a misc problem who can't seem to make any progress or get any input, so hopefully my exhaustive description of how I got here and what I've tried already will be useful to one of the local experts.

I know that ECC refers to the error correction checksum used to detect memory errors... but I find it awfully suspicious that the two supposed ECC errors fall on the very first and last slots on the misc range -- particularly since everybody else with this problem who posts the results of attempts to troubleshoot it or fix it reports exactly the same thing.
In other words, I assume the error message is wrong. This is pretty much the only reason I don't just conclude that the memory is actually hosed and go shopping for a new phone.
Oh, and... bump.

You are certainly telling the truth about it being quite long. That fact does, unfortunately, make it somewhat difficult to read.
I assume that you've seen a few of ezterry's and/or my own posts about the partitions, which is probably where you saw the info on the misc partition.
In any case, the misc partition isn't a "filesystem" partition as you are familiar with. It is actually just a simple data structure. In fact, only the system, cache, and userdata partitions are actually filesystem partitions, and the cache partition is only a filesystem partition part of the time -- during radio and spl updates, it also is used as a simple data structure with a header field and a payload field. That, along with the misc partition, instructs the SPL to perform a radio or spl update.
Now there is a possibility that it may be possible to salvage the device without a working misc partition. Specifically, the requirement is that you get yourself a high-engineering SPL (one with the ability to fastboot a radio image -- note: it is FAST boot, not flashboot).
One important thing to note that might make things easier is that an error "finding" the misc partition *might not imply a failed misc partition*. It could possibly be a failed CACHE partition. Have you tried FORMATTING your cache partition?
In any case, you are no doubt really wondering about my statement that you might be able to update the SPL without the use of a misc partition.... Read THIS thread and you will see how the partition tables are defined and how they can be overridden. This suggests a way that you can actually DEFINE the SPL partition to the linux kernel, which in turn, should allow you to flash_image an SPL update. What you need to do is determine the starting offset and length of the SPL partition, and define it along with the rest of the partitions on the kernel command line. Once this is done, you should be able to fastboot flash a radio update to the device.
Note: Having just done an RC29 NBH file, there is PRECISELY ONE high-engineering SPL that you can install to the device safely.... 1.33.2003 (ending with a THREE -- very important, a 5 is a brick when combined with an rc29's radio).
Also note: I don't take any responsibility if you fry it completely trying this idiotic procedure without a jtag standing by. It is quite risky. I suggest it because it may be your best chance of getting through this.
Note: fastboot does NOT require a 2.x radio image. Fastboot requires an engineering SPL, which for the same reason, you can't install.
Now as for the location of the read/write errors.... you think that it is suspicious that they occur at the first and last slot of the memory range...
Well this is not unexpected since there are only two slots. Each of 128 kB. The first at 0 offset wrt the start, the second at 20000 offset wrt the start. The ECC error itself says that each of the two blocks has failed whatever operation it was trying to perform.
I suggest that your first step might be to try again writing the RC29 NBH file.

Thank you for the explanations and all the details.
I have actually reloaded RC29 quite a few times. I followed the directions from scratch a couple times in case I had gotten something wrong (of course, this was easy to do since I get stuck pretty early in the process).
I'll try formatting CACHE and I'll take a look at using the SPL you reference and report back later.
I really appreciate the assistance.

Ah, just realized that when you do "Wipe cache" from RA recovery, formatting cache is the second step. Since that is immediately followed by another "Can't read MISC" error message, I guess formatting doesn't fix my misc issue.
In this paragraph:
In any case, you are no doubt really wondering about my statement that you might be able to update the SPL without the use of a misc partition.... Read THIS thread and you will see how the partition tables are defined and how they can be overridden.
Click to expand...
Click to collapse
Your "THIS" didn't link to anything. I'll go search for what you're referring to, since this would appear to be my only remaining solution. No JTAG handy, but if someone of your experience thinks this is probably my last-ditch option, I don't have much to lose anyway, right? I'll take it slowly.
Edit: I think this is it? forum.xda-developers.com/showthread.php?t=704560 Pretty clever... crazy and dangerous, sure, but what the hell, it's just a phone, lol...
Again, thanks for taking the time to help out.

MV10 said:
Ah, just realized that when you do "Wipe cache" from RA recovery, formatting cache is the second step. Since that is immediately followed by another "Can't read MISC" error message, I guess formatting doesn't fix my misc issue.
In this paragraph:
Your "THIS" didn't link to anything. I'll go search for what you're referring to, since this would appear to be my only remaining solution. No JTAG handy, but if someone of your experience thinks this is probably my last-ditch option, I don't have much to lose anyway, right? I'll take it slowly.
Edit: I think this is it? forum.xda-developers.com/showthread.php?t=704560 Pretty clever... crazy and dangerous, sure, but what the hell, it's just a phone, lol...
Again, thanks for taking the time to help out.
Click to expand...
Click to collapse
Before re-writing partitions find a recovery with 'erase_image' (I hear tell clockwork has it) install and try:
erase_image misc
then
flash_image misc <misc.img>
where misc.img is an old nandroid backup from a phone of the same region as your own (least its preferable its the same region your CID is in the structure)
It may correct the issue... if not we can try to flash an engineering SPL via flash_image..
I feel this is very safe in theory (as we don't have to worry about boot mode 3.. thus if a valid SPL is flashed you won't completely brick).. However we have no safeguards at this point in time so be careful that you really understand what is going on.. else you will write garbage to the SPL, and there is no helping that w/o JTAG.
(btw.. the SPL .. even the full engineering ones like 1.33.2003 and 1.33.2005 wont actually let you erase misc.. but will let you flash it)

Thank you, I'll try it later today.
Not that it's relevant to getting me fixed, probably, but no idea how/why this problem crops up? Or is it more a case of an error that can have multiple causes? I found it interesting that so many people were reporting it across the various Android forums, and there seemed to be no attempt to explain it. That kind of thing always makes me curious, particularly in an environment like this -- a room full of curious "dig in and figure it out" personalities...

If it ever happened to me, I would certainly try to figure it out, however this is really difficult since it has never happened to me. I don't think that it is anywhere near as common as you think.
What I believe about the situation at the moment is that it is *probably* a failure somewhere else along the line that simply has this SIDE EFFECT.
ezterry: Do you remember which memory address ranges are written by an nbh file? I recall that the nbh file has divisions for the different partitions, so I suspect that it may not write *everything*. Maybe misc and/or cache are not written?
Note: I have seen plenty of instances of the cache partition getting borked and having weird side-effect. The problem with the cache partition and why IT gets into weird states is that it is a dual-purpose partition -- sometimes a yaffs2 filesystem, sometimes a simple data structure, so if it gets into the data structure mode and something tries to use it as a filesystem, you end up with some interesting side-effects.

lbcoder said:
ezterry: Do you remember which memory address ranges are written by an nbh file? I recall that the nbh file has divisions for the different partitions, so I suspect that it may not write *everything*. Maybe misc and/or cache are not written?
Click to expand...
Click to collapse
The nbh is just a custom archive the header has 3 arrays of 32bit indicating the following for each partition included
> Partition type (this determines the partition via some mapping to flash radio,hboot,misc,cache,recovery,boot,system,splash1,diag)
> Partition offset from start of the nbh file (signature removed if included)
> size of image
The diagnostic nbh only has the fake 'diag' image.. however most others in the wild seem to have radio, hboot, splash1, recovery, system, cache, userdata...
I don't think I've seen one with misc.
Certainly none of my current collection have it. I Wonder if they allow it?

Clockwork's "erase_image misc" returns an error:
mtd: erase failure at 0x00000000
I also tried wiping and formatting the cache again, on the off chance that maybe clockwork did something differently. Nothing new to report there.
As for this kernel partition approach, do I correctly understand that I would be telling the kernel to create a new partition name mapped to a range which precedes misc where the SPL is located? I assume I can derive the size from an img of the stock SPL of the same version. Any tips on how I can figure out where it starts? (Apologies if it's in that thread Ibcoder referenced, I haven't finished reading it yet.)
Or am I thinking about this completely wrong?

Search for my post with the kernel command line with hboot replacing userdata.. it deliberately is not step by step but has the info needed.

On a somewhat peripherally-related note, I see in this post in the De-bricking thread:
forum.xda-developers.com/showpost.php?p=7072492&postcount=195
Ibcoder writes: 3) This person goes to boot to the recovery by issuing a "reboot recovery", which sets the command field of the MISC partition to boot-recovery and reboots.
Earlier I had thought about asking whether "reboot recovery" writes to MISC, since I issued that command from the RA console yesterday and to my surprise it worked. I figured I must have misunderstood something and maybe reboot recovery used some mechanism other than writing to MISC, but now I've run across the comment above.
Wouldn't that boot mode flag be the same thing recovery should use to finish installing a radio image?
ezterry, is this the post you're referring to?
forum.xda-developers.com/showpost.php?p=7064255&postcount=187

MV10 said:
On a somewhat peripherally-related note, I see in this post in the De-bricking thread:
forum.xda-developers.com/showpost.php?p=7072492&postcount=195
Ibcoder writes: 3) This person goes to boot to the recovery by issuing a "reboot recovery", which sets the command field of the MISC partition to boot-recovery and reboots.
Earlier I had thought about asking whether "reboot recovery" writes to MISC, since I issued that command from the RA console yesterday and to my surprise it worked. I figured I must have misunderstood something and maybe reboot recovery used some mechanism other than writing to MISC, but now I've run across the comment above.
Wouldn't that boot mode flag be the same thing recovery should use to finish installing a radio image?
ezterry, is this the post you're referring to?
forum.xda-developers.com/showpost.php?p=7064255&postcount=187
Click to expand...
Click to collapse
Suggesting, of course, that the misc partition itself is actually quite fine, but whatever subsystems responsible for screwing up when it screws up for you are in some other way broken.... which is not inconsistent with the theories I have presented above. Specifically, I am still quite concerned about your cache partition being somehow defective since it is known for having weird side-effects.
What you may possibly be able to do is hack the reboot command into "reboot flash-hboot"... be ***absolutely certain*** that you get your cache partition set up correctly and fully verified before you do this though, otherwise you WILL need jtag to fix it.

Later I wondered whether reboot had options to specify the flashing modes. I take it from your response that it does not. Given my meager relevant knowledge, significant hand-holding would probably be required to pull that one off!

Another oddity I have noticed: my own G1 shows a device ID of HT91CGZ02056 (through something like "adb devices" for example)... but my wife's G1 (with the MISC issue, or whatever it is) just returns a string of zeros: 000000000000. First noticed that in the nandroid backup directory name.
Not sure if that tells anyone anything useful or interesting, but it sure seems weird.

MV10 said:
Another oddity I have noticed: my own G1 shows a device ID of HT91CGZ02056 (through something like "adb devices" for example)... but my wife's G1 (with the MISC issue, or whatever it is) just returns a string of zeros: 000000000000. First noticed that in the nandroid backup directory name.
Not sure if that tells anyone anything useful or interesting, but it sure seems weird.
Click to expand...
Click to collapse
It could mean that there is a serious defect.... or it could be the same glitch that is causing you problems with misc. Remember that the device ID is stored within the same chip as the misc partition, just at a non-writeable address.

Ha, interesting, I didn't know there was any sort of relationship there. Very interesting.
Well, at this point my wife is freaking out without a phone so I'm just buying her a Galaxy S (yeah I know, Samsung... but frickin' T-Mo doesn't have anything else particularly compelling).
I'm sort of interested in what's wrong with her G1 and I have an unhealthy urge to keep fiddling with it, but honestly I can't justify spending much more time on it right now, too many other things going on in my non-phone-based life.
That means I have a thoroughly unexciting RC29 G1. I assume OTA updates aren't likely to work either (assuming they're still sent out). If either you or ezterry would have any interest in this device (maybe some questions about what went wrong since you haven't seen a MISC failure?), shoot me a PM, I'll see about shipping it off to one of you.
Regardless, I can't express how much I appreciate both of your attempts to help a complete stranger, and I look forward to reading about all the other weird and interesting stuff you guys dig up in the future...

[GUIDE] Changing your Bluetooth/Wi-Fi MAC Address

Hi guys
Well, I had an Atrix for a few days, but had some issues with AT&T and had to return it and deal with some customer service issues before I can re-purchase the device. I didn't let that slow me down though
While I had it, I made a few dumps of the NAND, and have been working on disassembling things. Thanks to the help from a number of great people on IRC (#xda-devs irc.freenode.net) I have been able to successfully change the Bluetooth and Wi-Fi MAC addresses, and discovered a way to write to the flash, bypassing the bootloader security.
The full writeup can be found at pocketnow.com
I will be posting more info about the bootloader bypass as soon as I get it 100% working, right now we are able to write data directly to the NAND, bypassing bootloader security, and also provide a false signature, allowing the device to boot. However there are some remaining issues (a custom kernel that was flashed to the device failed to boot properly) - stay tuned

You the man, thanks for the efforts !

Sweeeet!
Wonderful work!

Excellent, can't wait to see the end result. Hopefully custom kernels and ROMs will be coming soon.

Devs you guys are amazing! Thank you for the hard work that is put into all this! I know the challange is fun for you all, but it really helps us non dev ppl out a lot!
Sent from my MB860 using XDA App

nicely done Da-G.... great work as always glad to see you again and i hope to continue using your work as i did back in old winmo cooking !!!
quick question, is there really a reason why to change the bluetooth/wifi MAC drivers??? are there any benefits or basically just the same exact reasons when you do it on pc's

Main reason to change MAC address is to be able to join Wi-Fi networks that have whitelisting.
You could also use it to simplify device administration on your network.
Beyond that I can also imagine a few black-hat reasons to do it
Atrix is one of the few smartphones that can pull it off easily though, others I am aware of are the LG Optimus One and the SGS series (although it's not so easy on SGS)
There are plenty of other interesting datas in /pds, it is the device provisioning partition (NVRAM) and is equivalent to /efs on the i9000/Captivate (which is the last device I used, so easy for me to compare with)
Careful messing with it though, on the Captivate changing the wrong bit would kill your cellular radio until you restored an EFS backup, I suspect the same danger is here with the Atrix too! And we don't have a quick way to restore a PDS backup yet like with odin on SGS (although I am hot on the heels of a method to do so)

Omfg I'm excited! If this device gets real ROMs an even custom kernels, its going to be an even more amazing device
Sent from my MB860 using XDA Premium App

i'm exited about the bootloader bypass, i thought the firmware would do a complete checksum of it, so if it's partial then we should be able to find out exactly what gets checked.
i'm curious to see if you have been able to find something regarding sim unlock, just like the sgs was holding the lock very easily changeable with a simple hex editor. i bought the code already but maybe other people will get lucky

I've asked for a backup of /pds prior to and after locking over in the general forum, hopefully a few people can send those my way. I suspect a good hard look at that will reveal the location and provide an easy unlock method (I think I located it already, but as /pds is not restored via flashing the leaked SBF, i'm loathe to have someone else try it in fear of brickage)
I'll hammer it out once I get my device back in hand, whenever AT&T decides to allow me to purcahse

Da_G said:
I've asked for a backup of /pds prior and after locking over in the general forum, hopefully a few people can send those my way. I suspect a good hard look at that will reveal the location and provide an easy unlock method (I think I located it already, but as /pds is not restored via flashing the leaked SBF, i'm loathe to have someone else try it in fear of brickage)
I'll hammer it out once I get my device back in hand, whenever AT&T decides to allow me to purcahse
Click to expand...
Click to collapse
i will do it, but i am getting a permission denied.
Code:
C:\Users\fjleon\Desktop\android-sdk-windows\platform-tools>adb shell tar zcvpf /
sdcard-ext/pds-backup.tar.gz /pds/
tar: can't open '/sdcard-ext/pds-backup.tar.gz': Permission denied
i tried adb shell su and accepted super user on the phone, but i still cannot do it

wow bypass= custom roms...... this would be ingenious hope u get it working....
how does rsd lite 5 flashing work??? it seems to create an image and then re sign it.... would backtracking and try to use the same method work?

@franciscojavierleon:
Make sure you don't have usb internal/sd storage mounted when you issue the command, or the sd card will be unaccessible from device
@ahjdmarchi:
I didn't study the program too much yet. I'll look to that if the current method i'm working on proves to be a failure

Da_G said:
@franciscojavierleon:
Make sure you don't have usb internal/sd storage mounted when you issue the command, or the sd card will be unaccessible from device
@ahjdmarchi:
I didn't study the program too much yet. I'll look to that if the current method i'm working on proves to be a failure
Click to expand...
Click to collapse
heres a tattoo that i have on my chest
"failure is not an option" good luck brudda hope all turns well

Da_G said:
@franciscojavierleon:
Make sure you don't have usb internal/sd storage mounted when you issue the command, or the sd card will be unaccessible from device
Click to expand...
Click to collapse
i unmounted it and tried again and still get the same error. i killed root explorer first since i had it open and no dice

@franciscojavierleon:
Try this instead.
Code:
adb shell tar zcvpf /data/local/tmp/pds-backup.tar.gz /pds/
adb pull /data/local/tmp/pds-backup.tar.gz
adb shell rm /data/local/tmp/pds-backup.tar.gz

RadioComm
You really need to take a look at RadioComm if you haven't yet.
The BT MAC address can be edited directly in the NVM on all Motorola devices.
On CDMA chipset devices it is located in seem 01bf record 0001 bytes 0006 and there is also a module and special set of TCI commands for managing this called HOB restore.
There are also flags set in the firmware for whether the HOB is verified during the flash cycle or not.
just an FYI!

@cellzealot:
Checked out RadioComm already, but none of the commands work for Atrix. Have you tried it? Perhaps you have a more updated version?

Edited. Nevermind just saw you needed it before unlock as well. I've got my PDS folder from my unlocked phone if you need it (not sure)

i should get my unlock between today and tomorrow, so with my locked pds backup i will do a diff to see if anything gets changed at all.

OMAP4430 boot.rom dump

My purpose is to locate the fastboot system, and I thought that I would start from, well, the start. Boot-up on the OMAP4430 tries many places, one is an on-chip 48kb ROM. I initially tried to read /dev/mem, but no matter what address I tried to read it would say Bad Address, so I had to make a kernel module, in which I dumped the boot ROM to a file... and it worked.
The reversion of the ROM on my bionic is 0x03 0x19
(Please read Ch 27(.4.2.1) of OMAP4430_ES2.x_PUBLIC_TRM_vY.zip )
I am more handy with ia32 assembly, not arm...
So where is fastboot? I can see a few other addresses, but if I try to map some of them, the device will reboot.. The TRM spoke of 0x08000000 for a fast boot XIP but a reboot occurs (I think) ... any ideas where to look next?

After a day of digging around, I was able to find that "fastboot"(0x08000000) address at 0x28C18 (0x28000 is the base address of the boot.rom) ... just helping out anyone else interested in looking into this. I somehow don't think that this is what I am looking for though... but atleast I do know that I am making some headway
Edit: Confirm that I am unable to read even one byte from 0x08000000 .. reboots
Edit2: Polling from the Control Register (0x4A0022C4) returned 0x00000AEF ... which means that
1) This is not a GP(General Purpose) OMAP4430
2) SYS_BOOT[5:0] is b101111 which tells us
a) to use Memory, not Peripheral boot devices
b) 1st boot device is MMC2(1)(perm) (eMMC/eSD = GPMC pins)
c) 2nd= USB-ULPI (external transceiver)
... Does the MMC mean it boots from the onboard 16gb? If so, then this might be easier to trace through than I thought...
Has anyone dumped the entire contents of that memory? or just the known partitions?
Edit3: Reading the TRM more (pg 5240) tells me that SDMMC2 only Raw mode is supported, no file system (FAT12/FAT16/FAT32) support because the purpose of this approach is to avoid the boot time penalty of searching for a file system hierarchy when it is not always necessary.
Edit4: ...and Sure enough, dumping the first 512 bytes of /dev/block/mmcblk1 shows the Bootable signature (0x55AA) at the end (0x01FE)
... I thought I read that it would just try to read in RAW mode, which makes it not want to even have such a thing, but I knew it had all those other partitions, so I figured I might have been wrong there...
A proper dump of this soon enough.. atleast I gave you guys the boot.rom from the actual OMAP4430 that would have been otherwise hard to retreive... I only wasted one day on this, not bad and I learned some ARM ASM
Edit5: Maybe I am getting ahead of myself, it is of type 0x83 ... which is Linux, not any of the FAT FS which the boot.rom supports... ?
Edit6: Well, it has the file it's looking for, not sure if it's a FAT system like it's suppose to be though, and it looks like in a 1MB dump that fastboot is in the 2nd or maybe more, partition... I still want to try to dump this "MLO" bootup file... but i have to learn about FAT fs structure, ugh...

The implications of deep hardware hacking like this make me very excited for what could be possible with the Bionic. It contains some absolutely absurd hardware for a mobile device so the sky's the limit at this point. Fantastic work! I could only dream of being able to comprehend the things that guys like you can.
Also I wonder if this thread would end up getting proper attention in the dev section.

projektorboy said:
The implications of deep hardware hacking like this make me very excited for what could be possible with the Bionic. It contains some absolutely absurd hardware for a mobile device so the sky's the limit at this point. Fantastic work! I could only dream of being able to comprehend the things that guys like you can.
Also I wonder if this thread would end up getting proper attention in the dev section.
Click to expand...
Click to collapse
I only wish I could comprehend what he is talking about. I'm glad to see a vested interest is being taken!
Sent from my DROID BIONIC

Thanks so much, Noxz for making the effort to do this!

hey, thanks finally for the responses, a full day after the initial dump and no responses... I think because it's NOT in the dev section... but I can't post a thread there until I have 10 posts... maybe I can get that privilege now, moderators?
The bad part with disassembling is that when it computes an jump in code(in ARM it's called a branch) and doesn't give a specific address, it makes finding that code very hard.. I found the text "MLO", the bootable file, in the boot.rom but nothing of the code I know referenced it yet, unfortunate because that partition is not a standard FAT fs and thus is taking a while to read, but if I did have the disassemble of the ROM code where it looks for that, or even just the file search, then I could easily see what it is reading...
Obviously knowing that fastboot and such is in the second or third partition is quite a step forward, but I need to dump this MLO file so we can read from start to finish...
I'll keep everyone posted

So this partition isn't a correct FAT fs... I don't know if being identified as a Linux partition means anything and I'm just not reading into it right, but I am having some time trying to look into these files, you can easily see the MLO file, a KEYS file, and a PRIMAPP file right at the start, or I should say the file name, but there isn't much information on where they are mapped, etc etc...
Maybe partition2 will be better? It's also identified as a Linux partition
I still have a few days to waste...

Sorry to ask dumb. But what exactly does this benefit me when flashing it?
Sent from my DROID BIONIC using Tapatalk

The current fastboot does not have several commands that is in the original source... but really, I am just interested in the entire boot procedure.. there's a few things I might like to change... The good news is because everything but the boot.rom resides on the eSD, that means we should be able to write to it very easily, so we can change quite a bit

Noxz, I am along with these guys in I would understand more if I was just dropped in the middle of Ghana :\ but I would like you to know that you have given me my 1024th item on my 'to research' list. So once I get bored with what I'm doing now, I am going to try to learn a little bit about ARM and OMAP

Hah, I understand...
I've done a bit of x86 ASM and BIOS disassembly before.. so I figured I might as well peek into this and see what is being hidden and such...
I am seeking help right now... If you know anything about the FAT filesystem... you can start by doing "dd if=/dev/block/mmcblk1p1 of=/mnt/sdcard-ext/partition1"
.. It obviously has that MLO bootup file in it as mentioned in the OMAP4430 TRM but I can't seem to trace what cluster it might be in... I have to assume that it is in fact a FAT fs... but it doesnt seem to follow any of the structures/formats I've been reading... ???

The boot rom you've dumped is the ti omap itself; the only real purpose of that is to bootstrap the bootloader. You are correct in that it's not a GP; none of the Motorola phones are -- this boot rom is what verifies the signature of the bootloader.
http://www.droid-developers.org/wiki/Booting_chain
While not exact, the above diagram will give you an overview of the layout used by Motorola phone. The short version is boot rom -> mbmloader -> mbm -> lbl -> kernel, where mbmloader is the Motorola terminology for the MLO or X-LOADER referenced in the TRM. mbm is the bootloader (motorola boot manager) and controls all actions henceforth, including fastboot (which replaced an older sbf protocol).
The CDT acts as a partition table and lists the layout of the device, including marking where the signatures are located and how often they're checked.
http://blog.opticaldelusion.org/2011/10/bionic-development-notes.html

Sorry for late answer.
Here you can find example of reversing OMAP 3430 bootrom http://hg.droid-developers.org/reverse_engineering/src/b8b881184b5f/asm
As mentioned before droid-developers wiki contain a lot of info about bootrom.
Here you can find info about bootrom itself http://www.droid-developers.org/wiki/Application_Processor_Boot_ROM
Here you can find info about security model in omap http://www.droid-developers.org/wiki/Security http://www.droid-developers.org/wiki/Secure_Services
Here you can find info about my project - emulation of early OMAP booting (including bootrom debugging) http://www.droid-developers.org/wiki/QEMU

S-off with Firewater

Another S-Off script that was sent to me by coremark. Successfully s-off my device and supercid.
http://firewater-soff.com/
Thanks to @coremark.

After gaining S-off on a fully stock device using Firewater + temproot, what is the easiest method for permanent rooting?
Since due to S-off full access is granted to all partitions, is it possible to install the su binary and superuser / superSu apk to the /system partition without flashing a custom recovery? For example by using "adb push" or a root file manager?
Where can I get a su binary? Should I extract it from superSu / superuser recovery ZIP package?
Could anyone walk me through the steps?

edorner said:
After gaining S-off on a fully stock device using Firewater + temproot, what is the easiest method for permanent rooting?
Since due to S-off full access is granted to all partitions, is it possible to install the su binary and superuser / superSu apk to the /system partition without flashing a custom recovery? For example by using "adb push" or a root file manager?
Where can I get a su binary? Should I extract it from superSu / superuser recovery ZIP package?
Could anyone walk me through the steps?
Click to expand...
Click to collapse
I'm afraid you'll need a custom recovery for this. The /system write protection is implemented in kernel (the kernel doesn't sync changes to the actual block device and keeps them in RAM) and S-OFF is completely orthogonal to this. To work around it, you'd need a custom kernel (which is not feasible at the moment since HTC haven't released the full source tree yet, unfortunately) or the wp-mod hack (which I would be afraid of using, to be honest).
Also, why avoid custom recovery when you're already S-OFF and you can flash the stock recovey anytime?

koniiiik said:
The /system write protection is implemented in kernel (the kernel doesn't sync changes to the actual block device and keeps them in RAM) and S-OFF is completely orthogonal to this.
Click to expand...
Click to collapse
You are right, that makes sense.
But then how is this possible (if it is at all)? -> http://forum.xda-developers.com/showthread.php?t=2339056
(Pls check out the 2nd post from member "Indirect".)
AFAIK the One has the exact same kind of /system write protection as the 901s. Doesn't it?
Just out of curiosity, why would you be afraid to use wp-mod? Unknown / unpublished source? Bad feedback from users?

edorner said:
You are right, that makes sense.
But then how is this possible (if it is at all)? -> http://forum.xda-developers.com/showthread.php?t=2339056
(Pls check out the 2nd post from member "Indirect".)
AFAIK the One has the exact same kind of /system write protection as the 901s. Doesn't it?
Click to expand...
Click to collapse
To be honest, no idea. All I do know is that on my phone the write protection works the way it does and I don't really see a feasible way around it. Also, I haven't tried these exact steps. It's possible that adb remount does some extra work or something. Moreover, I'm not sure about the adb shell chmod ... command – that would require root, wouldn't it? But since I haven't tried it, I can only guess.
If you don't mind trying it, I'd be interested in the results.
edorner said:
Just out of curiosity, why would you be afraid to use wp-mod? Unknown / unpublished source? Bad feedback from users?
Click to expand...
Click to collapse
The way I understand wp_mod works is that it monkey-patches the running kernel's filesystem driver to skip the check for the /system partition. In other words, it rewrites the code of the running kernel in-memory. This by itself is reason enough to be extremely careful around such code as it has potential for a major disaster. Missing the right memory location by any nonzero number of bytes can result in the kernel doing practically anything (most likely a crash).
Now, to make matters worse, these seem to be only a few binary versions of the kernel module and people seem to just take a binary compiled for one kernel, modify the version information within the file to make it match other kernels and load it on a completely different kernel. This, to me, is borderline insane, considering that the kernel binaries depend on the version of the kernel, used compiler and even compiler flags used when building.
Again, though, I haven't actually looked at the module's source code; can't say I'm suffering from a surplus of free time and I'm also not *that* interested in it. Most likely it's written in a robust enough way to have a high chance of success. (This seems to be backed up by anecdotal evidence – the thing appears to work for people, which is a small wonder for me.) All of the above is actually just my interpretation of stuff I read in some threads here on XDA-developers and I haven't even tried to confirm it myself.
Still, for me, using the recovery for any such changes is a sufficient and acceptable workaround, since I don't need to modify /system that often.

Wow! Thanks for the exhaustive expanation about WP-mod!
If you don't mind trying it, I'd be interested in the results.
Click to expand...
Click to collapse
Well I am also a bit skeptical about this solution. So I am not sure I will be brave enough to try it
But if I do decide to give it a try, I will post the results here, I promise.

edorner said:
Well I am also a bit skeptical about this solution. So I am not sure I will be brave enough to try it
But if I do decide to give it a try, I will post the results here, I promise.
Click to expand...
Click to collapse
As far as @Indirect's post goes, that should be risk-free – either it does work, or it doesn't do anything. I don't see how it could harm your phone. Worst case, you end up with a /system/xbin/su binary that doesn't work due to wrong privileges (or owner information), in which case you should be able to just remove it and start over.

koniiiik said:
As far as @Indirect's post goes, that should be risk-free – either it does work, or it doesn't do anything. I don't see how it could harm your phone. Worst case, you end up with a /system/xbin/su binary that doesn't work due to wrong privileges (or owner information), in which case you should be able to just remove it and start over.
Click to expand...
Click to collapse
Ah, I see. In that case I will definitely try it!
Truth is I am still an Android noob, I used ADB maybe on two occasions so far, and did not have the time yet to properly check out the documentation for these particular commands.
One more question:
If I understand correctly, Firewater (when used together with the temproot) will also unlock your bootloader. Do you think the apps in /data/preloadwill be deleted in this case too? (I.e. does it do a factory wipe like the unlock process via HTCDev?)
If so, how do I restore the apps? Do I simply copy the APK's back to /data/preload with a root file manager, and that's it?
IIRC Helium backup is not really perfect for the purpose, because it is unable to restore those apps to /data/preload, and puts them to the standard app path. Is this what you remember, too?

edorner said:
One more question:
If I understand correctly, Firewater (when used together with the temproot) will also unlock your bootloader. Do you think the apps in /data/preloadwill be deleted in this case too? (I.e. does it do a factory wipe like the unlock process via HTCDev?)
If so, how do I restore the apps? Do I simply copy the APK's back to /data/preload with a root file manager, and that's it?
IIRC Helium backup is not really perfect for the purpose, because it is unable to restore those apps to /data/preload, and puts them to the standard app path. Is this what you remember, too?
Click to expand...
Click to collapse
No idea, I haven't used firewater, but my guess would be that it won't wipe anything…
As for backing up /data/preload, you can for example use temproot to get access to the directory, copy it somewhere on your sdcard and adb pull it. In case it gets wiped, you can just push it back again and voilà. It's going to require some shell-fu, however.
Alternately, you can just download my ZIP of the latest stock ROM and extract it, it contains the latest /data/preload.
And yes, just copying the APK files into /data/preload should suffice *– Dalvik and its package manager is intelligent enough to detect something has changed in there and perform any installation steps necessary. If it doesn't work right away, a reboot should fix things.

Edorner. It won't wipe. I tried it already.
Sent from my GT-I9305 using XDA Premium 4 mobile app

koniiiik said:
As far as @Indirect's post goes, that should be risk-free – either it does work, or it doesn't do anything. I don't see how it could harm your phone. Worst case, you end up with a /system/xbin/su binary that doesn't work due to wrong privileges (or owner information), in which case you should be able to just remove it and start over.
Click to expand...
Click to collapse
So, as promised, I tried the "adb remount" command on my device and it did not work.
Code:
adb remount
remount failed: Operation not permitted
However "mount -o remount,rw -t ext4 /dev/block/mmcblk0p38 /system" in root shell (acquired by temproot) worked like a charm And the modifications to /system performed afterwards turned out to be permanent. So in the end I was able to gain root without using a custom recovery.
Based on my experiences, I created a guide which summarizes all the steps necessary to S-OFF and root a completely stock device without using HTCDev unlock and custom recoveries.
I investigated a bit as to why "adb remount" would not work, and found two interesting topics on XDA about the issue:
[2013.05.24][ROOT] adbd Insecure v1.30
Can't get ADB Root Access in certain ROMs?
In short, "adb remount" is only available if the ADB daemon is run in "insecure" mode in a particular ROM. And unfortunately our stock ROMs seem to use secure ADB.

edorner said:
So, as promised, I tried the "adb remount" command on my device and it did not work.
Code:
adb remount
remount failed: Operation not permitted
However "mount -o remount,rw -t ext4 /dev/block/mmcblk0p38 /system" in root shell (acquired by temproot) worked like a charm And the modifications to /system performed afterwards turned out to be permanent. So in the end I was able to gain root without using a custom recovery.
Based on my experiences, I created a guide which summarizes all the steps necessary to S-OFF and root a completely stock device without using HTCDev unlock and custom recoveries.
I investigated a bit as to why "adb remount" would not work, and found two interesting topics on XDA about the issue:
[2013.05.24][ROOT] adbd Insecure v1.30
Can't get ADB Root Access in certain ROMs?
In short, "adb remount" is only available if the ADB daemon is run in "insecure" mode in a particular ROM. And unfortunately our stock ROMs seem to use secure ADB.
Click to expand...
Click to collapse
Fantastic guide, I just read it and wow.
Also, good to know that particular procedure disables the write protection. I'll have to investigate this sometime, because just now I tried and found out that on my device, the changes to /system are rolled back as soon as I remount /system read-only again. Maybe if I left it read-write all the time, they would persist as well...? I'll have a closer look at this later.

koniiiik said:
Fantastic guide, I just read it and wow.
Also, good to know that particular procedure disables the write protection. I'll have to investigate this sometime, because just now I tried and found out that on my device, the changes to /system are rolled back as soon as I remount /system read-only again. Maybe if I left it read-write all the time, they would persist as well...? I'll have a closer look at this later.
Click to expand...
Click to collapse
Thanks
Hm... Strange...
Instead of manually remounting /system as "ro", I simply rebooted the device. (What can I say, I am hopelessly lazy ) After the reboot I checked the permissions of /system by issuing the "mount" command without any parameters. It showed that it was remounted using the original settings:
Code:
/dev/block/mmcblk0p38 /system ext4 ro,noatime,data=ordered 0 0
So in theory, rebooting instead of manually remounting as "ro" should not make any difference. But who knows
After the reboot, I checked the changes I made to /system previously, and fortunately they did not disappear. (su was still there, I could successfully copy it, and execute it.)
Since then, I've performed a couple more reboots and at least one full shutdown-startup cycle as well. And I still have not lost any changes.
Please let me know if you find something out! I am very interested.

HD PLus Partition Table restoration

I've tried diving through google and the site looking for a solution to this. Between noise,missed hits, and age, I am not having any luck finding out if this is solvable.
I made the mistake last year of trying the fstrim fix on a model that was clearly a bad idea on - funny how I found all the "DON'T!" articles a year later despite being from before my search. . *ah well* I toyed with the fixes at the time but never had much luck and set it aside for a while.
Started looking again last night and was able to at least determine the Nook isn't dead. CWM comes up, I can hit it with ADB. fdisk doesn't seem to see anything ( which I'm guessing is expected but I'm unsure why ) so I'm uncertain how to restore. the partition tables.
I have an identical model I can clone if there are any sane processes for doing such, but i've been unable to ask search engines the right questions.
Can someone clarify if this is possible or if I'm "stuck" running off of an sd card from now on?
Thanks.

dbolack said:
I've tried diving through google and the site looking for a solution to this. Between noise,missed hits, and age, I am not having any luck finding out if this is solvable.
I made the mistake last year of trying the fstrim fix on a model that was clearly a bad idea on - funny how I found all the "DON'T!" articles a year later despite being from before my search. . *ah well* I toyed with the fixes at the time but never had much luck and set it aside for a while.
Started looking again last night and was able to at least determine the Nook isn't dead. CWM comes up, I can hit it with ADB. fdisk doesn't seem to see anything ( which I'm guessing is expected but I'm unsure why ) so I'm uncertain how to restore. the partition tables.
I have an identical model I can clone if there are any sane processes for doing such, but i've been unable to ask search engines the right questions.
Can someone clarify if this is possible or if I'm "stuck" running off of an sd card from now on?
Thanks.
Click to expand...
Click to collapse
First, the HD/HD+ does not use a DOS based partition table so fdisk will not work. It has a different system, I think GPT, but not sure it is the right name.
But if you look at my HD+ stock tip thread linked in my signature, you will see I have an article about partition structure there. If you use TWRP on SD it has a terminal emulator that will let you run the routines for backing up and restoring the partitions.
But if you truly messed up with the fstrim fix your device has become read only and it is not fixable.
Sent from my SM-T707V using XDA Premium HD app

leapinlar said:
First, the HD/HD+ does not use a DOS based partition table so fdisk will not work. It has a different system, I think GPT, but not sure it is the right name.
Click to expand...
Click to collapse
This is the provided, linuxy fdisk on the CWM image when I did a adb shell, not the host OS, which also isn't dos. Unless it's behaving in a way different than expected, it should detect the block devices even if it does not understand the partitioning table. Newer implementations of fdisk do speak gpt, but I rather doubt that's on the CWM image. I believe you are correct that it is a gpt table. I'll have to verify against my other device.
leapinlar said:
But if you look at my HD+ stock tip thread linked in my signature, you will see I have an article about partition structure there. If you use TWRP on SD it has a terminal emulator that will let you run the routines for backing up and restoring the partitions.
Click to expand...
Click to collapse
I'll have to give that a whirl. I hadn't spotted that particular bit.
leapinlar said:
But if you truly messed up with the fstrim fix your device has become read only and it is not fixable.
Click to expand...
Click to collapse
I'm not sure. If I run blkid I do see that the two partitions that CWM has a wipe/format seem to have file systems on them, but they are the only ones detected. This makes me think the partitions are borked in some very creative way and I either can't see the table to fix it with the tools I'm using or the tools I need aren't present on my image.

dbolack said:
I've tried diving through google and the site looking for a solution to this. Between noise,missed hits, and age, I am not having any luck finding out if this is solvable.
I made the mistake last year of trying the fstrim fix on a model that was clearly a bad idea on ...
...
Can someone clarify if this is possible or if I'm "stuck" running off of an sd card from now on?
Click to expand...
Click to collapse
If your EMMC is bricked due to "having run fstrim on a faulty EMMC chip", your only option is to run on SD a special "no-emmc" CM ROM such as the one posted at https://iamafanof.wordpress.com/201...-4-4-4-for-bricked-no-emmc-nook-hd-04nov2014/.

digixmax said:
If your EMMC is bricked due to "having run fstrim on a faulty EMMC chip", your only option is to run on SD a special "no-emmc" CM ROM such as the one posted at....
Click to expand...
Click to collapse
Interestingly, using the link to the buggy EMMC Page at Cynogen ( sorry, newb can't link ) mine is not on the list of known offenders.