yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] tacromx:
take a look at this...

http://answerpot.com/showthread.php?3588432-mtd+nand+erase+and+bad+block
[HTC Wildfire S] cadam11:
does anyone have a bootloader.img file...if so could you please post it
[HTC Wildfire S] Antagonist42:
Would quote you nhb but only on my Acer right now ;)

You are right and also wrong, they have managed to make it possible to write as 'normal' NAND but also to be able to write 'sections' at a time as AMSS part of phone doesn't use partitioning as Linux does (can use NTFS/FAT32 if they so wish) the NAND Pages are updated and written at a later date depending what is using that Page of the NAND and is finally written back under I think is Garbage_Collection ... I'll be posting a couple more docs with more of these points of info that's not in the NAND or MSM7227 docs ;) at least that is what I can make of it having a 10-15 minute read of docs lol

Rooted Xakep E320/C6 EUU Hacked Update
[HTC Wildfire S] no.human.being:
Ok so the Radio section can be directly overwritten (read-modify-erase-write is handled by NAND chip itself or by the MSM's memory controller?) while the "Android" section must be explicitely erased?

Take a look at this exploit. It's for the HTC Thunderbolt, which uses MSM8655 processor with 8 GB eMMC memory, so I first thought it'd not be of any use for us, but check out the "msm_sdcc.h", it mentions that it's designed for "MSM7k chipsets" so something similar will probably work for us.

The "proc_comm.h" seems to be there for using low-level processor functions, some of which sound interesting.

PCOM_CONFIG_NAND_MPU

PCOM_NV_READ

PCOM_NV_WRITE

PCOM_GPIO_IN

PCOM_GPIO_OUT ("WP" pin of the NAND is connected to a GPIO on the processor! - Unfortunately I don't think that it's the NAND itself that's holding us off but rather the processor's MPU.)

PCOM_RESET_MODEM

The exploit seems to inject a module into the Android kernel that does something "evil" and gains write access. Considering we can boot custom kernels via Fastboot it's probably quite a bit easier for us.
[HTC Wildfire S] munjeni:
Yes, I allready mentioned about msm_proc_comm function... its realy interested allso, but we found in kernel only few calls to msm_proc_comm, all other calls is not documented for what use is but is still allready in msm_proc.h, so we need to test one by one :) !!! See my post -> http://xdaforums.com/showpost.php?p=27116490&postcount=2566 ... allso whole that page have many interested documents about usefull nand things

---------- Post added at 09:49 PM ---------- Previous post was at 09:40 PM ----------

For me now, first interested kernell things is:

- ioctl

- than msm_proc_com

- than msm_nand.c and nand.h (codearurora msm_nand.h have a lot of nand definitions that not exist in msm kernel!)

These 3 things + document about nand (posted by Antagonist) is very very interested...

Uhh, forgot nand_mpu (tried to dump it but phone allways reboot, but no problem writing to mpu, so why I don't know, it's still like write only flag )
[HTC Wildfire S] Antagonist42:
OK updated my Signature link ;)

Docs added are:

AMSS Multimedia App Concurrency

MSM6025 - a few here and you need to check them as to Memory mapping/Addressing/XMEM/NAND etc plus about page writing (who knew it wrote the page out elsewhere before an erase?)

MDM 62/6600/8200 docs

Make Boot doc has info may be of interest to memory map

Also check out the Filesystem Overview ... have some FTL to add to the mix :confused: :D

Table 4-2 Memory map (addressable) (cont.)

Region_________________|Base Add .|Max Add .|Range MB
RESERVED...............|0xDC000000 0xDDFFFFFC - 32
|.....................|0xDE000000 0xDFFFFFFC - 32
|.....................|0xE0000000 0xE0FFFFFC - 16
|.....................|0xE1000000 0xE1FFFFFC - 16
|.....................|0xE2000000 0xE2FFFFFC - 16
|.....................|0xE3000000 0xE3FFFFFC - 16
|.....................|0xE4000000 0xE4FFFFFC - 16
|.....................|0xE5000000 0xE5FFFFFC - 16
|.....................|0xE6000000 0xE6FFFFFC - 16
|.....................|0xE7000000 0xE7FFFFFC -16
|.....................|0xE8000000 0xEFFFFFFC - 128
|.....................|0xF0000000 0xFFFEFFFC - 384 - 0.064
BOOT UP REGION ........|0xFFFF0000 0xFFFFFFFC - 0.064

