yashsingh1/xdaforums huggingface dataset:
[G2 and Desire Z Android Development] HamNCheese:
C'mon people.... This has been proven and confirmed by many people (including myself.) It is not cache. It is not a ramdisk. You are filling a block device (not RAM memory.) The OS will glitch eventually, causing a soft reboot (and ext3 failures.) I pasted demonstrated this on IRC last night...

We need to get away from the ramdisk vs overlay vs wipe discussion, and get back to the purpose of this thread - making real progress.
[G2 and Desire Z Android Development] damnoregonian:
you have no idea what you're talking about, neither does lbcoder.

look up UBC. it takes up no memory, because it only uses non-allocated memory. as memory is allocated, UBC blocks are flushed and that's when changes start reverting.

unfortunately, the cache vs. overlay is a very important question with regard to how progress goes forward.

now, if you have any real proof that there is an overlay, i'd love to see it, as it would point me in another direction. however, filling up unallocated ram with UBC blocks, forcing it to flush them all and causing bad changes to the filesystem driver as its state suddenly changes is more evidence of there being a cache than an overlay :)

now, back to business.

dump of the eMMC's CSD registers:

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10 00 CB 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 01 EC 00 00 03 00 01 00 00 00 04 1F 01 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 05 00 02 00 07 00 02 01 00 00 00 00 00 0A 0A 0A 0A 0A 0A 00 00 40 43 00 00 11 00 07 08 04 01 01 04 06 08 00 07 96 96 15 02 00 00 00 00 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 01 00 00 00 00 00 00 00

anyone have docs so i can figure out what the fields are?
[G2 and Desire Z Android Development] HamNCheese:
It's not in the linux cache. I can write 200MB+ to /system and free shows very little change. The block device appears to accept the writes, then later reverts behind the kernel's back. This points to hardware taking action, rather than linux.

You can reproduce this yourself, fill /system and memory is largely unaffected.
[G2 and Desire Z Android Development] damnoregonian:
free would show 0 change whatsoever, again, i will redirect you to the linux UBC.

please don't post with an informative attitude if you're this in the dark with regard to the inner workings of the OS.
[G2 and Desire Z Android Development] bentglasstube:
# /data/local/tmp/busybox free
/data/local/tmp/busybox free
total used free shared buffers
Mem: 379832 250400 129432 0 17712
Swap: 0 0 0
Total: 379832 250400 129432
# dd if=/dev/zero of=/system/fill
dd if=/dev/zero of=/system/fill
/system/fill: write error: No space left on device
441257+0 records in
441256+0 records out
225923072 bytes transferred in 12.606 secs (17921868 bytes/sec)
# /data/local/tmp/busybox free
/data/local/tmp/busybox free
total used free shared buffers
Mem: 379832 376360 3472 0 17688
Swap: 0 0 0
Total: 379832 376360 3472

It looks like a cache to me.
[G2 and Desire Z Android Development] damnoregonian:
image CRCs (as seen by hboot):

hboot: 0xa2610f94

boot: 0x673d0cdc

recovery: 0xa0ddafe2

system: 0xcc3a37c1
[G2 and Desire Z Android Development] HamNCheese:
oh, for the love of god.....

Stop posting this garbage, none of these blogger idiots know what they are talking about.

Constant re-flashing would be a disaster, even with the best wear-leveling possible. Get root on your device and draw your own conclusions.

Ask yourself: What the F does DSLReports know about rooting android....
[G2 and Desire Z Android Development] damnoregonian:
excellent :)

this tells us something great.

it's not UBC, it's an actual cache added by HTC.
[G2 and Desire Z Android Development] damnoregonian:
it's better as i posted earlier...

dslreports is just parroting what some blogger wrote who was parroting this very thread before people started figuring out what was really going on.
[G2 and Desire Z Android Development] maubig:
They're working on this now in the IRC

Here's some doc...

omapworld.com/iNAND_e_MMC_4_41_IF_data_sheet_v1_0%5B1%5D.pdf
[G2 and Desire Z Android Development] HamNCheese:
[edit]

Post your "facts" in IRC so we can all take a look. This thread is meaningless at this point.
[G2 and Desire Z Android Development] Corylulu:
Edit: nvm sorry
[G2 and Desire Z Android Development] damnoregonian:
na, i don't use IRC, sorry.

