[Guide] Factory condition restoration / Downgrade to webOS 3.0.0
- Thread starter rr5678
- Start date
You're a giant among men, brother. This was the only thing that would have fixed my new Touchpad. You ended a solid 25 hours of torment for me. Thank you.
Read-only flash / unable to delete 'store'
Hey all, new here. Apologies ahead of time for the length, but I hope it will end up being worth it for some of you. I actually don't have a problem myself, but was doing some research about the various ways TouchPads have been (and thus could still possibly be) bricked, and what known-working fixes existed for those scenarios. I intend to start playing around with other OSes on my TouchPad and want to make sure I don't do anything stupid; if I know what can brick a TP, then perhaps I can make sure to avoid doing those things.
From what I can tell, between jcsullins' TPDebrick (for Qualcomm Downloader Mode problem) and this thread (complete NAND wipe and repartition), it seems almost impossible to permanently brick a TouchPad, which is impressive.
"Almost," though, being the key word. There are a troubling number of people in this thread and elsewhere (both here on XDA and other forums) whose TouchPad NANDs have become stuck in some sort of permanent read-only mode, where no writes to flash that they do actually stick. It's system-wide, too, not just in one OS. This is what is preventing people from completing the steps listed in the OP of this thread: they can't wipe the logical volumes on the flash because they can't write to the flash. And as far as I have been able to tell, nobody has found a fix yet, so the only way people who have had their TouchPads afflicted by this malady have gotten past this is if HP replaces their TouchPad for them. That's kinda scary. What's even more scary is that it seems like every story about a TouchPad stuck in read-only mode corresponds to an attempt at an Android install; I've not found anybody who only uses WebOS who has also suffered from this, which suggests that somehow some component of the Android port might be causing this.
One thread that I ran into, though, got my wheels turning, because it included a link to the datasheet for the SanDisk flash chip that is in the TouchPad (unfortunately, I cannot include the URL and properly give attribution to the author because this forum won't let me as a n00b include outside links; if you want it, PM me). It's called an iNAND (that's the trademark name), and it is an eMMC chip, which means it is not just a flash chip, but a flash chip with a built-in flash controller that essentially presents itself to the OS the way an SD card controller/slot would: the OS thinks it's talking to an SD/MMC card!
There seems to be a misconception both in the post I linked to as well as by people who have composed other posts that the flash chip in the TouchPad has failed in some way when this happens, and that either the chip simply broke in such a way that you can no longer write to it, or it has gone into a perpetual read-only mode as a fallback/"safe-mode" measure in response to some other failure or corruption. But if you read the datasheet, it's pretty clear at least that the chip is not designed to fall back to a read-only mode in response to corruption or breakage elsewhere. In section 2.9 (p. 11), "Enhanced Write Protection", it explains that the entire flash chip can be purposefully write-protected by changing some flags in the CSD ("Card Specific Data") register.
The CSD register is further laid out in detail on section 4.3.4 (p. 21), where it is revealed to be a 128-bit-wide register consisting mostly (as I found out by reading another document -- page 86 of the "SD Specifications, Part 1, Physical Layer Simplified Specification, Version 2.00", which again I am not allowed to link to...thank XDA) of read-only values and a couple of changeable values. Two of the changeable ones are bits 12 (TMP_WRITE_PROTECT) and 13 (PERM_WRITE_PROTECT). If either of these bits are set to '1', the entire flash chip is write-protected. But there is an important difference between the two bits: the former can be set and unset at-will (and the setting survives loss of power). The latter, once set, can NEVER be undone and will write-protect the chip permanently!
I suspect that those of you with TouchPads that will no longer accept writes made to the NAND have had one (or both) of those bits in the CSD of the SanDisk eMMC toggled to be 'on' (1) somehow. How, I know not. Perhaps there is a bug in the 2.6.35 kernel SD/MMC driver, or perhaps there is a bug in ClockworkMod for the TouchPad, or perhaps there is a bizarre bug in moboot itself. Or maybe there *is* an engineering defect in these iNAND chips that causes these bits to flip themselves under certain rare (or perhaps not-so-rare) conditions. I dunno. But if we are lucky, then only TMP_WRITE_PROTECT is getting set, which is something that theoretically CAN be undone.
There is a way to read the CSD from the command shell via sysfs, so if you can boot up your device and get to a shell somehow, we can try to check this. If this theory turns out to be correct, then we can perhaps try to work on a way to unset TMP_WRITE_PROTECT (or at least confirm that PERM_WRITE_PROTECT was set and so know with certainty that nothing more can be done). Execute this command:
You should see a 32-digit-long (16-byte/128-bit) hexadecimal number when you do this; this is the contents of the CSD register. My TouchPad's eMMC's CSD register, for example, looks like this (16GB TouchPad):
The part we are interested in is the 4th digit from the right; as you can see in my case, the last 4 digits are 4010, and the 4 is the digit of import. 4 is in fact what we want to see here. If TMP_WRITE_PROTECT is set, this will be a 5 instead of a 4. If PERM_WRITE_PROTECT is set, it will be a 6. If both TMP_WRITE_PROTECT and PERM_WRITE_PROTECT are set, it will be a 7. Given what the MMC CSD spec states, it is unlikely for that number to be anything other than something between 4 and 7 (bit 14, the Copy bit, is almost always set to 1 from the factory and is unchangeable once set to 1, and bit 15 will always be 0).
So those of you with still-bricked read-only TouchPads, if you could run this test and report back with the contents of your CSD, I suspect the results would be very educational!
-- Nathan
Hey all, new here. Apologies ahead of time for the length, but I hope it will end up being worth it for some of you. I actually don't have a problem myself, but was doing some research about the various ways TouchPads have been (and thus could still possibly be) bricked, and what known-working fixes existed for those scenarios. I intend to start playing around with other OSes on my TouchPad and want to make sure I don't do anything stupid; if I know what can brick a TP, then perhaps I can make sure to avoid doing those things.
From what I can tell, between jcsullins' TPDebrick (for Qualcomm Downloader Mode problem) and this thread (complete NAND wipe and repartition), it seems almost impossible to permanently brick a TouchPad, which is impressive.
"Almost," though, being the key word. There are a troubling number of people in this thread and elsewhere (both here on XDA and other forums) whose TouchPad NANDs have become stuck in some sort of permanent read-only mode, where no writes to flash that they do actually stick. It's system-wide, too, not just in one OS. This is what is preventing people from completing the steps listed in the OP of this thread: they can't wipe the logical volumes on the flash because they can't write to the flash. And as far as I have been able to tell, nobody has found a fix yet, so the only way people who have had their TouchPads afflicted by this malady have gotten past this is if HP replaces their TouchPad for them. That's kinda scary. What's even more scary is that it seems like every story about a TouchPad stuck in read-only mode corresponds to an attempt at an Android install; I've not found anybody who only uses WebOS who has also suffered from this, which suggests that somehow some component of the Android port might be causing this.
One thread that I ran into, though, got my wheels turning, because it included a link to the datasheet for the SanDisk flash chip that is in the TouchPad (unfortunately, I cannot include the URL and properly give attribution to the author because this forum won't let me as a n00b include outside links; if you want it, PM me). It's called an iNAND (that's the trademark name), and it is an eMMC chip, which means it is not just a flash chip, but a flash chip with a built-in flash controller that essentially presents itself to the OS the way an SD card controller/slot would: the OS thinks it's talking to an SD/MMC card!
There seems to be a misconception both in the post I linked to as well as by people who have composed other posts that the flash chip in the TouchPad has failed in some way when this happens, and that either the chip simply broke in such a way that you can no longer write to it, or it has gone into a perpetual read-only mode as a fallback/"safe-mode" measure in response to some other failure or corruption. But if you read the datasheet, it's pretty clear at least that the chip is not designed to fall back to a read-only mode in response to corruption or breakage elsewhere. In section 2.9 (p. 11), "Enhanced Write Protection", it explains that the entire flash chip can be purposefully write-protected by changing some flags in the CSD ("Card Specific Data") register.
The CSD register is further laid out in detail on section 4.3.4 (p. 21), where it is revealed to be a 128-bit-wide register consisting mostly (as I found out by reading another document -- page 86 of the "SD Specifications, Part 1, Physical Layer Simplified Specification, Version 2.00", which again I am not allowed to link to...thank XDA) of read-only values and a couple of changeable values. Two of the changeable ones are bits 12 (TMP_WRITE_PROTECT) and 13 (PERM_WRITE_PROTECT). If either of these bits are set to '1', the entire flash chip is write-protected. But there is an important difference between the two bits: the former can be set and unset at-will (and the setting survives loss of power). The latter, once set, can NEVER be undone and will write-protect the chip permanently!
I suspect that those of you with TouchPads that will no longer accept writes made to the NAND have had one (or both) of those bits in the CSD of the SanDisk eMMC toggled to be 'on' (1) somehow. How, I know not. Perhaps there is a bug in the 2.6.35 kernel SD/MMC driver, or perhaps there is a bug in ClockworkMod for the TouchPad, or perhaps there is a bizarre bug in moboot itself. Or maybe there *is* an engineering defect in these iNAND chips that causes these bits to flip themselves under certain rare (or perhaps not-so-rare) conditions. I dunno. But if we are lucky, then only TMP_WRITE_PROTECT is getting set, which is something that theoretically CAN be undone.
There is a way to read the CSD from the command shell via sysfs, so if you can boot up your device and get to a shell somehow, we can try to check this. If this theory turns out to be correct, then we can perhaps try to work on a way to unset TMP_WRITE_PROTECT (or at least confirm that PERM_WRITE_PROTECT was set and so know with certainty that nothing more can be done). Execute this command:
Code:
cat /sys/class/mmc_host/mmc0/mmc0:0001/csd
Code:
d00f00320f5903ffffffffff92404010So those of you with still-bricked read-only TouchPads, if you could run this test and report back with the contents of your CSD, I suspect the results would be very educational!
-- Nathan
Interesting theory. I dusted off my TP, ran the command and got back the same code you posted. What's next?
Hey there. So your CSD register contents match mine exactly? What if you were to post the entire thing here anyway just in case there is a subtle difference you might be missing?
I don't see any prior posts from you on XDA, so I'm not sure what the specific symptoms are with your TouchPad. Do they match those described by the other people I was addressing in my response? (This thread covers many different modes of TP failure.) Specifically...
- When you run either WebOS or Android, nothing you do (settings changes, downloads, new app installs, local document saves, etc.) is "remembered" after a reboot?
- When you attempt to wipe and recreate all of the logical volumes as documented at the beginning of this thread, you issue the "lvm.static vgremove store" command, followed by "lvm.static vgcreate -s 8M store /dev/mmcblk0p14", and the second command returns to you this error?: "/dev/store: already exists in filesystem", and "New volume group name 'store' is invalid"
-- Nathan
Yes, I'm a long time reader but first time poster.
But the issue that I am encountering with my TP is exactly what you describe above. When attempting to remove and recreate the volume store, it does error that the store already exists.
I ran the command you provided from the terminal app in CM9. It returned the following value:
d00f00320f5903ffffffffff92404010
---------- Post added at 09:52 AM ---------- Previous post was at 09:45 AM ----------
Yes, if I make any changes in CM9 or webOS then reboot the TP, it does not save any of the changes made.
Well, then we might be back to the drawing board here. It doesn't appear that the whole-flash write protect has been engaged. There *is* apparently another way that the documentation describes, though, to write-protect only certain parts of the flash chip. This would be accomplished by manipulating certain parts of the EXT_CSD register. Unfortunately, it does not look like EXT_CSD is exposed by sysfs. I will have to do a little bit more reading up on this.
One thing you could try to do to see if indeed the flash chip is write-protecting itself would be to attempt to blank out the first sector of data on it (boot sector?). If you do this and it is successful, it will put the TouchPad into QHUSB-DLOAD/Qualcomm Download Mode, at which point you would run TPDebrick on it. This will not have any effect if the flash chip is indeed write-protected in some way at the hardware level of things. At this point, you probably don't have anything to lose by trying it: perform the bootup procedure described at the beginning of this thread in the OP, and then once you get to the point where you are about to start entering in the various lvm.static commands, run this single command instead (WARNING: I have not vetted this procedure myself! This could brick your TouchPad! I am not responsible if it does!):
Code:
dd if=/dev/zero of=/dev/mmcblk0 bs=512 count=1You're mistaken. Most UNIX-like systems will mount various volumes read-only until after filesystem integrity has been determined, at which point they will be re-mounted read-write. So filesystem damage that is not automatically correctable (e.g., a fsck triggered during boot cannot fix the volume) would cause the re-mount simply to not occur, and the system would also likely boot straight into single-user mode if the affected volume is the boot volume. But this all happens at the *volume* (partition/filesystem) level, not at the physical *drive* level; no kind of drive "locking" occurs. It would be absurd for an OS to do this, or for the hardware to enable it to do so. Think about a multiboot PC: hypothesize that Linux filesystem corruption occurs, so Linux locks the drive, thus preventing you from using the copy of Windows that is on there, even though it is in perfectly good shape? What a mess that would be.
-- Nathan
You've gotta consider this though: Most TouchPads this issue occurs on ARE multi-boot and it does affect both operating systems. Maybe eMMCs are handled differently. Hell, maybe it's the controller screwing everything up. I'd make a more detailed reply right now but I'm going underground
That's actually kinda my point: it's not "the OS" doing it because there is > 1 OS involved here.
In an eMMC design, the controller is part of the flash chip.
In a multi-OS system, with all OSes being unable to write to the drive, the write-protect is obviously happening in hardware, not software. Heck, when you follow the procedure in the OP, you aren't even booting one of the OSes that resides on the flash: you're basically booting a recovery image via USB, and you STILL can't write to the drive from that environment.
The only documented way of write-protecting an MMC-class flash device (besides SD cards with their write-protect slide switch) is via manipulating writable bits in the CSD and EXT_CSD registers. And if an OS is touching those things, that's not a feature: that's a bug. Unless the engineers were high when they made that decision, there's no way that was intentional.
-- Nathan
Yep.. I did that once... sucked.. great guide! I was lucky.. I have 2 touchpads and I got to look at the stock touchpad to look at the partition layout. Great guide! Now I can not feel the need to keep it so stock.
I think my son inadvertently installed the nightly build downloaded by goomanager. He doesn't recall what he did. But it can't get beyond the cyanogenmod face logo. I can boot into WebOS. But the file system is read locked. I can make changes to the sd card when connected to the PC. As soon as I disconnect, it reverts back. I tried formatting the sd card. No go. I'm afraid I have a "safe mode" TP now
I was able to install Preware and Tailor once using WebOS Quick Install. But I'm unable to repeat that. If I were to go into WebOS recovery and run Novaterm, can you tell me the equivalent command to run from Novaterm?
Thank You , Thank You....
ok, I have this exact problem...and I have also tried every damn thing on the net for the last 6 months trying to get my sd to work right again and write. So let get down to the brass tacks...
I just ran that code line through my terminal and received the exact same code you have....
Code:
d00f00320f5903ffffffffff92404010
so I also have a 4....let me know what else I can do to help move this along!
ok, I have this exact problem...and I have also tried every damn thing on the net for the last 6 months trying to get my sd to work right again and write. So let get down to the brass tacks...
I just ran that code line through my terminal and received the exact same code you have....
Code:
d00f00320f5903ffffffffff92404010
so I also have a 4....let me know what else I can do to help move this along!
NIRA that is some impressive research. In motor controls there are also soft and hard lock outs. From what I have seen my tp do, I can't prove it but I swear low charge will put the tp into a soft lockout situation, so before any fixes are tried at least a twelve hour charge time on the stock if not larger gauge chord is a must.
Second, I have trashed my pad numerous times but I can't get to the link I want to share so I will try to get it tomorrow. I think it may help the two previous posters.
Sent from my Galaxy Nexus using Tapatalk 2
Second, I have trashed my pad numerous times but I can't get to the link I want to share so I will try to get it tomorrow. I think it may help the two previous posters.
Sent from my Galaxy Nexus using Tapatalk 2
Thanx for ur help
its working...
but 1 doubt
after the 3rd step in novaterm it is asking like this
Do you really want to remove volume group "store" containing 11 logical volumes? [y/n]
what should I prefer, yes or no??
---------- Post added at 11:58 PM ---------- Previous post was at 11:28 PM ----------
Thanx for ur help
its working...
but i doubt
after the 3rd step in novaterm it is asking like this
Do you really want to reove volume group "store" containing 11 logical volumes? [y/n]
what should I prefer yes or no??
its working...
but 1 doubt
after the 3rd step in novaterm it is asking like this
Do you really want to remove volume group "store" containing 11 logical volumes? [y/n]
what should I prefer, yes or no??
---------- Post added at 11:58 PM ---------- Previous post was at 11:28 PM ----------
Thanx for ur help
its working...
but i doubt
after the 3rd step in novaterm it is asking like this
Do you really want to reove volume group "store" containing 11 logical volumes? [y/n]
what should I prefer yes or no??
Last edited:
I say yes for all of them after all your rebuilding the system
sent from the bathroom
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
88This is for all those people who want to start over. I made the mistake of using webOS Doctor without removing the Android and Linux partitions. That left me with a deer turd for an HP TouchPad. So after about 2 hours of slaving, I figured out what to do
I. What you need
Novacom - Click
Novaterm - Click (or found in C:\Program Files\Palm, Inc\terminal. Run novaterm.bat)
Recovery uImage - Click
WebOS Doctor 3.0.0 - Click
WebOS Doctor 3.0.4 (optional) - Click
II. What to do
1) Install Novacom and extract Novaterm.
2) Open a command prompt and navigate to your Palm, Inc folder (usually \Program Files\Palm, Inc)
3) Move the recovery uImage to the Palm, Inc folder.
4) Boot your Touchpad into recovery (Power + Volume Up from power off)
5) In that command prompt, run ( novacom boot mem:// < nova-installer-image-topaz.uImage ) (without the parenthesis)
6) Once run, all you'll see on the Touchpad is the HP logo. This is good. Now open Novaterm and hit Connect
7) If you see a prompt that says something like "root@webOS device" this is good, now run these commands IN ORDER and these commands are CASE SENSITIVE
(For 32GB Touchpads only)
(16GB Touchpads)
8) When done, reboot the Touchpad into recovery (Power + Center/Home until screen off, then Power + Volume Up)
9) Run webOS Doctor 3.0.0 (This is to ensure a repartitioning and no other version will work at this point)
Branch 1) You can stop here to have 3.0.0 as your webOS version. You've just completed a downgrade that was before thought impossible.
Branch 2) If you want webOS 3.0.4, continue on.
10) When webOS Doctor is complete, hold down Power and Center, and when the screen turns off, immediately hold Power and Volume Up.
11) You'll see the USB icon again, just run webOS Doctor 3.0.4 and you're done.
Have fun.
_____________________________
For those having problems with novaterm:
For those having problems with Java:
7This information should be added to the OP as I was going through hell trying to get novaterm to work. I tried every pointer I could find but no matter what I did, any key I pressed on the keyboard would bring this error up "arithmetic overflow error." Then I finally found something that worked, if anything I think the novaterm step should be removed and just put this down as this seems to for sure work.
After doing the novacom mem...... command
Type novacom -t open tty://
You will stay in the command prompt but will now see the root terminal line for the Touchpad, and you can continue typing the rest of the commands in to reset it. This worked perfectly for me, in case anyone was running into a similar problem to me.
Thanks for the detailed instructions though OP, I've been really wanting to fully restore my TP and start from scratch, it's gotten quite cluttered over the time I've had it and it's been bugging me.
P.S. - I didn't stop to think whether the OP instructions would work with the method I used, since they only have you install novacom and novaterm, so I'm guessing that the TTY option may not work. Well if that is the case, then just install the latest Java Development Kit for your version of Windows, as well as the latest HP webOS SDK/PDK for your version of Windows, which can both be found easily by searching for the corresponding website. Hopefully this helps someone.6Read-only flash / unable to delete 'store'
Hey all, new here. Apologies ahead of time for the length, but I hope it will end up being worth it for some of you. I actually don't have a problem myself, but was doing some research about the various ways TouchPads have been (and thus could still possibly be) bricked, and what known-working fixes existed for those scenarios. I intend to start playing around with other OSes on my TouchPad and want to make sure I don't do anything stupid; if I know what can brick a TP, then perhaps I can make sure to avoid doing those things.
From what I can tell, between jcsullins' TPDebrick (for Qualcomm Downloader Mode problem) and this thread (complete NAND wipe and repartition), it seems almost impossible to permanently brick a TouchPad, which is impressive.
"Almost," though, being the key word. There are a troubling number of people in this thread and elsewhere (both here on XDA and other forums) whose TouchPad NANDs have become stuck in some sort of permanent read-only mode, where no writes to flash that they do actually stick. It's system-wide, too, not just in one OS. This is what is preventing people from completing the steps listed in the OP of this thread: they can't wipe the logical volumes on the flash because they can't write to the flash. And as far as I have been able to tell, nobody has found a fix yet, so the only way people who have had their TouchPads afflicted by this malady have gotten past this is if HP replaces their TouchPad for them. That's kinda scary. What's even more scary is that it seems like every story about a TouchPad stuck in read-only mode corresponds to an attempt at an Android install; I've not found anybody who only uses WebOS who has also suffered from this, which suggests that somehow some component of the Android port might be causing this.
One thread that I ran into, though, got my wheels turning, because it included a link to the datasheet for the SanDisk flash chip that is in the TouchPad (unfortunately, I cannot include the URL and properly give attribution to the author because this forum won't let me as a n00b include outside links; if you want it, PM me). It's called an iNAND (that's the trademark name), and it is an eMMC chip, which means it is not just a flash chip, but a flash chip with a built-in flash controller that essentially presents itself to the OS the way an SD card controller/slot would: the OS thinks it's talking to an SD/MMC card!
There seems to be a misconception both in the post I linked to as well as by people who have composed other posts that the flash chip in the TouchPad has failed in some way when this happens, and that either the chip simply broke in such a way that you can no longer write to it, or it has gone into a perpetual read-only mode as a fallback/"safe-mode" measure in response to some other failure or corruption. But if you read the datasheet, it's pretty clear at least that the chip is not designed to fall back to a read-only mode in response to corruption or breakage elsewhere. In section 2.9 (p. 11), "Enhanced Write Protection", it explains that the entire flash chip can be purposefully write-protected by changing some flags in the CSD ("Card Specific Data") register.
The CSD register is further laid out in detail on section 4.3.4 (p. 21), where it is revealed to be a 128-bit-wide register consisting mostly (as I found out by reading another document -- page 86 of the "SD Specifications, Part 1, Physical Layer Simplified Specification, Version 2.00", which again I am not allowed to link to...thank XDA) of read-only values and a couple of changeable values. Two of the changeable ones are bits 12 (TMP_WRITE_PROTECT) and 13 (PERM_WRITE_PROTECT). If either of these bits are set to '1', the entire flash chip is write-protected. But there is an important difference between the two bits: the former can be set and unset at-will (and the setting survives loss of power). The latter, once set, can NEVER be undone and will write-protect the chip permanently!
I suspect that those of you with TouchPads that will no longer accept writes made to the NAND have had one (or both) of those bits in the CSD of the SanDisk eMMC toggled to be 'on' (1) somehow. How, I know not. Perhaps there is a bug in the 2.6.35 kernel SD/MMC driver, or perhaps there is a bug in ClockworkMod for the TouchPad, or perhaps there is a bizarre bug in moboot itself. Or maybe there *is* an engineering defect in these iNAND chips that causes these bits to flip themselves under certain rare (or perhaps not-so-rare) conditions. I dunno. But if we are lucky, then only TMP_WRITE_PROTECT is getting set, which is something that theoretically CAN be undone.
There is a way to read the CSD from the command shell via sysfs, so if you can boot up your device and get to a shell somehow, we can try to check this. If this theory turns out to be correct, then we can perhaps try to work on a way to unset TMP_WRITE_PROTECT (or at least confirm that PERM_WRITE_PROTECT was set and so know with certainty that nothing more can be done). Execute this command:
You should see a 32-digit-long (16-byte/128-bit) hexadecimal number when you do this; this is the contents of the CSD register. My TouchPad's eMMC's CSD register, for example, looks like this (16GB TouchPad):Code:cat /sys/class/mmc_host/mmc0/mmc0:0001/csd
The part we are interested in is the 4th digit from the right; as you can see in my case, the last 4 digits are 4010, and the 4 is the digit of import. 4 is in fact what we want to see here. If TMP_WRITE_PROTECT is set, this will be a 5 instead of a 4. If PERM_WRITE_PROTECT is set, it will be a 6. If both TMP_WRITE_PROTECT and PERM_WRITE_PROTECT are set, it will be a 7. Given what the MMC CSD spec states, it is unlikely for that number to be anything other than something between 4 and 7 (bit 14, the Copy bit, is almost always set to 1 from the factory and is unchangeable once set to 1, and bit 15 will always be 0).Code:d00f00320f5903ffffffffff92404010
So those of you with still-bricked read-only TouchPads, if you could run this test and report back with the contents of your CSD, I suspect the results would be very educational!
-- Nathan2Sure.
Here you have :
Code:lvm.static lvdisplay --- Logical volume --- LV Name /dev/store/root VG Name store LV UUID Aq5Mpj-p1ou-AMwd-j0YJ-1ytK-nHVn-NlOGUR LV Write Access read/write LV Status available # open 1 LV Size 568.00 MB Current LE 71 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Persistent major 254 Persistent minor 0 Block device 254:0 --- Logical volume --- LV Name /dev/store/var VG Name store LV UUID 1OQAZu-Zx0P-fK6M-xdYj-8T0z-CoDw-2pwy00 LV Write Access read/write LV Status available # open 1 LV Size 64.00 MB Current LE 8 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Persistent major 254 Persistent minor 1 Block device 254:1 --- Logical volume --- LV Name /dev/store/update VG Name store LV UUID 9Cpv99-Al2S-eCWp-ioAi-AGMS-T10i-qba3pn LV Write Access read/write LV Status available # open 0 LV Size 16.00 MB Current LE 2 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Persistent major 254 Persistent minor 2 Block device 254:2 --- Logical volume --- LV Name /dev/store/log VG Name store LV UUID jaNcqX-uRU7-uwWi-yvZE-KHiN-K5RX-mh3jkJ LV Write Access read/write LV Status available # open 1 LV Size 24.00 MB Current LE 3 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Persistent major 254 Persistent minor 3 Block device 254:3 --- Logical volume --- LV Name /dev/store/mojodb VG Name store LV UUID 7nT2OX-nlbV-U6HQ-UrVi-Pja6-nDwP-BpHsTR LV Write Access read/write LV Status available # open 1 LV Size 256.00 MB Current LE 32 Segments 2 Allocation inherit Read ahead sectors auto - currently set to 256 Persistent major 254 Persistent minor 4 Block device 254:4 --- Logical volume --- LV Name /dev/store/filecache VG Name store LV UUID oH0jt0-AcIO-pFTF-3wD7-cYC2-W88I-H0UqPj LV Write Access read/write LV Status available # open 1 LV Size 136.00 MB Current LE 17 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Persistent major 254 Persistent minor 5 Block device 254:5 --- Logical volume --- LV Name /dev/store/media VG Name store LV UUID NWNspe-aKe5-glCM-c0mb-15sM-32Mu-64e8jx LV Write Access read/write LV Status available # open 1 LV Size 12.64 GB Current LE 1618 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Persistent major 254 Persistent minor 6 Block device 254:6 --- Logical volume --- LV Name /dev/store/swap VG Name store LV UUID TOq7Y8-2XCB-diKE-3D7s-3pIp-Ksbl-4LbZP0 LV Write Access read/write LV Status available # open 1 LV Size 512.00 MB Current LE 64 Segments 2 Allocation inherit Read ahead sectors auto - currently set to 256 Persistent major 254 Persistent minor 7 Block device 254:72
Thank you. I was able to make the correct commands for 16GB Touchpads.
