i think i might have found a possible fix for the eMMC corruption.
credits go to 3p4145 for discovering this:
Well I am in no way an expert or have enough knowledge to find an answer.. but I have some basic idea... so here it goes...
If I understand correctly, the problem is that the eMMC driver chip gets corrupt...
This chip controls the MMC0 which is (part of the chip) the actual flash upon which the phone relies to store its stuff...
No Since the issue is seen with rooted phones more often, I would imagine something that was written to the mmc0 is causing issues.. Using root explorer, i found this file on my /proc/emmc
This file seems to have the some sort of memory locations for various directories on the mmc... a corruption of this file could be a bad thing... I am not saying that this is the cause.. but if anyone with a bricked phone could get into their FS (i have no clue how) and check this file.. we could look into coming up with a generic file with memory address that are common....
Mine seems to have locations address for:
misc
recovery
boot
system
cache
userdata
devlog
pdata
Click to expand...
Click to collapse
as he stated, the eMMC files that might be corrupted in the failed eMMC chips are located in /proc/emmc.
i have been able to get to this location using adb
Code:
cat /proc/emmc
so, would it be possible to copy the correct files from a good chip to this location, and fix the failed eMMC problem?
the failed chip's filesystem got corrupted i think (correct me if i'm wrong)
i have the emmc file, pm me if you want it.
seems like a good theory. let's say you do copy the files from a good chip over to the bad emmc...how could you simulate or know when/how the M4G2DE 2.10GiB units would fail?
suchavibrantthang said:
seems like a good theory. let's say you do copy the files from a good chip over to the bad emmc...how could you simulate or know when/how the M4G2DE 2.10GiB units would fail?
Click to expand...
Click to collapse
it's impossible to tell when the chip will fail. but when they do.. could someone try this?
So it's a software failure and not an actual hardware failure? I'm not sure how likely this is to solve the issue, but any movement towards a solution is a good thing.
TeeJay3800 said:
So it's a software failure and not an actual hardware failure? I'm not sure how likely this is to solve the issue, but any movement towards a solution is a good thing.
Click to expand...
Click to collapse
it's more of a firmware issue. inside a computer, there are many different chips. some chips are consisted of firmwares, these are the ones that you can write to and change (like the eMMC chip). other chips, are completely hardware, you can't write to them, you can't change them.
so since the eMMC chip is consisted of "software", then maybe we can replace the corrupted files with good ones.
but i need some testers, since my dead eMMC chip is somewhere in tmobile's dead phones junkyard.
If it's the chip itself that fails - then you can't fix it by writing something to it, since it won't write whatever you're trying to write to it. Trying that would be equal to trying to fix a failed hard disk by using it.
"Firmware" is just another term for software. No chip consists of firmware, firmware is written on memory (permanent or rewritable), which is read by some hardware (usually some type of CPU) that executes this firmware. eMMC is just a rewritable memory chip, and if the controller of the chip fails, or big chunks of the memory in this chip fail - it's not usable anymore.
And of course, there is no such thing as "driver chip". Driver is a program, software, that runs on CPU and is stored in - again - memory. eMMC controller, on the other hand, is hardware, a part of the chip itself. The failure is on a whole another level.
Jack_R1 said:
If it's the chip itself that fails - then you can't fix it by writing something to it, since it won't write whatever you're trying to write to it. Trying that would be equal to trying to fix a failed hard disk by using it.
"Firmware" is just another term for software. No chip consists of firmware, firmware is written on memory (permanent or rewritable), which is read by some hardware (usually some type of CPU) that executes this firmware. eMMC is just a rewritable memory chip, and if the controller of the chip fails, or big chunks of the memory in this chip fail - it's not usable anymore.
And of course, there is no such thing as "driver chip". Driver is a program, software, that runs on CPU and is stored in - again - memory. eMMC controller, on the other hand, is hardware, a part of the chip itself. The failure is on a whole another level.
Click to expand...
Click to collapse
You summed up my thoughts on the issue perfectly, especially the first paragraph. That's why I didn't understand why the OP's theory would work. I'm not knocking his efforts at all...anyone trying to fix the eMMC issue is doing a good thing, it just didn't make sense to me.
oh...
sorry.. i thought the chip was just corrupted when it said "failed"...
well then nevermind, this wouldn't work.
Thanks for talking abt this guys..
I understand what you guys are saying.. but quite often the HW itself is not bad but the address locations are corrupt.. Like I mentioned in my initial post... I am not sure what causes the fault.. but Once caused, IF there is a way to just re-write the addresses for these locations so that the driver chip/Controller chip can try to use the addresses provided is what I am trying to see..
This statement is right on the amrk: "eMMC is just a rewritable memory chip, and if the controller of the chip fails, or big chunks of the memory in this chip fail - it's not usable anymore."
now considering this, IF the controller is physical fault (as in fabrication fault, overheated transistors etc).. the nothing more can be done.. BUT if the fault is just in the addressing fail.. this providing the addresses should work wouldn't you think?
If someone has a brick on their desk they can try this.. Nothing really to loose right?
I would never suggest replacing the emmc file of a working chip.. now thats just crazy talk.. well if you have $500 to spare.. sure.. but I was thinking of fixing a broken one...
One more last thing: The only problem with this approach on a dead phone is getting access to the FS AFTER the phone is dead.. any ideas?
3p4145 said:
Thanks for talking abt this guys..
I understand what you guys are saying.. but quite often the HW itself is not bad but the address locations are corrupt.. Like I mentioned in my initial post... I am not sure what causes the fault.. but Once caused, IF there is a way to just re-write the addresses for these locations so that the driver chip/Controller chip can try to use the addresses provided is what I am trying to see..
This statement is right on the amrk: "eMMC is just a rewritable memory chip, and if the controller of the chip fails, or big chunks of the memory in this chip fail - it's not usable anymore."
now considering this, IF the controller is physical fault (as in fabrication fault, overheated transistors etc).. the nothing more can be done.. BUT if the fault is just in the addressing fail.. this providing the addresses should work wouldn't you think?
If someone has a brick on their desk they can try this.. Nothing really to loose right?
I would never suggest replacing the emmc file of a working chip.. now thats just crazy talk.. well if you have $500 to spare.. sure.. but I was thinking of fixing a broken one...
One more last thing: The only problem with this approach on a dead phone is getting access to the FS AFTER the phone is dead.. any ideas?
Click to expand...
Click to collapse
using adb you are able to get into the filesystem...
A failed partition update would mean the emmc file was corrupted??
Or failed partition update means it wasn't able to update partitions because the chip failed to re-initialize??
If the theory is correct, the EMMC file not the chip is actually screwed up and it can be fixed, but if the emmc chip is what failed then it is irrecoverable.
tKoHaXoR said:
A failed partition update would mean the emmc file was corrupted??
Or failed partition update means it wasn't able to update partitions because the chip failed to re-initialize??
If the theory is correct, the EMMC file not the chip is actually screwed up and it can be fixed, but if the emmc chip is what failed then it is irrecoverable.
Click to expand...
Click to collapse
i'm pretty sure it the eMMC's filesystem got corrupted, but of course, i could be very wrong.
that's why we need a bricked MT4G with dead eMMC.
Has this been posted in the g2 forums? I know they have had some guys lookin into this as well...
Sent from my HTC Glacier using XDA Premium App
irrelephant said:
Has this been posted in the g2 forums? I know they have had some guys lookin into this as well...
Sent from my HTC Glacier using XDA Premium App
Click to expand...
Click to collapse
should i also post this in the g2 forums?
saranhai said:
should i also post this in the g2 forums?
Click to expand...
Click to collapse
I believe there are a few ppl there with the failed emmc that still have their phones...
Sent from my HTC Glacier using XDA Premium App
irrelephant said:
I believe there are a few ppl there with the failed emmc that still have their phones...
Sent from my HTC Glacier using XDA Premium App
Click to expand...
Click to collapse
yes thank you
irrelephant said:
I believe there are a few ppl there with the failed emmc that still have their phones...
Click to expand...
Click to collapse
Do any other models have this issue, or is it just T-Mobile phones?
TeeJay3800 said:
Do any other models have this issue, or is it just T-Mobile phones?
Click to expand...
Click to collapse
I have heard about 4 or 5 phones have had the bad emmc... Just Google phones with bad emmc and I'm sure there will be a list
Sent from my HTC Glacier using XDA Premium App
question: would the stock rom/pd image have this so called "good" file imbedded in it?
i ask because my current phone has gotten the cache errors while on rooted non-stock roms such as ice glacier and CM7..i was able to recover from them...but never once saw any issues after flashing completely back to stock...ive also not seen this issue arise after flashing from stock into Virtuous Unity and ive been on VU for almost 2 weeks and ive flashed a few radios and restarted my phone at least 2 dozen times to see if i get the cache error and so far nothing
all of which kinda leads me to believe that this very well could be a software or file issue thats being written maybe too many times or written with incorrect information due to flashing multiple roms or radios or something...i know not everyone with the "bad" emmc has had issues but maybe they arent doing something to trigger the bad errors
here's the emmc file located in proc:
Related
basically my motorola atrix doesn't work any more!!
the bit of the screen which is meant to be used to access the buttons bellow, work as though you are pressing the bottom of the visible screen!!
EVERYTHING is shifted down! if i want to press something, i have to press the area 1cm bellow the location!
I suspect it is cause by me formatting every single folder on the internal storage using clockwork recovery...
i have tried installing the original Rom using RSD, i have tried everything!!!
ANY HELP PLEASE?
the device is a piece of garbage now!
i saw that NO ONE else has reported this issue anywhere on the net!!
it can't be a hardware problem cause it was working before i formatted all of those folders! including the ones with the 3 character names... can't remember the names... but basically i formatted everything...
this is a common problem when you format / partition the internal memory. it screws up your PDS partition, which i hope you backed up. search a little more, there are lots of topics on this in the dev forum and I believe there MAY be a solution but i don't remember.
Just found a couple of threads...
I didn't back it up... does this mean that my Motorola atrix is practically worthless now? :s
Solution
http://forum.xda-developers.com/showthread.php?t=1131649
this apparently is supposed to work... will try it in a bit.
but still, you won't get the original mac address and bluetooth number and the rest...
:/ sad times... there must be someway to acquire the original values?!?!
benedict.s said:
http://forum.xda-developers.com/showthread.php?t=1131649
this apparently is supposed to work... will try it in a bit.
but still, you won't get the original mac address and bluetooth number and the rest...
:/ sad times... there must be someway to acquire the original values?!?!
Click to expand...
Click to collapse
i'm not sure there are, as those values were never meant to be cleared out.
can ask why you decided to format every folder in the memory?
dLo GSR said:
i'm not sure there are, as those values were never meant to be cleared out.
can ask why you decided to format every folder in the memory?
Click to expand...
Click to collapse
Well, if you look in the post i linked to, it is an image that i pushed into the partition...
it's working now at least!
I do have my mac address and IMEI, do you know how i can edit that image file to put my own values in it? i have no clue as to how the image can be edited.... :/
the reason i did that was because i had an HTC HD2 before. it originally comes with windows, and so when you installed Android, it had a horrible process... in that process, the MAGLDR and CWR as they were called, did not erase every folder in the phone's main memory... so i had gotten used to formatting them individually in that phone.. that's why i did it on the Atrix...
also, in the HD2 they were folders not partitions... so basically, i wasn't familiar with the exact core of Motorola android devices...
there must be a way to put in my own hardware details into the PDS image file?
benedict.s said:
Well, if you look in the post i linked to, it is an image that i pushed into the partition...
it's working now at least!
I do have my mac address and IMEI, do you know how i can edit that image file to put my own values in it? i have no clue as to how the image can be edited.... :/
the reason i did that was because i had an HTC HD2 before. it originally comes with windows, and so when you installed Android, it had a horrible process... in that process, the MAGLDR and CWR as they were called, did not erase every folder in the phone's main memory... so i had gotten used to formatting them individually in that phone.. that's why i did it on the Atrix...
also, in the HD2 they were folders not partitions... so basically, i wasn't familiar with the exact core of Motorola android devices...
there must be a way to put in my own hardware details into the PDS image file?
Click to expand...
Click to collapse
well, that's a little over my head, but i know some of the devs would be able to help you if you PMed them maybe.
coolios...
know anyone in particular?
In case that someone missed it
(tnx to user garwynn)
Fresh off the press...
Q: Do you know the commands to reset the eMMC controller in question?
Originally Posted by Ken Sumrall (Android)
Once the chip has locked up, no command will reset it. It must be power cycled. If instead you are asking how to clear the metadata so the chip works again, the only solution I know is to update the firmware inside the chip, and that also wipes all the data. This probably includes factory calibration data that must be saved before the firmware is updated, and restored after. Also, the boot loader is probably in the chip, and must be restored after the firmware update, or the device will be bricked. This is a dangerous operation, because if something goes wrong, the device will probably be bricked. (emphasis added)
Q: Is there any documentation available on this issue? If so and it is private is it possible to have it released?
Originally Posted by Ken Sumrall (Android)
It is private, I'm asking if I can release it, along with the code to update the emmc firmware. Don't get your hopes up, my guess is the answer will be no.
Q: Alternate erase method?
Originally Posted by Ken Sumrall (Android)
If you really want to erase data on a rev 0x19 samsung emmc chip, I suggest you just write zeros to the entire partition.
Q: Difference between GB/ICS Wipe
Originally Posted by Ken Sumrall (Android)
IIRC, when using recovery to wipe the phone on GB, the make_ext4fs() library would not issue an erase command first, it would just write one a new blank filesystem. This, of course, doesn't really erase all the private data of the user, so we changed make_ext4fs() to first erase the partition, then write out the new filesystem. You can see the code in system/extras/ext4_utils/wipe.c, which didn't exist in gingerbread, but does in honeycomb and later. It is the erase operation on the rev 0x19 firmware that can cause the emmc chip to lockup. (emphasis added)
Regarding Entropy512's summary of observations:
Originally Posted by Ken Sumrall (Android)
Regarding the notes on MMC_CAP_ERASE, the just lists the cards ability to perform the erase command. In other words, if the mmc_erase() function works. What is more important is if anyone calls the mmc_erase() function. Looking at the mmc driver, in drivers/card/block.c, it is only called when a secure discard or discard request is made. As far as I know, those requests are only sent if the filesystem is mounted with the "discard" option, or if userspace code does an ioctl() to erase a partition, like make_ext4fs does. So check the mount options on the filesystems. *If they don't specify "discard", the erase operations are probably not happening.
Of course, a simple debugging printk() in the mmc_erase() function will tell you if anyone is calling it.
Additional info not directly related to questions:
Originally Posted by Ken Sumrall (Android)
The lockup doesn't happen immediately after power-on. The chip doesn't lock up until a sector is referenced that has corrupted wear leveling data inside the chip. Once that sector is referenced, the chip will lockup hard, and the only thing that will get it talking again is to power cycle it. Once it is power cycled, the chip will talk again, until that bogus sector is accessed.
http://forum.xda-developers.com/showpost.php?p=26521643&postcount=293
So, absolutely no CWM wipe for Note, until we got a solution? Maybe change custom ROM CWM wipe as write zeros or delete all files instead of file system format?
It just seems crazy that Samsung/Google cannot release a small file to flash that would fix this problem. I'm sure they could if they really wanted to.
I am asking Samsung Singapore about the eMMC bug on their facebook page. Hope to get some info on whether the bug is proliferating across region ICS versions or have they actually silently fixed it.
for what the note is worth and they sold millions it should be fixed now this is putting me off getting another samsung ,which i really do like them it feels like they have let us down
It is not just the Note, it is all Eyxnos based Samsung phones including the GSII. I could be wrong, but I think they sold a few of those...
It is not just CWM wipe that is the problem. You can brick performing a factory reset on official XXLPY (and all official ICS kernels so far... and all leak ICS kernels). The only safe kernels are those based on GT-I9100 Update4 source code release - this includes XplodWILD's CM9 release (and it's derivatives such as Asylum, Paranoid, MIUI) and Entropy's DAFUQ and that other WizDom kernel with more to come now that there is source available.
FYI, the N7000 source even has the MMC_CAP_ERASE bug. Just look at Franko's kernel thread.
Global recall lmao
Sent from my GT-N7000 using Tapatalk 2
nickshertzer said:
It is not just the Note, it is all Eyxnos based Samsung phones including the GSII. I could be wrong, but I think they sold a few of those...
It is not just CWM wipe that is the problem. You can brick performing a factory reset on official XXLPY (and all official ICS kernels so far... and all leak ICS kernels). The only safe kernels are those based on GT-I9100 Update4 source code release - this includes XplodWILD's CM9 release (and it's derivatives such as Asylum, Paranoid, MIUI) and Entropy's DAFUQ and that other WizDom kernel with more to come now that there is source available.
FYI, the N7000 source even has the MMC_CAP_ERASE bug. Just look at Franko's kernel thread.
Click to expand...
Click to collapse
And the devs on here, now that they have a source, will eventually remove that MMC_CAP_ERASE code from the kernel. Just give them some time. If Samsung won't do anything, then we at XDA will make the best of what we can. And I say Samsung and not Google because the ball really is in Samsung's court, not Google's.
wasnt this published a little while ago on the portal?
panyan said:
wasnt this published a little while ago on the portal?
Click to expand...
Click to collapse
Yes, it was.
So that makes sense FINALLY. GB never did a true wipe, sorta like a soft format pc. Can we just modify the ics kernels to mmc_erase() as how gb runs it and get rid of the new code? This is a temporary work around.
PoisonWolf said:
Can we just modify the ics kernels to mmc_erase() as how gb runs it and get rid of the new code? This is a temporary work around.
Click to expand...
Click to collapse
that was my exact thoughts too as i was reading it -> just do a quick wipe and not full erase
panyan said:
that was my exact thoughts too as i was reading it -> just do a quick wipe and not full erase
Click to expand...
Click to collapse
Yeah, like how Ken talked about Honeycomb and forward having wipe.c, let's just get rid of that nonsense.
I dont know how it works, but if you're on Gingerbread, and you encrypt your phone, and you do a full-wipe in CWM, can a person still access the data? I mean, we now know that they could with the right tools since the information is still on the chip, just not easily accessible. But if it is encrypted, can it be decrypted and accessed? I guess what's the encrypting algorithm and is it the same for all devices?
If the information cannot be accessed if it is encrypted, then paranoid folks shouldn't have to worry with soft wipes.
Can anyone confirm that a 32 GB Note shipped with the same 0x19 firmware on the emmc?
Markuzy said:
I am asking Samsung Singapore about the eMMC bug on their facebook page. Hope to get some info on whether the bug is proliferating across region ICS versions or have they actually silently fixed it.
Click to expand...
Click to collapse
Well don't hold your breath that would mean that Samsung has made a BIG mistake in their's firmware's and that would produce lots of anger and sales drop.
I think IF they decide that they will eventually fix this it would be in big quiet and just like part of "new" firmware like 4.0.4 etc
panyan said:
wasnt this published a little while ago on the portal?
Click to expand...
Click to collapse
andreww88 said:
Yes, it was.
Click to expand...
Click to collapse
Where? This was written yesterday so i don't know what is exactly "little while ago" ?
Additional info not directly related to questions:
Originally Posted by Ken Sumrall (Android)
The lockup doesn't happen immediately after power-on. The chip doesn't lock up until a sector is referenced that has corrupted wear leveling data inside the chip. Once that sector is referenced, the chip will lockup hard, and the only thing that will get it talking again is to power cycle it. Once it is power cycled, the chip will talk again, until that bogus sector is accessed.
Click to expand...
Click to collapse
This concerns me the most. Is there any way to "test" all sectors of the phone's emmc to see if we have the bogus sector?
Like a terminal command to create a file of X size so you could "fill" up the entire phone with a bogus file. Could this work?
PoisonWolf said:
This concerns me the most. Is there any way to "test" all sectors of the phone's emmc to see if we have the bogus sector?
Like a terminal command to create a file of X size so you could "fill" up the entire phone with a bogus file. Could this work?
Click to expand...
Click to collapse
Yes that would be very useful, to actually check if our phones are already damaged ...
Hm, makes me wonder about some peoples SODs
GocaS6 said:
Where? This was written yesterday so i don't know what is exactly "little while ago" ?
Click to expand...
Click to collapse
http://www.xda-developers.com/android/hard-brick-bug-on-galaxy-s-ii-and-note-leaked-ics-kernels/
panyan said:
http://www.xda-developers.com/android/hard-brick-bug-on-galaxy-s-ii-and-note-leaked-ics-kernels/
Click to expand...
Click to collapse
If you read it carefully you'll notice that this is not same conversation
Today Franco Kernel R3 was released and it included the removal of :
* Removed MMC_CAP_ERASE (workaround to fix the superbrick bug)
Boy124 on the other hand, flashed the kernel. Performed a wipe/factory reset twice, and phone successfully booted. As well as, flashed stock GB in PC Odin for checkup, and the rom was successfully flashed.
So is it the time where the bug is being solved? The more confirmation, the better, the safer. Cheers.
GocaS6 said:
In case that someone missed it
(tnx to user garwynn)
Fresh off the press...
Q: Alternate erase method?
Originally Posted by Ken Sumrall (Android)
If you really want to erase data on a rev 0x19 samsung emmc chip, I suggest you just write zeros to the entire partition.
Click to expand...
Click to collapse
Based on the other thread about this.
Is it possible to create a partition from that faulty blocks and mount it on to PC? later on I will use data wiping software to write 0..
Im thinking of trying this. but Im still quite unsure yet on how to actually mount second partition to PC, besides the UMS partitition
Looks like the bug is still there!
blue_panther9_9 said:
Based on the other thread about this.
Is it possible to create a partition from that faulty blocks and mount it on to PC? later on I will use data wiping software to write 0..
Im thinking of trying this. but Im still quite unsure yet on how to actually mount second partition to PC, besides the UMS partitition
Click to expand...
Click to collapse
You cannot format or write zeros into the bad blocks because you cannot access them.
You can low level format the whole chip, but then you need to restore the or rebuild the bad blocks list. Finally you would need a Jtag to rewrite the bootloaders into the chip.
Princeomi said:
Looks like the bug is still there!
Click to expand...
Click to collapse
When the bug damages the emmc, it will not be until after the faulty sector is written to/used that the problem will become apparent.
The bug does not have to be present in the current kernel to cause the brick. In the case of this claim, info about his/her previous ICS flashes and wipes is much more important than the proverbial straw that broke the camels back.
Sent from my GT-N7000 using XDA
Where is the BIOS in this thing? I get that it has /boot /system and /recovery but where is the firmware that the device very first utilizes?
Does the streak even have any type of NVRAM memory?
webdawg said:
Where is the BIOS in this thing? I get that it has /boot /system and /recovery but where is the firmware that the device very first utilizes?
Does the streak even have any type of NVRAM memory?
Click to expand...
Click to collapse
What are you attempting to do?
Understanding and Hacking
I am trying to understand the device and search for potential exploit vectors. If I take out the inner SD card what type of data does the device still have on it?
It has to have something that starts the boot from the inner SD card. Does this something insert anything into the running code on the device? Can it?
Can, if the device has the type of storage I am talking about, the device record and store even a small amount of data?
I have heard of reference to NAND backups and even seen a quote about how the NAND backup util included in the recovery utils does not backup something. The something I am referring to is not the external SD card.
Web...
Strephon Alkhalikoi said:
What are you attempting to do?
Click to expand...
Click to collapse
Why would you need exploit vectors when the system is completely open/unprotected?
the innerSD holds the /data and /cache partitions
It is like I am not making myself clear enough. A computer has a BIOS which passes boot to the OS/bootloader. Would not the phone have the same thing. If you do not know this answer do not ask anymore questions.
Stop asking why I am asking.
TheManii said:
Why would you need exploit vectors when the system is completely open/unprotected?
the innerSD holds the /data and /cache partitions
Click to expand...
Click to collapse
webdawg said:
It is like I am not making myself clear enough. A computer has a BIOS which passes boot to the OS/bootloader. Would not the phone have the same thing. If you do not know this answer do not ask anymore questions.
Stop asking why I am asking.
Click to expand...
Click to collapse
Unfortunately for you it seems you don't know what you're doing or why you're even asking about it
Sent from my GT-I9100 using Tapatalk 2
Okay Then
cdzo72 said:
Unfortunately for you it seems you don't know what you're doing or why you're even asking about it
Sent from my GT-I9100 using Tapatalk 2
Click to expand...
Click to collapse
Please. Unless you have an answer please do not reply. I know exactly what I am talking about. If the device does not have any NVRAM in it that one could flash to and only internal memory via SD card then just say this.
webdawg said:
It is like I am not making myself clear enough. A computer has a BIOS which passes boot to the OS/bootloader. Would not the phone have the same thing. If you do not know this answer do not ask anymore questions.
Stop asking why I am asking.
Click to expand...
Click to collapse
Manii knows far more about the Streak than you do, so if you want your questions answered, I suggest you check that attitude of yours at the door.
Strephon Alkhalikoi said:
Manii knows far more about the Streak than you do, so if you want your questions answered, I suggest you check that attitude of yours at the door.
Click to expand...
Click to collapse
Your right. Did not realize it was him, work has an affect on my attention. Sorry Manni.
I am at home now. Let me try and expain myself.
I just do not get it. All the pages I have read and the research I have done everything tells me that everything is stored on the internal SD card.
But I still have this nagging thought from this page: http://www.rdtk.net/2011/06/25/using-streakmod-recovery/ that says this: the firmwares reside on the nand but in an entirely separate area. only stock recoverys can write to them under normal circumstances, you can probably read/write them manually but it’s dangerous as you can super-brick if you don’t know what you’re doing
What the hell is that guy talking about? The way I read it is that an entire subset of firmware exists on the device that only that one webpage has ever talked about. (That I have read)
I have read alot about BIOS hacks and how they function inserting code into Windows. Even legitimate code for paid services. Computrace.
I know about the Carrier IQ software. What I do not know about is the software outside the rom, recovery, boot partitions and such that exists on the Dell streak or any Android device.
I suppose my attitude comes from the ton of forum posts that I read with unanswered questions because people wanted to know why the OP is asking such a question.
I took Manii's post the wrong way because of your question Steven. Not to offend you and I understand why you ask. For example I just hate going into support channels and asking questions about an iptable rule and being told that I should relearn Linux networking because...well just because I did not understand one concept. I took it the same way here.
I apologize to all.
Web...
MTD based nands are more complicated then eMMC nands in this aspect, as MTD nands you simply cannot read from the 'hidden' portions of the nand. eMMC ones you can.
eMMC devices you can always read from any eMMC partition, so you can likely make complete backups including your modem (though no custom recovery does this by default, it's still a bad idea)
Fortunately for us, MTD seems to be 'obsolete', every device that launched with GB installed or newer uses eMMC.
Dell Streak 5/Partition layout - XDA wiki
Dell Streak Pro/Partition layout - XDA wiki
The S5 is a MTD device, the SPro is eMMC, note how the SPro has many more partitions.
The majority of them also exist on the S5, but the only way to access them (safely) is though a stock recovery.
You can write to them with fastboot, but some of them must be unpacked by an updater in the stock recovery. Simply flash them (specific ones) and you'll super-brick that would require JTAGging at a minimum to fix.
You simply cant read the other MTD partitions without JTAGing (it might be possible with a specificly modified kernal, but you dont gain anything doing this, if at all), assuming that the hidden parts are MTD partitions even. For all we know the controller could be directly writing onto NAND pages with their locs hardcoded (which would kinda be like partitioning, but without the formal partition tables(?) )
There's also is a small amount of memory that can only be written (afaik) via JTAG.
It contains your device's ID, such as Service tag and IMEI.
On tegra devices (at least the S7 and S10) it's the WP1 and WP2 partition.
It could be possible that it's on the NAND as a MTD partition, but if it is we dont know about it. It would be insane (and illegal, as changing your IMEI is illegal in most countries) to write to it, but so there's never been an example of it. I dont know where they are on the SPro, i'd need a live device to check.
The modem OS itself is stored on the nand, the modem processor knows (or the bootloader knows) how to feed it it's OS image.
Location breakdown:
NAND: <everything on the partition layout above, including the below>
/system
/firstboot
boot.img
recovery.img
amss.mbn
appsboot.mbn
dbl.mbn
dsp1.mbn
fsbl.mbn
osbl.mbn
DT.img
The innerSD
/data
/cache
Modem storage (lock state)
Device unique data (IMEI and Service tag)
RTC (the clock)
I dont know the exact terminology or the exact order of booting on qualcomm snapdragons (it's likely to be the same with all at least in the same generation)
But it's something like:
Press power button
CPU powers up
IPL loads <hardwired onto cpu>
Check if innerSD is valid (this is streak specific, device also locks up if it fails as the loader isnt robust enough to work around it)
Init modem and it's firmware <amss.mbn on older devices, non_hlos.bin on newer devices> (FYI modems are themselves complete 'system's in that they have their own ram and OS, basebands are complete OS images in most devices)
Check what button combos are pressed
Start booting:
If you pressed the recovery mode combo:
Load recovery SPL <dbl.mbn? + DT.img>
Display SPL menu:
Reboot
Load Recovery ("update from update.pkg")
Read from recovery.img and load it
Caliberate screen
If you pressed fastboot mode combo:
Load the fastboot loader <fsbl.mbn?>
If you pressed the download mode combo:
Go into download mode (for QDLtool)
If you did not press any combo: begin booting normally
Load dsp1.mbn
Load boot.bin
Linux kernal mounts and starts reading:
/system
/cache
/firstboot
/data
Android boots normally
Boot completes, you're at the lockscreen/home screen
I'm just making educated guesses at which *.mbn does what, as noone's really studied them to the point that they are willing to modify them.
Regardless they're signed so you cant modify them (we dont know per-se that the CPU checks the signatures on *.mbns, but I dont think any is willing to risk their device to try anyway)
The kernal images arnt signed, you can simply toss any kernal that is valid (otherwise it wouldnt boot)
When your device boots, the logo flashes 4 times:
1st logo: IPL and it's logo (possibly hardwired onto chip)
2nd logo: SPL and it's logo (stored in one of the *.mbns)
3rd logo: UBOOT and the kernal logo (stored with the kernal, sounds like a band name)
4th logo: bootimage.zip (whatever boot splash is with the installed rom
TheManii,
Thanks for the information. This is everything I wanted to know. If I have anymore questions I will ask later.
Web...
SOLVED the best way.. See post #5
Hello
I have asked this in other threads, but have not gotten an answer that I can manage to make work yet. I'm also hoping that this thread may help the many others out there with this same problem.
I have an Iconia A500 that has the bad sector problem. I cannot get it to format partitions through any of the EUU's out there,or even the Babsector .bat's . Same thing every time-read/write failure. I have seen mention in a thread or two about guys who have used the "rawdeviceread" and "rawdevicewrite" commands in NvFlash to "map out" any bad sectors on the EMMC chip, and create "dummy" partitions over them so that the tablet will function again, at least until more sectors die anyhow.
Can someone please explain this process, including describing the files needed, exact commands, and the rest of the process to make this happen? I have seen member "Yaworski" describe the basis of it, but again his commands are no-go for me. It would also be great if a partition could be created, but not formatted, completely bypassing any possibility of NvFlash failure.
Thanks in advance By helping me I'm sure you wil also help many others. It seems many a500's are starting to suffer form this same exact issue.
Anyone? I have read thru this post: http://forum.xda-developers.com/showthread.php?t=1691729&page=3 , and seen a couple recommendations to it in other threads, but no dice on making it work .. or even being able to map out the bad sector/s. I know this'lll fix me up at least temporarily...
I need help with this as well. There doesn't seem to be a step by step guide anywhere :\
Sent from my SGH-T769 using xda premium
dynospectrum said:
I need help with this as well. There doesn't seem to be a step by step guide anywhere :\
Sent from my SGH-T769 using xda premium
Click to expand...
Click to collapse
I've been asking around about a possible process of mapping out bad sectors, and not just members in here, but engineers and technicians I know as well. First, the NAND has this sort of embedded firmware that directs it to remap or bypass bad sectors “spontaneously,” if you can call it that. When you're stuck with “write errors” or where the NVflash even fails to create and format a partition, it suggests that this part of that firmware is not working. Why the loose fit, or lack thereof, I don't know.
Second, The FCK guys mention that you can write a dummy file and make the device read back so you can see where the data is missing and circumvent it altogether. But they also state that if Sector 0 – which NVFlash is slated to access – is kaputt, then it would hang, as probably in your case and certainly in mine.
Given that the Boot Configuration Table is 4Kb tiny while the NAND is 16Gb large, I can't imagine the latter being damaged so badly as not to have a continuous space of 4Kb to accommodate such partition. As a matter of fact, I did have someone with special equipment probe my NAND “physically” and the initial report indicated that the first half (50%) of it had less than 3% of its sectors that was bad. NVFlash, however, could neither create nor format, let alone write on it.
So, either one must have the appropriate hardware to do a very low level format to restore the NAND in full or in part, or NVFlash has to be hacked to command writing at a Sector different than 0. Until that happens, I doubt it that a step-by-step guide grounded in current programs would be viable.
I know that neither the custom ROMs nor the custom Bootloaders and Recoveries are remotely the cause, because this occurred way before any of it came onto the scene. But in light of the frequency at which this happens to some of us, it seems ironic to term this device bullet-proof. I'd like to think it's not incurable, but what the FCK do I know? (Sigh) Anyone with the essential hardware know-how to tackle this?
SOLVED..well the "easy" way....
I sourced out a broken A500(strangely the screen is fine though lol), re-soldered the power button on it(PITA), and put it into my A500.
I plan on taking it easy with the flashing on this one. A500s seem to have a growing history of EEMC chip failure from over-flashing. My old board had been flashed MANY times by the previous owner, and a few by me before it died. The "new" tab was only flashed enough to get it to Stock ICS. Now it has the V8 bootloader and Civato's Re-Flexx ROM(Best out there IMHO).
So there you have it.. this seems to be the best way to fix this problem on the A500---Replace the Darn motherboard. I'd imagine mapping/skipping sectors is only a temporary fix that will probably lead to the tablet dying when its needed most.