you also need to keep in mind that the "kernel" is not this massive sentient entity.

the filesystem keeps a cache, the block device uses the UBC, and of course any other drivers are free to implement any caches they would like to use as well.

you have no evidence that there is anything happening on the hardware level. you have evidence that you don't understand and are interpreting - poorly.
[G2 and Desire Z Android Development] bentglasstube:
I got a different system - 0xf710906d
[G2 and Desire Z Android Development] davr:
Too lazy to read to see if someone decoded it, here's my results:

http://davr.org/p/XgcG8m92.html
[G2 and Desire Z Android Development] damnoregonian:
have some of your irc buddies give me a working link to the docs for the eMMC chip.

i've posted a dump of the CSD registers, it will solve the debate as to whether any overlay or write protection is done, period.
[G2 and Desire Z Android Development] davr:
Did you dump both the CSD and the EXT_CSD? Or just one of them? The dump I was looking at was only EXT_CSD, and there are a few more write protect bits in the CSD, according to the datasheet linked above (did you see it?). Not 100% sure it's the correct datasheet, don't have a way to verify that.
[G2 and Desire Z Android Development] vi5in:
So here is the datasheet for the iNand:

http://omapworld.com/iNAND_e_MMC_4_41_IF_data_sheet_v1_0[1].pdf

Earlier on someone had mentioned the CSD register:

The CSD register is 16-bits wide (128 bits). The bits that might matter are:

WP_GRP_SIZE [36:32] Write protect group size 11111b 5
WP_GRP_ENABLE [31:31] Write protect group enable 1b 1
CONTENT_PROT_APP [16:16] Content protection application 0b 1
COPY [14:14] Copy flag (OTP) 1b 1
PERM_WRITE_PROTECT [13:13] Permanent write protection 0b 1
TMP_WRITE_PROTECT [12:12] Temporary write protection 0b 1

So a possible attack vector... would it be possible to write a kernel module or driver than can clear the write-protect bits? Then you can load up this driver and get root to make the changes persistent.
[G2 and Desire Z Android Development] The_Forastero:
It made me laugh to see the dslreports using the world "jailbreak"... omg... when the tittle of this very thread they're mentioning says "root"!

Anyhoo, this reminds me of how Deep Freeze works, but just with an unfrozen partition.
[G2 and Desire Z Android Development] vi5in:
Are there existing linux kernel-modules that do this sort of thing? Work with eMMC's that is?
[G2 and Desire Z Android Development] damnoregonian:
just the ext_csd, the csd didn't look like it had anything really interesting.

the ext_csd has the address for the wp tables
[G2 and Desire Z Android Development] vi5in:
Could you do a CSD dump as well? The bits and bit-fields in my previous post seem interesting and I'm curious to see what their values are.

How are you dumping the values of these registers? Apologies if you've already stated it before. I think I may have missed it.

I looked at mmc.h in the linux kernel source and this looks interesting (if the kernel module route is valid):

#define MMC_SEND_EXT_CSD 8 /* adtc R1 */
#define MMC_SEND_CSD 9 /* ac [31:16] RCA R2 */

/* class 6 */
#define MMC_SET_WRITE_PROT 28 /* ac [31:0] data addr R1b */
#define MMC_CLR_WRITE_PROT 29 /* ac [31:0] data addr R1b */
#define MMC_SEND_WRITE_PROT 30 /* adtc [31:0] wpdata addr R1 */
[G2 and Desire Z Android Development] bentglasstube:
I got the ext_csd dump by running "fastboot oem get_ext_csd_emmc"
[G2 and Desire Z Android Development] krayshunist:
You can try taking a look at the source code for the U3 tool here: http: // sourceforge.net / projects / u3-tool / files/

I really wish I wasn't gone on business and had my G2 and desktop here with me :-/
[G2 and Desire Z Android Development] bentglasstube:
# cat /sys/bus/mmc/devices/mmc0:*/csd
cat /sys/bus/mmc/devices/mmc0:*/csd
d00f00320f5903fffffffdff924040c8
[G2 and Desire Z Android Development] davr:
converting to binary gives

11010000 00001111 00000000 00110010 00001111 01011001 00000011 11111111 11111111 11111111 11111101 11111111 10010010 01000000 01000000 11001000

going by the datasheet:

PERM_WRITE_PROTECT = 0

TMP_WRITE_PROTECT = 0