This kinda thing any good?

Hoping so for Posting #100 :cool: ....hope the next 90 are about what to do with S-OFF and the big ole grins we'd have :D (crack it in 10?):p
[HTC Wildfire S] Root-Maniac:
Is this going to apply to the AT&T HTC One X??? Please tell me yes!!!
[HTC Wildfire S] :
No, there is a totally different thread for the HOX. I had a look. They're doing well. The HOX is an emmc device. It's strange how I don't know what emmc is.

Sent from my TARDIS
[HTC Wildfire S] munjeni:
I verified again. After dd dev/zero blocks is all with 0x00 :eek: (strange thing is why its not treated as a bad blocks because have 0...hmm maybe oob data is not 0?)
[HTC Wildfire S] no.human.being:
So today I probed the JTAG traces with an oscilloscope while having the target powered, the JTAG interface connected and running OpenOCD on the host.

Most signals (nTRST, TDI, TMS, TCK, RTCK, nSRST) seem to be 3.3 V level, some (DBGRQ, DBGACK) seem to be 5 V level, which seems a little high, but what's really strange is that TDO (serial data from target to host) has a digital signal on that has a level of only 1 V, which seems a bit low. This is probably why OpenOCD says "target returns all zeros". Probably the JTAG interface interprets 1 V as low, given that all other lines use standard 3.3 V logic level.

Now the question is why the processor provides such a low output on TDO. What was also strange is that VTREF (target reference voltage) is at 0 V. ARM datasheets claims about VTREF...

So I enabled a second supply of 3.3 V (first supply of 4 V was powering the board) and connected it over a 100 Ohms resistor to the VTREF pin, but the result was still the same. OpenOCD reads "all zeros" and processor provides only 1 V signal at TDO. Any idea what could be the problem here? What could be the reason that the processor provides such a low signal voltage and is there any way to change it to a higher level? If not, could one boost the signal using some sort of "logic level shifter" so that the level is high enough for the JTAG interface?
[HTC Wildfire S] tacromx:
Can i suggest takeing the jtag craddle off the phone, apply power, boot up, then check with a meter what voltage is on the vref pad on the phone
[HTC Wildfire S] no.human.being:
VTREF is high-impedance on the phone and also an input on the JTAG interface side, so it seems that both the processor and the JTAG interface suppose the opposing part to provide the reference voltage.

Conforming to ARM's datasheets, the behaviour of the JTAG interface seems correct, as VTREF is declared as an "input" in their tables. The datasheet seems to be referring to the view of the JTAG equipment, not the processor, since it declares TDO, the pin that "receives serial data from the target during debugging" as an "input" and TDI, the pin that "provides serial data to the target during debugging" as an "output". So following this scheme VTREF is supposed to be an "input" for the JTAG equipment and therefore specified to be provided by the processor. However, it's high-Z on the processor side, so it seems that the processor is, contrary to ARM's specification, expecting the JTAG equipment to provide the reference voltage.

So we have both parties expecting the opposite side to provide the reference voltage. As both are expecting a voltage, I simply decided to provide it from an external DC source hooked to the VTREF pin on the JTAG adapter over a 100 Ohm resistor (as the datasheet claims "if VTREF is pulled HIGH by a resistor, its value must be no greater than 100 Ohms"). However, it seems that this is either not the problem or just part of the problem, since even with the VTREF provided by the external source, the logic levels on TDO are still only 0 and 1 V for "low" and "high" respectively.

The processor is "speaking" over the JTAG lines after power is applied to the board. You don't even have to boot the phone. The processor operates even when the phone is "powered down" (albeit in a "low-power state"), as long as voltage is provided to the board. You also don't need the "thermistor emulation" for the JTAG to become active. With the "termistor" pins of the battery open, the phone won't boot at all (not even into HBOOT mode), but the processor is already operating and JTAG is active. So as long as all you want is communicate with the processor, supply voltage is sufficient. The "thermistor emulation" will become important when we want to trace through the HBOOT code with a debugger, since the controller won't boot without what it thinks is a "proper Lithium cell". :D
[HTC Wildfire S] compro01:
eMMC is an embedded multimedia card. it's NAND flash+a controller in a single package, rather than just a raw NAND chip.

