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...

[Q] Porting Meego to the Tab, some Android noob questions before I start

Hi chaps,
I've just bought a Galaxy tab with plans to port Meego to the device.
I'm new to all the Android stuff, and tbh the myriad methods for doing this/that/the other and the relative lack of explanation of what's actually being done in these various methods/tools is quite confusing (and worrying).
So, if you'll bear with me, I have a few questions which are probably quite basic.
I've rooted my Tab using SuperOneClick, no problems there, I also understand that there is a leaked flashing tool called (Multi)Odin and an open source flashing tool called Heimdall. I understand adb.
So onto the questions:
Before I start messing about, how should I backup my existing firmware image? I see people talking about taking image dumps using dd, or Odin or Heimdall. What is the preferred method? And how should one then restore the device from these backups?
Alternatively is it possible to simply download the firmware directly from Samsung (I see links to later firmware, but really I'd be happy with what I have currently - P1000XXJK5 and FROYO.XWJJ7)?
I'm assuming that the best installation method would be to replace recovery, then I can add my own kernel and have it boot a rootfs mounted on the external SD card for example. Any thoughts?
I've seen one thread about people compiling their own kernels, with panics and the like which are solved by giving the full path to the initramfs extracted from the existing image. Any clues as to why the built version doesn't work? This is not so important as I can have a look at this when I build the Samsung source.
Is anyone looking at the bootloaders? Is there any information anywhere about them (as changing the bootloader to allow selection of the kernel to be booted would make life easier)?
Thanks for your patience!

Ok, so to partly answer myself, I see www dot samfirmware dot com has links to downloads of firmware images.
I'd really prefer to generate my own image of what's currently on the device rather than trusting a download site, but I guess it's better than nothing. Does anyone know how these images were generated anyway?

lardman said:
Ok, so to partly answer myself, I see www dot samfirmware dot com has links to downloads of firmware images.
I'd really prefer to generate my own image of what's currently on the device rather than trusting a download site, but I guess it's better than nothing. Does anyone know how these images were generated anyway?
Click to expand...
Click to collapse
Samfirmware get their images direct from Samsung insiders. They are not dumps.
If you want to dump from your device search "rotobackup" here in the dev forum.
Sent from my GT-P1000 using Tapatalk

alias_neo said:
Samfirmware get their images direct from Saunaing insiders. They are not dumps.
Click to expand...
Click to collapse
Ok that's reassuring.
alias_neo said:
If you want to dump from your device search "rotobackup" here in the dev forum.
Click to expand...
Click to collapse
Great, just what I was looking for, many thanks

So some more questions:
Any limit to the size of the kernel? Presumably just the size of the partition (which after extracting the image for backup seems to be a pretty large 15.4MB)?
What do all the .rc files in the raminitfs do? They are as follows: fota.rc, init.goldfish.rc, init.rc, init.smdkc110.rc, lpm.rc, recovery.rc
The init.rc is the normal init.rc file, so that's fine. Presumably the recovery.rc file is run if the bootloader detects that recovery mode is wanted (holding down keys during boot). The init.goldfish.rc? I guess this is to do with the emulator, though why it would be in a release image I don't know.
I assume that init.smdkc110.rc is automatically run somewhere along the line, though I don't see where it's started.
Any thoughts on lpm.rc and fota.rc? Are multiple .rc files run for the normal and recovery boots?
Thanks

lpm.rc is for low power mode that displays battery charging animation
goldfish is for running the rom under qemu.
backup your rom using rotobackup. compile samsung's kernel from sources, mix up default initramfs with meego's init scripts. pack all Meego stuff into loop mounted disk image. then flash zImage to kernel and your disk image to factoryfs using heimdall. I assume you have experience hacking N8xx/N900 and Maemo or Meego?
factoryfs is around 300MB so I think it should fit Meego and it (and kernel) can be easily restored with heimdall.

Thanks for the comprehensive reply
Yes I do have experience hacking Maemo/Meego, though have never really had to fiddle with init scripts before and this is as good a reason as any to learn.
I'd actually like to dual boot, so am modifying recovery.rc to bring up the Meego system on the external SD card.
Am just fiddling about building extra kernel modules now (needs btrfs for my image for example) and modifying the recovery.rc file.

Hmm, well I was all set to go and flash my new zImage and was looking for the heimdall command line, when I saw this at the top of one of the threads in this part of the forum (http://forum.xda-developers.com/showthread.php?t=870690):
Restoring to factory after using this process (you need using stock images):
heimdall flash --kernel stockzImage --recovery stockzImage --factoryfs factoryfs.rfs
Click to expand...
Click to collapse
Which has made me worry a bit that I've missed a recovery partition with its own kernel and wrongly assumed that the same kernel is used for both recovery and normal running, just with a different .rc file to be interpreted by init.
Any thoughts?

Do we trust the partition sizes reported here: http://forum.xda-developers.com/showpost.php?p=9471190&postcount=14
They seem very small for the kernel partition. I used RotoHammer's dd method to grab the contents of the partitions as a backup, so am assuming the sizes shown above are not correct (or represent something else?)
Going back to RECOVERY and ZIMAGE partitions - the ZIMAGE partition contains a recovery.rc, the question is really whether, even if they use the same zImage in both the ZIMAGE and RECOVERY partitions, the version in the RECOVERY partition is actually booted if recovery mode is selected (by holding the up volume key, etc.)? OTOH it may be that the RECOVERY partition is either empty or unused, has anyone tested specifically to see whether recovery.rc is run from the ZIMAGE partition?

Well I think I can answer my own question there, I flashed my modified kernel (modified recovery.rc) only to the KERNEL partition, and it boots normally if I don't touch anything, and just gets stuck on the first Samsung screen if I boot in recovery mode.
So it's doing something, I just can't tell what. Not sure if any kernel messages are getting lost behind that image, or perhaps they aren't even output to the framebuffer at all. I seem to remember seeing something about disabling the splashscreen so I'll go and have a look for that. Anyone got any other suggestions?
P.S. I also note there's a flash of screen corruption as the device starts up with my new kernel, I don't remember seeing that before. Is this a usual occurance?

I see from the Nexus S port that including adbd in the image seems to be the way to go for early messages, I'll need to generate a new Meego image and have another go later on.

Interesting, I can't see that I've done anything wrong, and my extra init shell script is not started. I am trying to use the "exec" keyword in recovery.rc to start a shell script which will pass control to the Meego rootfs. At the start of my shell script I start adbd (i.e. still within the initramfs), so I should be able to tell if it has started, and it doesn't appear to do so.
Therefore I did some Googling, and I've seen that in some cases the initramfs init does not implement the "exec" keyword (http://forum.samdroid.net/f9/new-init-exec-import-implemented-3280/). This is troublesome for me as it's what I'm trying to use, but at least would explain why I don't seem to leave the init process
I couldn't see the Samsung specific source for init anywhere, has anyone found any? I'm not happy to replace it using the standard Android source as I'm guessing there's code missing which allows the bootloader to tell init how the device was started so that it knows which of the .rc files to run. Has anyone looked into this?
Thanks

Looking at the code in that link it looks pretty straightforward, just a case of parsing the kernel command line (though I might just reverse engineer the existing init first to make sure I'm not missing anything).
Would still be easier to get the actual source code from Samsung, so I've emailed their Open Source group.

lardman said:
P.S. I also note there's a flash of screen corruption as the device starts up with my new kernel, I don't remember seeing that before. Is this a usual occurance?
Click to expand...
Click to collapse
I get it with CM

Does CM use a compressed initramfs? I'm using one of those and wondering if it's something to do with the (admittedly small) extra time required to move to init.
I don't have my Tab with me here, could someone post the output of /proc/cmdline please? You'll need to be root. Thanks.

Well it's booting you'll all be glad to hear.
More details to follow, but from memory the following were required:
Custom kernel to add btrfs support (as the image I'm booting is a btrfs partition on the external SD); kernel patch to allow compile-time cmdline to be added to the end of the bootloader cmdline (to enable console=tty0); replace Android init with init script to perform some basic setup then pivot_root to the Meego partition.
Next steps are to get the Meego system running usefully (which includes getting a terminal as currently I just have a login prompt but no way of inputting anything!) and also seeing whether I can get dual booting working with an Android system standard boot and Meego replacing the recovery boot.
Poor pic, but still: http://people.bath.ac.uk/enpsgp/Tab/PICT0040.JPG

Good stuff. Thanks for keeping us informed.

After you've got the groundwork for this done, how easy would it be to get Ubuntu running?

Try google http://lmgtfy.com/?q=ubuntu+on+galaxy+tab
Sent from my GT-P1000 using XDA App

brilldoctor said:
Try google http://lmgtfy.com/?q=ubuntu+on+galaxy+tab
Sent from my GT-P1000 using XDA App
Click to expand...
Click to collapse
That's using chroot, which I don't want. I want it running natively.
Sent from my Galaxy Tab

[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.

[Q] XT890's Medfield SoC architecture

(I know this thread maybe should belong to Development forum, but I'm posting here since I don't have enough posts to discuss there yet)
I'm in the second year of Computer Science, being a dynamic/interpreted languages programmer for over 6 years now, C/C++ for 2 years.
I have a solid understanding on the x86 PC architecture: interrupts, buses, etc. I'm pretty good at basic x86 assembly... Been studying UEFI for over a month... Whatever.
I've lost the past couple hours searching but didn't find anything on the architecture of our device. Is the "Bootloader" here compared to a BIOS? Or is it like any PC bootloader (MS-DOS, Windows, Linux bootloaders). Is there anything like a BIOS at all or does the OS, once booted, manages all the hardware interrupts by itself? Can I use INT 10H on XT890? Is it ANYTHING close to the PC architecture?
PCI, ISA, (parallel and serial) "ports" managed by a chipset between the peripherals and the x86 core itself?
Ok, it's x86. Once the system has booted, we can call x86 instructions, ok... But what is under that? Is there any reference on this? How can I boot my own code, if it's not Linux?
I really got nowhere trying to learn about the architecture underneath Android and Motorola's Bootloader on Medfield. Found nothing on Intel nor Motorola websites. What am I doing wrong?
Thanks in advance!

I'm studying this myself but there is a lot that i need to learn. Check those to see if helps.
http://bootloader.wikidot.com/android
http://elinux.org/Android_Booting
http://www.ibm.com/developerworks/linux/library/l-linuxboot/

I would like more info about the RAZR I as well, considering it's the only mainstream phone with a x86 processor I'd expect more documentation about it, I am receiving a RAZR I soon.
For what I know, it's boot process is similar to other Android devices, it loads and decompresses a boot.img file that includes a ramdisk and the kernel, you should be able to load another non-linux OS by chainloading a secondary bootloader there, I honestly would like to see more development on the Razr i, specifically to get native Gnu-linux with x11 running

Using @thiagomtl's links, I was able to understand a little more about the Boot process. XT890 seems to have basically the same mechanics of the ARM ones, but x86 tuned.
However I'm yet to understand the differences between "normal" Linux bootstrapping and the Android Bootloader's one.
On a average legacy Linux box we have GRUB/LILO on the MBR. Making a hell of a simplification here: The user turns the PC on, BIOS does the POST and then loads whatever code is on the MBR. GRUB is a very small program there, which simply loads a driver for the storage device, loads vmlinuz and the f*ing ramdisk on the memory and executes it (effectively by simply pointing the IP to the address where the kernel is on the memory).

Samuelgames said:
I would like more info about the RAZR I as well, considering it's the only mainstream phone with a x86 processor I'd expect more documentation about it, I am receiving a RAZR I soon.
For what I know, it's boot process is similar to other Android devices, it loads and decompresses a boot.img file that includes a ramdisk and the kernel, you should be able to load another non-linux OS by chainloading a secondary bootloader there, I honestly would like to see more development on the Razr i, specifically to get native Gnu-linux with x11 running
Click to expand...
Click to collapse
But the Boot process is just a part of my original question. Ok, a important one, but a part.
What about the structure of the device? How it's all implemented? Is the display using plain old VESA VBE? Are the input devices PS/2? USB? Is the power implemented using ACPI standards? lol

As far as I'm concerned Atom SoC doesn't respect many industry standards for the architecture, even for those who run Windows 8, buttons on the Razr I should be naturally be defined as GPIO as the notification LED, I don't think the display respects VESA standards (SGX 540 can't even do scaling) but it should fallback to them at some extent depending on how you initialize the framebuffer.
All of this should be in the Motorola kernel, I haven't taken a look at it but I'll surely will once I get my phone

@Hazou, @YaPeL, @Omar-Avelar
you guys know anything about this?

Ok this is all i know about it by searching through the code and internet and by finding out myself (no sources included, just my memory). It's all linux, nothing like Windows.
Kernel:
We indeed are making a x86 kernel, but not for normal PC's. We use the mid-x86 implementation within the x86 code of the kernel. (arch/x86/platform/mid-x86) MID is the intel word for all the socs for mobile platforms intel is using. The normal upstream linux doesn't provide all the necessary code. And is has changed with the new android version 4.4.2 for our device.
Boot sequence:
The android devices use some sort of bootloader. Droidboot. Droidboot includes the fastboot commands and starts the bringup of the android system. You can read about it on the internet. In most devices (ARM) it is the first thing thats get called for.
Our intel device is a little different. Before the droidboot gets loaded the firmware of the device loads another OS. Also called POS (i think preprocessor OS, or something). Those gets updated with the dix and efwi(wrong name) files we got. The POS can be accessed by booting in the medfield download through the camera button, if i am correct. The POS then loads the droidboot which will in turn load the rest, like a linux device which loads from the bootloader.
The partition layout can be found in the gpt.bin. It can be flashed through fastboot and can change every partition afaik.
So the boot order is:
1. POS/RADIO
2. DROIDBOOT
3. BOOT.IMG is like linux. First the kernel then the ramdisk with the kernel modules.
4. ANDROID
To comment about the JB implementation.
We can build our own kernel and we can, if we want and take the time, upgrade the kernel to the newest version (for android is that 3.10, but we should be able to manage to go fully upstream 3.17). But that takes a lot of time.
I also noticed that, from what i heard, some kernel modules specific for our device has changed and now the kernel that we have can't load the new firmware files in 4.4. So we will need the next kernel from Moto to compile our own when 4.4.2 is released. Those changed are not upstream.

Hazou said:
The POS then loads the droidboot which will in turn load the rest, like a linux device which loads from the bootloader.
The partition layout can be found in the gpt.bin. It can be flashed through fastboot and can change every partition afaik.
So the boot order is:
1. POS/RADIO
2. DROIDBOOT
3. BOOT.IMG is like linux. First the kernel then the ramdisk with the kernel modules.
4. ANDROID
Click to expand...
Click to collapse
This is the most interesting part for hundreds of us. Is there a way we can find what sectors are used for the pos so we can possibly repair code corrupt?
I have a feeling the gpt is messed up so any amount of writing to the dnx or ifwi will be in the wrong location.
I can't find any information on this phone at all.
I think it's time I bought a spare mobo and dumped everything to compare a broken to working

Flacid Monkey said:
This is the most interesting part for hundreds of us. Is there a way we can find what sectors are used for the pos so we can possibly repair code corrupt?
I have a feeling the gpt is messed up so any amount of writing to the dnx or ifwi will be in the wrong location.
I can't find any information on this phone at all.
I think it's time I bought a spare mobo and dumped everything to compare a broken to working
Click to expand...
Click to collapse
If i am correct they are present on the partition layout of the phone. I just don't know wish ones are the right ones. Never looked good enough at that.
Also to repair the gpt and write the dnx or ofwi to the right location u need a dd command or flash command with the right parameters. The flash command most likely won't work because of the gpt partition and the DD command wont either because most of the time u don't have access to a recovery anymore.
But my knowledge about this is limited, so if u dare to put your phone on the line and have maybe the knowledge and skills to do what some people need, please do I can't and need my phone working

Hazou said:
If i am correct they are present on the partition layout of the phone. I just don't know wish ones are the right ones. Never looked good enough at that.
Also to repair the gpt and write the dnx or ofwi to the right location u need a dd command or flash command with the right parameters. The flash command most likely won't work because of the gpt partition and the DD command wont either because most of the time u don't have access to a recovery anymore.
But my knowledge about this is limited, so if u dare to put your phone on the line and have maybe the knowledge and skills to do what some people need, please do I can't and need my phone working
Click to expand...
Click to collapse
Skills/knowledge = limited. I'm no programmer but I take information in like a 100 petabyte SSD.
My phones knackered, I'm trying to fix it but it's not easy! If it's fixed, I'll break it again to make sure the fix works :good:
It's going to be a long road, there is zero success since the first report of code corrupt.
As you say, I need the right param. There's almost no information about it anywhere and what information is about is very fragmented.
I'll keep you updated

Flacid Monkey said:
Skills/knowledge = limited. I'm no programmer but I take information in like a 100 petabyte SSD.
My phones knackered, I'm trying to fix it but it's not easy! If it's fixed, I'll break it again to make sure the fix works :good:
It's going to be a long road, there is zero success since the first report of code corrupt.
As you say, I need the right param. There's almost no information about it anywhere and what information is about is very fragmented.
I'll keep you updated
Click to expand...
Click to collapse
I am almost certain it can be fixed as long as it is a software failure (some maybe have a hardware failure). As this seems one of them it should be fixable as long as your BL is unlocked. With a locked bootloader u don't stand any chance (nah, maybe with medfield flasher, but that one is also limited).
Take a look at the acer padphone or something. Dunno how it is called exactly. Is also uses the intel SOC and makes use of the medfield flasher.
I never had a phone thats corrupt so can't say much about it, but i can help with thinking my way through. If u have that problem can u boot in fastboot or is that even impossible? I know we can flash the POS and fastboot through xfstk. So with the right combination it should work. And if not we can try flash the modem as extra if that is possible. But do know it can hard-brick the device (modem, lowest thing of the device) of-course, aldo u don't have much choice now
Another thing, because fastboot (and even recovery) can flash the dix, ifwi and bootloader files. I 'assume' xfstk (that can also flash the ifwi, dix and bootloader) can flash the whole emmc with indeed the right parameters. We have the source code of the fastboot/recovery ifwi, dix and bootloader flasher. Also called update_osip.
So think it out, i will wait and see.

uart console
Has somebody tried to access a uart console on our razr-i? would be nice for debugging.
Intels datasheet says the board has 3 uart ports. http://ark.intel.com/products/70097
I hope one uart port can be accessed via usb or audio jack. Like on this device: http://forum.xda-developers.com/showthread.php?t=1081743
Or is it only possible with opening the phone and looking for jtag pins?

How does the Fire boot, and why can't the bootloader be unlocked ?

Hi, having flashed a couple of fires I was curious to understand why we can't unlock the bootloader by copying one from an early (pre-5.0.1) image. Perhaps someone can critique this and fill in the gaps to help me learn?
I understand the general idea that an ARM SoC starts after power or reset by executing from adress zero in memory which must therefore be some non-volatile memory (ROM, but possibly something flashable). The general way it goes is that address zero contains a jump instruction to the entry point of some code that we call the "Boot ROM", all of which is in that non-volatile memory just mentioned.
The boot ROM has just enough capability to initialise RAM and load a secondary bootloader (SBL) into it from some other non-volatile storage such as flash memory (is this the UBOOT partition on the internal flash drive?). The SBL is what we know as the bootloader that responds to the volume-down key and can boot the system (kernel and ramdisk in 'boot' partition) or recovery (kernel and ramdisk in 'recovery' partition), or it can establish itself as a fastboot server.
This left me wondering why we cannot simply replace the SBL image with one from a pre 5.0.1 image that supports unlocking. I don't understand how downgrading can brick the device.
I don't understand the detail and haven't been able to find anything concrete to explain it. If there is, perhaps a link to it might help me. Or if someone can be kind enough to explain it ?
I was thinking that the inability to replace the SBL may be because boot ROM performs verification of the SBL to ensure that it is legit before executing it. I don't know if it does but I read somewhere that the SBL image contains a 40-byte header for this purpose and that the boot ROM contains a verification (public?) key.
I presume the boot ROM is in some flash memory that is inaccessible from the outside and I thought that it could not be modified which would mean that all the SBL versions would need to have been signed by the same key. But I think perhaps the boot rom can be modified and the key contained therein can be changed when upgrading. I am guessing - I'd like to know how this works...
anyway, enough rambling

ogpog said:
Sorry just realised I was in the wrong forum and I can't see a delete option. Would a mod kindly move this to the "Fire Q&A, Help & Troubleshooting" for me pls.
Click to expand...
Click to collapse
Hopefully you found the appreciate threads (two) which address most of your questions. As for the OP you can modify your own posts in XDA; just replace the existing content with a few words (eg: "posted in error...deleted) and resave.

Davey126 said:
Hopefully you found the appreciate threads (two) which address most of your questions. As for the OP you can modify your own posts in XDA; just replace the existing content with a few words (eg: "posted in error...deleted) and resave.
Click to expand...
Click to collapse
I wasn't able to find them, can you point me at them, then I'll mark this as deleted... I did spend ages over a couple of days trying to find the answers.

ogpog said:
I wasn't able to find them, can you point me at them, then I'll mark this as deleted... I did spend ages over a couple of days trying to find the answers.
Click to expand...
Click to collapse
Within these threads you'll find contributors knowledgeable in the subject matter.
http://forum.xda-developers.com/amazon-fire/development/bootloader-unlock-ideas-t3289721
http://forum.xda-developers.com/amazon-fire/development/unbrick-fire-7-5th-gen-downgrade-t3388747

Thanks @Davey126, I had found the first of those posts but not the second one, which I've just had a good read of...