CONTENT_PROT_APP = 0
[G2 and Desire Z Android Development] damnoregonian:
d00f00320f5903fffffffdff924040c8

ah sweet - you already got it
[G2 and Desire Z Android Development] vi5in:
FEDC BA98 7654 3210
-------------------
7| 1101 0000 0000 1111
6| 0000 0000 0011 0010
5| 0000 1111 0101 1001
4| 0000 0011 1111 1111
3| 1111 1111 1111 1111
2| 1111 1101 1111 1111
1| 1001 0010 0100 0000
0| 0100 0000 1100 1000

Based on the values you provided, it seems like both PERM_WRITE_PROTECT and TMP_WRITE_PROTECT are set to 0. COPY is set to 1 and WP_GRP_SIZE and WP_GRP_ENABLE are both set to 11111 and 1. These look like the default values from the data sheet.

So... what does this mean? Are we looking at the wrong MMC? Or is it using some other mechanism?
[G2 and Desire Z Android Development] damnoregonian:
no, i think tmp_write_protect and perm write protect are total chip protection.

the grp ones refer to the specific portions that are wp
[G2 and Desire Z Android Development] vi5in:
Haha, was just going to write that. I looked at the data-sheet a bit more. So ideally if we simply set WP_GRP_ENABLE to 0, it should ignore the value in WP_GRP_SIZE? Or we should just set all those bits to 0.
[G2 and Desire Z Android Development] damnoregonian:
according to the physical layer mmc specs, if you turn off WP_GRP_ENABLE it disables write protect groups, soooo.... we just need something to push a new csd.
[G2 and Desire Z Android Development] vi5in:
Is there a simple way to write to the registers? Or would you have to write a kernel module/driver?

When I worked at intel I did some driver development. We had a special layer that let you directly cat to the exposed registers... but I doubt it is so easy here...

Unless...

Can you try echoing the following value to csd:

d00f00320f5903fffffffde0124040c8

Then make a change in system, reboot and see if it persists. I may be barking up the wrong tree... but maybe it's worth a short?

edit: I'm retarded - I put in the wrong value... I've updated it
[G2 and Desire Z Android Development] damnoregonian:
and, one of the symbols exported by the kernel is:

wait for it...

mmc_send_csd

if this works, this is gonna be cake.
[G2 and Desire Z Android Development] phoenix79:
New here so be forgiving, but did anyone notice this line?

162 01 -- RST_n_FUNCTION [162] H/W reset function 0h
[G2 and Desire Z Android Development] damnoregonian:
kernel module.

it'd be near impossible to write directly to anything regarding the card, however, modules global symbols (including functions) are in the kernel's symbol table, so you can call functions defined in the mmc module from within your module.
[G2 and Desire Z Android Development] damnoregonian:
already tried echoing. csd sys node is ro.
[G2 and Desire Z Android Development] vi5in:
Cool. From what you said, it looks like the symbol is exported... so if we were able to send this value to the CSD... :).

I think it might be worth a short. Will see if I can do this over the weekend. It has been a LONG time since I wrote a kernel driver. I don't remember much at all... very rusty.
[G2 and Desire Z Android Development] vi5in:
Pretty much what I expected. Another thing to think about though. If we are able to disable this (and it turns out that THIS is what we want to disable), isn't there the other problem of the image being restored while the phone is running?

Presumably this might not be a problem if the write-protect area is turned off... but I wonder how that operation would be affected.
[G2 and Desire Z Android Development] krayshunist:
Assuming you turn off the correct write protection, you should be able to flash a new recovery image and have it stick. Someone please correct me if I'm wrong.
[G2 and Desire Z Android Development] slayerdork:
Has anyone tried this?

fastboot oem mmc_send_csd d00f00320f5903fffffffde0124040c8

Maybe...lol?
[G2 and Desire Z Android Development] damnoregonian:
that's the scary part.

the real problem, is what if you turn it off, blocks start actually being committed, and you end up with a totally effed filesystem because half the writes were already discarded...

i'd want to have a recovery image to flash or a working hboot flashable base image in case things went wrong.

though in reality, the phone has enough memory to store quite a few writes before it starts flushing, so you might be just fine when you finally do a real sync, and yaffs is very hard to break, it has very few (none maybe?) disk structures that aren't simply inodes.
[G2 and Desire Z Android Development] bentglasstube:
INFO[ERR] Command error !!!
OKAY [ 0.011s]
finished. total time: 0.011s
[G2 and Desire Z Android Development] slayerdork:
I did a little searching for mmc_send_csd, this is what I found, so, maybe it needs the correct parameters?