Allows you to use a more normal file system (e.g. ext3/4) and let the controller handler the wear leveling, erasing eccentricities, etc. rather than using a dedicated flash file system (e.g. YAFFS2) and having to deal with all that stuff yourself.
[HTC Wildfire S] munjeni:
N.B.H, on my phone, usb is conected, jtag is connected, voltage going to 4.2v only when jtag have connection to the board and phone is powered on in jtag mode, maybe I'm wrong (not payed attention to that part) but if I not forget there voltage was ~3v before I click "connect"... allso see this picture, maybe is of any help? -> http://i125.photobucket.com/albums/p69/littmanr/DSC04962-1.jpg
[HTC Wildfire S] no.human.being:
Voltage levels stay the same, it's just that there is communication going on over the interface when I start OpenOCD (at least for a short burst - until OpenOCD realizes that the target is not responding) and afterwards the lines go HIGH again.
[HTC Wildfire S] munjeni:
Maybe you have messconfiguration sothere around, wrong clock, or wrong pins...??? Do you found v+ pin on board? If not, you need tricks to get jtag connected for example I have no v+ connected to board, but I conected that pin to v+ pin of the battery connector and I need to insert battery for about 1s and reinsert battery to get jtag connected (without that I have error in comunication... something about irlen... so I need to repeat all steps "turn off jtag box, turn off phone..." until jtag have comunication. Will let you know next time what error mesage I have...). How many pins you found, 6,7,8 ? I have 7 (8th v+ missing, and is not in right connection that expect to be, its connected to v+ batery connector, so I have no full working jtag because I can not use reset/halt, I'm not abble to boot phone ir order to watch proceses, to watch registers, to watch memory...etc, only I can do is write/read nand while phone not booted)
[HTC Wildfire S] no.human.being:
I provide supply via a DC voltage source connected to the two outer battery pins on the board.

The interface has a 20-pin JTAG header.

1 - VTREF

2 - VTSUPPLY

3 - nTRST

4 - GND

5 - TDI

6 - GND

7 - TMS

8 - GND

9 - TCK

10 - GND

11 - RTCK

12 - GND

13 - TDO

14 - GND

15 - nSRST

16 - GND

17 - DBGRQ

18 - GND

19 - DBGACK

20 - GND

All the GND pins are connected together at the JTAG adapter to one needle contacting the board's ground plane. VTREF, VTSUPPLY, DBGRQ and DBGACK are left open on the JTAG adapter (present on the JTAG pin header but not routed anywhere on the phone's board). All the other pins are connected to some place on the phone's board via the adapter. VTREF I can either leave open or supply another 3.3 V from a DC voltage source. The result is the same whether I put 3.3 V onto that pin or simply leave it open. OpenOCD always claims "processor returns all zeros" and logic levels also stay the same.

There's a total of 8 "needles" on the adapter contacting the phone's board, 7 of them "sharp" and contacting traces, one of them blunt and contacting the ground plane. You have to grind off the insulating coating from the ground plane in the place where the adapter contacts it, otherwise you will have no ground connection and OpenOCD will claim that "processor returns all ones". Once you have established the ground connection, it will claim that "processor returns all zeroes". In the place where the 7 "sharp" needles contact the test points there is very thick black insulating coating on the board. The needles seem to be successfully penetrating the insulation, so you don't have to grind here. Ground plane is only place that needs grinding, since the needle contacting it is blunt and will not penetrate the insulation. However, the thick opaque paint in the place where the test points are prevents you from seeing what's on the board in this region. If you look carefully you can see a metalish glow from where the needles have penetrated the coating, but that's basically all. No idea how the circuit board looks below the insulation layer.

However, I think that the electrical connection is basically ok, since I can see data flow over the JTAG interface. It's just that the level that the processor puts out on the TDO pin is so low and I don't know how I can get that level to the proper 3.3 V instead of the 1.0 V that the processor puts out.
[HTC Wildfire S] tacromx:
@nhb

I take it you missed my post a couple of days back

you can see whats under the black tape here
[HTC Wildfire S] heavy_metal_man:
Hey guys I have access to a HTC wildfire s tomorrow with hboot 1.09.0099 and Radio 7.57.39.10m that I am going to xtc clip. Should I do Radio the dumps??? If so please tell me the full instructions also, I do not intend to htcdev unlock as it is not my phone. Will Simon simons tool unlock the hboot?? It says locked ATM. With rl beside the s-on. Also how long do we suspect the whole radio partition would take to dump?? Please nbh or theq86 reply or pm me asap as I will not have access to the device for long :cool:
[HTC Wildfire S] :
I believe your friend has already flashed the HBOOT from HTCDev, because it says "LOCKED".