274 int mmc_send_csd(struct mmc_card *card, u32 *csd)
275 {
276 int ret, i;
277
278 if (!mmc_host_is_spi(card->host))
279 return mmc_send_cxd_native(card->host, card->rca << 16,
280 csd, MMC_SEND_CSD);
281
282 ret = mmc_send_cxd_data(card, card->host, MMC_SEND_CSD, csd, 16);
283 if (ret)
284 return ret;
285
286 for (i = 0;i < 4;i++)
287 csd[i] = be32_to_cpu(csd[i]);
288
289 return 0;
290 }
[G2 and Desire Z Android Development] vi5in:
Guys, it was my bad earlier.

The correct value is:

d00f00320f5903fffffffde0124040c8

I edited my post, but not before it was quoted.

Please do verify the value. Bits 36:32 should be 00000b and bit 31 should also be 0b.
[G2 and Desire Z Android Development] damnoregonian:
i recommend everyone refrain from playing with the send_wp_info fastboot command. it has a bracket [CMD31?]....

i found a proposed addendum to the mmc standard defining CMD31 (currently reserved) as a way to permanently write protect a group.

CMD31	Ac	[31:0] data address	R1b	SET_PERM_WRITE_PROT	If the card has write protection features, this command sets the permanent write protection bit of the addressed group. The properties of the write protection are coded in the card specific data (WP_GRP_SIZE)

makes my stomach sink thinking of some of the stupid tests i did with it....
[G2 and Desire Z Android Development] vi5in:
I didn't get the gist of your comment though -- why is it recommended not to use it?

I don't think you could have done any real damage; looks like that node is RO like you said!
[G2 and Desire Z Android Development] damnoregonian:
no, not in linux.

emmc_set_wp_info (i think it was called that) is a fastboot command issued at the bootloader (that myself and a few other people were playing with)
[G2 and Desire Z Android Development] craisis:
Check JESD84-A441

You guys should go read the spec at (URL below, see EDIT).

EDIT: Apparently I can't post links yet... : goo<dot>gl/iAWY

The WP_GROUP_SIZE and WP_GROUP_ENABLE is CSD are read only values.

I think we're more interested in are BOOT_WP and USER_WP in the EXT_CSD. See section 8.4 of the above documentation.

Also, we should make sure we don't make it permanently read only, the device supports write once bits in the register, so it's impossible to undo. Even with chip resets/etc.

Below is the spec on the relevant bits:

and
[G2 and Desire Z Android Development] damnoregonian:
well that's really depressing.

the spec i got didn't specify rw or ro.

well, if the BOOT_WP and USER_WP flags are what we want to attack, the kernel also provides mmc_send_ext_csd.

though i really don't think those do what you think they do.

whatever mechanism we're going after has to support groups, or areas because not all of the flash is write protected.

it may be we have to send the CLR_WRITE_PROT command to clear out the write protect groups after finding a way to list them....

but the kernel doesn't seem to have any exports for handling that.
[G2 and Desire Z Android Development] damnoregonian:
0000000000000001010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a0000000000000000021596960700080604010104080700110000434000000a0a0a0a0a0a000000000001020007000200050000000000000100000000000000000000000000000000011f040000000100030000ec01010000000000000000000000000000cb0010000000000000000000000000000000000000000000000000000000000000000000000000000000000000010101000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

ext_csd from while the phone is running (already booted)

i'm assuming it's different from what we got from fastboot.

someone wanna see if USER_WP and BOOT_WP are enabled in that?
[G2 and Desire Z Android Development] VValdo:
http://press.t-mobile.com/articles/t-mobile-G2-code-level-modifications
[G2 and Desire Z Android Development] grankin01:
Fix it till its broken. Then fix it till its better. :)
[G2 and Desire Z Android Development] f231f:
Sounds like they are throwing HTC under the bus
[G2 and Desire Z Android Development] arich:
Hmm so does it have the same unfortunate side-effect on the Desire Z?
[G2 and Desire Z Android Development] TFJ4:
I guarantee you that "fastboot oem unlock" didn't result in many bricked devices (Can't flash SPLS/Splashes). HTC also didn't have to take away 2GB of space to do it.
[G2 and Desire Z Android Development] sino8r:
This bs is not gonna stop us. I don't understand the point in it. I mean how many devices do they have to fix because someone bricked it. Very few, I would imagine. I hate **** like this. They are placing any blame on HTC when it was clearly tmobile's idea.