Sent from my TARDIS
[HTC Wildfire S] munjeni:
You are wrong! So thats reason why you no have jtag connection :)

See picture from htc hd2 aka htc leo: http://img221.imageshack.us/img221/8083/20120616101614.jpg I had that phone and I had full working jtag connection (including halting, reseting, tracing...etc) because I had VREF pin position on the board (on my aria I have no VREF because no one know where it is on phones botherboard, instead of real VREF I have "tricky" VREF connected to the battery connector but that not worked good!). You need to have signal to 1st pin (of the 20pin header) from the board VREF signal in order to get jtag working !!! If you not route VREF from the board to the 20pin header (pin 1) on your box, you will have not working jtag ! See picture. These pin (not surre if is for sending or receiving) is for sending voltage to 1st pin of the 20pin header (this instruct your jtag box that there board is runing, so if you not send voltage to the 1st pin of your jtag box, your jtag box think that your board not runing :))

Another thing. When you read log from jtag_init (few posts back, you will see one of the few instructions sent to phone via jtag was

JLINK_Halt()... but as I say, "halt" is not posible if pin1 is not conected to the phone vref... and I can confirm VREF if not conected to "in my way" battery v+ connector, I have no working connection, and after all that I have hard way to get connection possible only with "tricks" (push battery for one seccond and pull back) to get jtag connection working! But again I must to say, when I had htc hd2 I had full working jtag solution (one click and I was connected)... I'm sure if I found vref on aria phone motherboard I will have full working jtag too without needs for using tricky things
[HTC Wildfire S] no.human.being:
No, I strongly believe that the reason for not getting JTAG connection is that the chip is putting out a signal with too low voltage at TDO.

The VTREF (not VREF, it's labeled VTREF, the T is for "target") is not for knowing whether the target is running. It is to be provided by the target so that the JTAG equipment can "dynamically adjust" its voltage to follow the logic level of the target. But in our case the target doesn't provide it, so I "artificially" pulled the trace up to +3.3 V in the hope that the logic level at TDO would "follow" from the too low +1.0 V to the required +3.3 V but it didn't do the trick.

Not sure what VTREF would have to do with halting. It is provided by the processor to the debugger, not the other way round, so it's not a sort of "halt/run" toggle. The JTAG equipment can hold the processor halted in reset state by pulling nSRST low and it can halt the processor from running state by pulling DBGRQ high.

Apart from that, the target can be put into debug state by hitting a breakpoint.
[HTC Wildfire S] munjeni:
Ok, believe you or not believe, theory or not theory, without VTREF I have no way to connect to jtag, and its true in my story! VTREF is input, is needed, and have reference:

All reference is here -> http://www.segger.com/interface-description.html

So if segger got null from vtref he treat my phone as a phone without power!!! So if vtref get signall from phone, he will know that phone have power, but if phone not send signal to vtref, how do you think it will work? I believe now, its reason why I need to insert battery for about 1s (vtref got needed signal from my battery) :)

But in htc hd2 storry is diferent. I have no problems. There segger vtref getting signal from phone directly when I power on phone!
[HTC Wildfire S] no.human.being:
It seems you don't understand what's the problem here. VTREF is high-Z on our board so it cannot drive the input on the JTAG equipment, but expects to be driven by the JTAG equipment. However, conforming to ARM's specification, the processor must provide the VTREF to the JTAG equipment. So it seems that in this sense either the Marvel board or even the MSM7227 chip itself is not conforming to ARM's JTAG specifications, but the interface is. So the problem is not that one couldn't connect the VTREF lines of the JTAG interface and the board. The problem is that neither piece of equipment drives that line.

So I have two pieces of equipment, the board of the phone and the JTAG interface, and on both sides VTREF is an input. So I tried to provide 3.3 V to the VTREF line from an external DC source, as I though that the processor's TDO, which puts out too low a voltage, might "follow" the VTREF, but it turned out that this is not the problem at hand. Even when I pull the VTREF line up to 3.3 V via a 100 Ohms resistor (see the ARM datasheet claiming that VTREF "must be pulled to 3.3 V on the target with a resistor no larger than 100 Ohms"), output on TDO remains at 1.0 V level, which is too low. So the missing VTREF is not the problem. Even with the VTREF pulled to 3.3 V, logic levels at TDO stay too low and JTAG interface fails to recognize the 1.0 V level as logical "high".

So I claim the true problem is the too low logic level the processor provides at TDO so we have to either find a way to increse the processor's logic level from 1.0 V to the 3.3 V that the JTAG interface expects or to put some circuitry between the processor and the JTAG interface that "boosts" the 1.0 V that the processor provides to the 3.3 V logic that the JTAG interface expects (e. g. a level shifter).
[HTC Wildfire S] munjeni:
Ok, lets see later.
[HTC Wildfire S] :
Did ya see my response?

Sent from my TARDIS
[HTC Wildfire S] heavy_metal_man:
yes i have :) but i would like to know what commands i would need to dump the radio and if nbh and the gang actually want it.
[HTC Wildfire S] heavy_metal_man:
firstly sorry about the name error bud :D secondly i will only have 20 minutes tops with the device as my friend will need to go pick up her kid:D will the fstboot command in the link you have sent me dump the whole radio or just the one for that specific radio?? i would prefer if it would just dump the whole lot in one :D

cheers again!
[HTC Wildfire S] no.human.being:
Oooh first please don't quote it all. :D

Well the problem is that you need to specify the correct partitioning or else the kernel in CWM might not boot properly, might run unstable and crash during the dumping procedure or (although I think the odds are fairly remote) brick the stock firmware on the phone by attempting to mount partitions that aren't really where the kernel thinks they are. The problem is that the "mtdparts=..." kernel parameter basically completely overrides the entire partition table that's on the phone. You cannot just "add another entry" to the table or something like that, you either use the table that's on the phone (not specifying kernel parameters, but this will not grant access to the Radio) or you provide an entire partition table as parameter.

Because of this you will have to figure out how this table looks like and I currently know of no other way than doing a "cat /proc/mtd" on a kernel that's booted to "stock" partitioning (e. g. stock ROM) and then doing all the lengthy (and error-prone) calculations. Sorry. :(

One might try building an app that does "cat /proc/mtd", parses the output and automates all the calculations, but this will take time that we probably don't have.
[HTC Wildfire S] *se-nsei.:
How's the development going nhb? The first post reeaaally needs updating, I hope. :D
[HTC Wildfire S] heavy_metal_man:
Hmm. How long would it take to come up with that command line if you had the cat/proc/mtd? You see I may have to try get this done while I'm in work ( which will be all of tonight).... If I can I might be able to unlock the bootloader and then cat/proc/mtd before work starts and upload it to here, because I don't feel confident in doing the math :o
[HTC Wildfire S] no.human.being:
You can "cat /proc/mtd" on the phone without bootloader unlocked. All you need is either a terminal emulation app on the phone or USB debugging enabled and a working Android SDK build for the adb shell.

Later for dumping the Radio you will definitely need a working Android SDK build on the computer.

Well I basically did a lot of of low-level (mostly hardware) stuff to the phone recently, not so much actual development. I found out how to configure OpenOCD (don't know whether the configuration is any good, since lots of values are more "good guesses" than actual knowledge but at least it's a starting point). I found how to get the board to boot without being attached to the Lithium cell which is not important for getting JTAG access (because this works as long as the board has power supply, being booted is not neccessary for JTAG to work) but will later be needed for tracing through the boot code, since the phone won't boot without what it thinks is a Lithium cell. :D However, I didn't get the debugger running yet. I suspect that the processor's logic level might be too low for the JTAG equipment. I don't really have an idea how to work around that yet, I might need to build a circuit that boosts the processor's JTAG signal to the appropriate voltage level (a so-called "level-shifter").

Apart from that munjeni and Antagonist42 also seem to make progress, but I must admit that I wasn't really able to keep track of all the things that they were doing recently. So basically we're now down at the actual physical layer and messing around with the electrical stuff that's going on on the phone's board and trying to find a way of actually talking to the processor to get the on-chip debugging working. :D

The far goal will be getting a patched HBOOT that has signature verification removed loaded into the device's memory via JTAG, then flash a patched HBOOT image via Fastboot. If this works it will be the first S-OFF GSM WFS that's neither shipped S-OFF nor turned S-OFF via xtc-clip, but this might still be a long long way.
[HTC Wildfire S] heavy_metal_man:
Excellent! So if I do that and post the info could you do the math. It will be a good 2 hours after I start work until I get my 1st break :D