It also makes me sick and thinking of tmobile laughing at us when we stuck with a bloated G1. Stupid thought, I know but it just makes me so angry.
[G2 and Desire Z Android Development] vabovyan:
Try to mount as ext2

Can anybody try to mount system partition as ext2? And try t write to it.

mount -o rw,remount -t ext2 /dev/block/mmcblk0p25 /system

It is also possible that HTC modified ext3 module in kernel so all writes are redirected to cache. I am not sure that mounting it as ext2 will work though...
[G2 and Desire Z Android Development] damnoregonian:
i'm beginning to think that there's nothing shady going on with the caching, it's just that either the device or the mmc driver isn't returning an error on the write. since writethrough caching is enabled, we see that cache.

(dd or even a cat into the block device won't return an error either)
[G2 and Desire Z Android Development] xile6:
HTC did have to replace alot of phones because of people bricking them so it makes sense for them to up there game and try to stop people some messing them up. But were there is a will there is a way and we will have root one day.
[G2 and Desire Z Android Development] mark925:
If that is the case then the G2 won't be the last phone they do this with.....
[G2 and Desire Z Android Development] sino8r:
Yeah, I know... its just a bit disheartening, ya know? Got any more encouraging rhymes?
[G2 and Desire Z Android Development] craisis:
mmc command

Ok, after further reading in the specs documents (mentioned above). It appears that we're going to need to issue a "CMD29" with the address of write group we want to unlock.

See section 7.10.4 of the JEDEC 84-A441.
[G2 and Desire Z Android Development] sino8r:
Yeah, we get that but it HAS TO BE us who will be first to deal and develop this new root method. Why couldn't have started with the stupid mytouch hd, lol?!
[G2 and Desire Z Android Development] amwilliams9:
disregard prior post. I'm to new to add useful input.
[G2 and Desire Z Android Development] damnoregonian:
see:

i'm working on it.

there doesn't seem to be an easy interface for sending arbitrary commands, and there are no exports for that particular command.
[G2 and Desire Z Android Development] grankin01:
Figure of speech. :) I am all for root and would be sorely disappointed if they somehow (not likely) did find a way to honestly keep us from achieving it.

I spent quite a bit of money on this device (as did everyone who has it) and don't like the fact that someone else thought it would be a good idea to tell me how I could use it.

Will be a tester as soon as steps are posted for perm root. :)
[G2 and Desire Z Android Development] vi5in:
Bummer. Yeah, just looked at it. They are RO. Ugh. Looking more and more like I have to return this phone.
[G2 and Desire Z Android Development] craisis:
Ok, if my quick perl code to parse that binary worked... Both USER_WP and BOOT_WP are all zeros (both are bytes), which would be good news for us. (None of those bits define if the protection is enabled or disabled, just what we as a user or "host" can do.)
[G2 and Desire Z Android Development] thatruth132:
good work craisis
[G2 and Desire Z Android Development] wrxtc714:
I feel you

I have 20 more days to find perm root otherwise this thing will go back

As much as I love this phone, without root i'm just not satisfied.

Glad I haven't sold my nexus yet.

What would have been so bad about making it like the nexus

I know there is a way to root it without unlocking the bootloader now but I had no problem unlocking my bootloader and voiding my warranty.

That was such a simple way to seperate the rooters and the rest of the crowd

it's that simple and was a great idea that they should have stuck with imo
[G2 and Desire Z Android Development] vi5in:
Right. It's good they are zero because it means that we can't set permanent protection.
[G2 and Desire Z Android Development] craisis:
Bit def revisited.

Actually it means we can:

But it also means that when the command to disable writes is issued it is not permanently applied.

But most importantly, it means we do have a bit that if we can find how to set it will disable all write protection:
[G2 and Desire Z Android Development] damnoregonian:
i'm not entirely sure what they mean by power-on write protection...
[G2 and Desire Z Android Development] osho741:
I think it refers to wp enabled when the device powers on but what would be the point of that?

Unless its intended to be used with a specific partition that is used for powering the device up.