yashsingh1/xdaforums huggingface dataset:
[G1 Android Development] BinaryDroid:
Yes he gave me the access to the files already, thats one of the reasons I need to installed windows first lol. I never used windows on the development machine but honestly the only thing that seems to hold the important data is the scripts which are human readable so I'm almost sure they could be adopted to OpenOCD or similar. I mean it even has the label on which pins need to be set high, low or what have you, ways to flash, erase, you name it its their. after seeing those files I figured we didnt need the JTAG document that were seeking. if everyone can figure it out on other devices with no documents..surely cant be too hard. i have soooo much more software to test on linux though. i have no plan after work so probably going to install Ubuntu 9.04 , turn off updates and then test OpenOCD. that seems really positive! i've got 3 different parallel Jtag adapters made for testing, Old cheapo, Buffered, and the third is a really complicated one that has all the possible connections needed(but more to go wrong hehe)

I could really use some help on how you normally get a phone into debug mode, or how can I do a simple test to read the Chip ID?

Also does anyone have a bricked board their willing to donate? i'm doing all of this on my primary functional board and would hate to kill i, also not sure if i'm actually in debug mode.
[G1 Android Development] scholbert:
Hi BinaryDroid!

May help out if i got my device....

Anyway it would be very nice idea to contact ViperBJK (author of QMAT).

He prooved JTAG access to Diamond already and good very deep knowledge of the device.

Debug mode should be also activated by hardware.

If nothing works out it would be a possibility is to ask one of the Hard-SPL creators. Disassembly of the SPL may give a hint of activating debug mode.

It's obvious, that the mode pins are important to be setup correctly.

The watchdog needs to be disabled (can't remember the pin), PS_HOLD would be required too.

The MSM chipset is bit more complex to access for debugging.

We need patience to gather the necessary informations.

MPU on Hermes was much easier i guess :p

EDIT:

From what i know so far, there would be mainly two methods on MSM to give access to the NAND chip:

1. Using TAP controller

This is a basic access and it is possible to toggle the pins in hardware, simple LPT adaptor should do the job.

2. Using ETM unit

This should be the mode used in QMAT.

Some binary is loaded into RAM (RAM needs to be initialised) and is used as a programming tool.

ETM gives control to the memory, but it's bit more complex to handle.

Anyway, the ARM units inside MSM chip have different ID's. Both should be accessible through primary port.

As far as in know MMU needs to be disabled while accessing the chip.

Regards,

scholbert
[G1 Android Development] BinaryDroid:
Ok well purchaed QMAt with JTAG last night since that tool has been written specifically for the job and will help with getting everything figured out, plus i need it for other projects. the QMAT setup does not mention the mode control pins being used at all for some reason. only the pins I already found which did not seem to work with my 5 wire unbuffered Wiggler. I have to do another test tonight with the complete complicated version that is suggested just until I get it working. once I know the connection works i'll adapt the simpler wiggler to do the same job so anyone trying to unbrick can build the simple $10 dollar adapter and build themselves. I aleady have a plan to make the soldering job to the jtag pins painless via modding the EM shield. at least now with QMAT purchased I can feel better asking him questions and getting correct answers. Primary JTAG is definitely the way to go. your correct also about the ps_hold pin attached to 10K resistor to the watchdog pin.
[G1 Android Development] virdi:
Small step for Man, a giant leap for Android ;)

@BinaryDroid @r3nrut Keep going, good stuff. Thanks for your hard work!

I have my G1 taken apart (no, it's not bricked - I am changing the housing). Do you want me to label the Primary JTAG pinout on one of the high-resolution pictures I am taking?

How close are you to the secondary pinout?

Did you ever find the elusive pdf document with JTAG connection details?
[G1 Android Development] scholbert:
Wonderful :D

Yeah that would be awesome...

To support the MSM7xxx familie in OpenOCD would also be very nice.

I saw lbcoder already posted a link ;)

Anyway, if we use boundary scan mode the software implementation would not be very complicated.

First step would be to build up a header file from the BSD-file of MSM7xxx.

Also simple buffered LPT-adaptor could be used.

Have a look at this package...

Keep on hacking!

scholbert
[G1 Android Development] R3nrut:
Excellent work Binary Droid!!!

I'm working on gathering a few bricked boards for testing on. If I get two I'll send one your way.
[G1 Android Development] twoscoops:
Have they been verified?

Ok, we know the pinout, but has anyone successfully connected up to these pins and checked them? I.e. can you get a response to the IDCODE command working?

I gave it a quick test (with Segger), but it was not able to see anything on the chain.

For what it's worth, the Segger wants VTref (target reference voltage), and nSRST (target CPU reset signal) which we don't have labelled. I left nSRST disconnected and tied VTref to an external 3.3 source.
[G1 Android Development] ezterry:
interesting; not sure it helps or hurts for radata..

radata <offset> <block size?> followed by the data with an "info" signature.

Yes the SPL uses ram to talk with oemsbl but we ought to be able to talk directly to radata.. if we don't need some data on the phone or elsewhere for the "info" signature.. (this is why the command line stops responding when you type radata 90000000 1 ... its waiting for data.)

That said I wonder if I can use this + oemsbl bugs to execute arbitrary code.

...

I'm still having memory reference issues looking at HTC_BOOT.. seems virtual memory is set up in QC_BOOT, so even if its at 0x00900000 physically that's not what its offsets expect.

QC_BOOT (part12 of my split) sets up the translation table in memory at 0x80038000; clears it and seeds it based off some data starting at 0x8001DC1C and 0x8001DC94 (still looking into what may be loaded there.. hopefully I'm not looking at more virtual addresses)
[G1 Android Development] bart9984:
Hi ezterry,

I said radata only because somewhere I read it could be used to flash. Actually I don't know even how to use it and what the command does. What is data with info signature? I could investigate on it if I know what is it :)
[G1 Android Development] viperbjk:
radata is just writing to memory.

rwfactory is the right command to write nand, which is only available in mfg spl afaik.
[G1 Android Development] ezterry:
At the very least the ENG SPL (hboot/fastboot) flashes most partitions directly; however the radio it passes to the radio firmware via radata; and presumably then it is either flashed to or can be triggered to be flashed.

Might just be SHA1+data... might be SHA1+signed by HTC + data.. or a bit better SHA1 signed by either a key on the phone/rseed/radio.img + data ... it might be something else entirely..

Thus far I only spotted sha1 code inside a function near the printf of "INFOadopting the signature contained in this image" from the ENG SPL..

Edit: Interesting, just found the "help" for radata

(yes I think it still needs the two parameters)

Also this script: http://nah6.com/~itsme/cvs-xdadevtools/xda2nbftool/parsegsmv2.pl

seems to extract HTC radio images very well (was written for the Kaiser; but worked flawlessly to extract the G1 radio)

That properly extracted oemsbl based at 0x900000 as previously mentioned.
[G1 Android Development] ezterry:
Updated list of oemsbl commands available over serial on ota-radio-2_22_19_26I (when security locked.. many more if we where security unlocked)

rseed -- no help screen

rpass -- no help screen

radata -- Write All data Command for RUU

powerdown -- Power down.

pmic_vreg -- no help screen

pmic_level -- no help screen

pmic_vib_on -- no help screen ... turns vibrate on

pmic_vib_off -- no help screen ... turns vibrate off

GO2AMSS -- no help screen

setboot -- set boot mode (See my previous post)

setoffmode -- Off-mode charging switch (0 = enable; 1 = disable)

checksum -- Checksum of oemsbl and amss image

rtc -- RTC Command
[G1 Android Development] bart9984:
hi ezterry,

I can confirm all the commands are enabled also on my Magic.

where did u find them? While disassembling?

there is hope to find other commands?

good work

here an example:

>setoffmode
Off-mode charging switch: 0x0 [0:Enable/1:Disable]
>checksum
Usage:
checksum oemsbl
checksum amss

>checksum amss
CheckSumCRC = 0xA8506225

>checksum oemsbl
newest_mibib_block = 2 , oldest_mibib_block = 3

CheckSumCRC = 0xA497B2AA

>rtc
rtc.sec = 130105

for commands:

Command: pmic_level

Usage: pmic_level <vreg_m> <level_in_hex>

<vreg_m>:

PM_VREG_MSMA_M

PM_VREG_MSMP_M

PM_VREG_MSME_M

PM_VREG_MSME2_M

PM_VREG_MMC_M

PM_VREG_RFRX1_M

PM_VREG_RFRX2_M

PM_VREG_RFTX_M

PM_VREG_TCXO_M

PM_VREG_SYNT_M

PM_VREG_RUIM_M

PM_VREG_RUIM2_M

PM_VREG_USB_M

PM_VREG_WLAN_M

PM_VREG_MDDI_M

PM_VREG_CAM_M

PM_VREG_BT_M

PM_VREG_AUX_M

PM_VREG_AUX2_M

PM_VREG_MSMC1_M

PM_VREG_MSMC2_M

PM_VREG_PA_M

PM_VREG_BOOST_M

PM_VREG_GP4_M

Purpose: Set pmic level.

Command: pmic_vib_on

Purpose: Enable pmic vibration.

Command: pmic_vib_off

Purpose: Disable pmic vibration.

Command: pmic_vreg

Usage: pmic_vreg <vreg_m> <1/0>

<vreg_m>:

PM_VREG_MSMA_M

PM_VREG_MSMP_M

PM_VREG_MSME_M

PM_VREG_MSME2_M

PM_VREG_MMC_M

PM_VREG_RFRX1_M

PM_VREG_RFRX2_M

PM_VREG_RFTX_M

PM_VREG_TCXO_M

PM_VREG_SYNT_M

PM_VREG_RUIM_M

PM_VREG_RUIM2_M

PM_VREG_USB_M

PM_VREG_WLAN_M

PM_VREG_MDDI_M

PM_VREG_CAM_M

PM_VREG_BT_M

PM_VREG_AUX_M

PM_VREG_AUX2_M

PM_VREG_MSMC1_M

PM_VREG_MSMC2_M

PM_VREG_PA_M

PM_VREG_BOOST_M

PM_VREG_GP4_M

Purpose: Set Pmic verg on/off

taken from this url http://www.nuerom.com/nueWiki/(S(w2ere43fchst5i45bweu3v55))/Rhodium_W rtask a commands.ashx?Code=1

So in other forum posts when they use

radata 90000000 1

is for changing oemsbl on the fly?

bart99
[G1 Android Development] bart9984:
edit

false positive

sorry

:)
[G1 Android Development] ezterry:
Thought that was used for the SPL on other phones.. and it may

If we mess up the oemsbl there will be no way out w/o jtag..

Those were the white listed subset of commands allowed on a security locked device from the disassemble. (I could check your radio version if its different to see if you have something else but I'd be surprised)

The full list is much much longer and has commands to read/write to arbitrary locations in memory.

Ok... sleep for me..
[G1 Android Development] scholbert:
Great job ezterry, i think you are quite a master in disassembly ;)

The offsets i posted were observed during JTAG debug session.

Physical and virtual memory is often very confusing, so maybe i'd like to point something out.

Using JTAG debug mode on ARM9 core everything is physical memory from the ARM9 point of view. MMU must be disabled otherwise the debugger will loose connection to the core, afaik.

Blue led mode:

Booting G1 into HTC_BOOT (radio bootloader) no MMU is involved, perfect debugging stepping through the code works very well.

That's the mode i was in while reading out certain memory regions.

Code yould be written to RAM using the debugger. Which means that memory is completely initialized.

Executing code would also work, but the JTAG adaptor slows down execution speed, so no way for realtime observations with a LPT-adaptor.

If i start into AMSS with GO2AMSS i'm loosing connection or to be more exact i'm not able to reconnect to target with JTAG.

At least that's what i observed.

After booting G1 into standard bootloader mode (i already told that my device is no brick yet) it is also possible to connect to ARM9 with JTAG.

While ARM11 is executing standard SPL located in RAM at physical 0x0, ARM9 seems to live in HTC_BOOT at physical 0x00900000.

Memory at 0x0 could be modified with debugger using the ARM9 access.

ARM11 is running autonomously.

I never tried to set ARM9 PC at 0x0 and start execution... Would crash immediately i guess :D

Right now i'm a bit confused about this radata command and if it would help us.

Another thing i realized is that HTC_BOOT seems to be very wicked code.

I guess that's what they call signed bootcode (uuuuaargh).

EDIT:

I started to write low-level JTAG tool with MSM720x support.

This attempt will use the JTAG mode of MSM cpu and uses BSDL file information to toggle the required signals (EBI2_DATA0..7, EBI2_CS0#...) of the cpu.

Some further research will be required to handle the NAND access.

This software won't make use of the MSM NAND controller, but uses TAP controller instead. The NAND flash chip will be set up directly via JTAG chain.

Because this will be the lowest level of access, every part of the chip could be accessed this way. Though this method is known to be very slow it would be enough to rewrite a bricked SPL someday.

This all sounds very weird, but basically i know how to do programming.

My sparetime is also very limited so i won't give any timeline or similar :rolleyes:

Perhaps i'll need some more information form BinaryDroid because there are some requirements concerning hardware testpoints.

I also must admit that my skills are not enough to write a tool which is required for viperbjk's PSAS environment.

So if there's someone who could help out on this attempt, please join the discussion.

TBC...

scholbert
[G1 Android Development] bart9984:
hi scholbert,

just for my curiosity, if you have a serial cable

which is the output on mtty in normal boot?
[G1 Android Development] scholbert:
Hi bart9984!

Here's the boot message of my G1 on the serial line:

boot reason: PM_KPD_PWR_KEY_ON_RT_ST

(PowerOn Status,Boot Reason)=(1,1)
NAND_FLASH_READ_ID : HYNIX_256MB_FLASH_128MB_SDRAM

ARM9_BOOT_MODE0, Boot Android
Clearing RAM...
Load Bootimg header, addr=0x507C0000 taget=0xA8100000
Load Bootimg header OK
Load Kernel, addr=0x507C0800 taget=0x80008000 Size=0x001E1054
Load kernel OK
bad block num=0
Load ramdisk, addr=0x509A2000 target=0x81000000 Size=0x00027322
Load ramdisk OK
SPL2 doesn't exist
Load OK.
SetupTAG addr=0x80000100 cmdline add=0xA8100040
TAG:Ramdisk OK
Get CID OK

androidboot.serialno=HT852KV36185
boot reason=0x0
commandline from head: no_console_suspend=1 console=null
command line length =314
active commandline: board_trout.disable_uart3=0 board_trout.usb_h2w_sw=0 board_trout.disable_sdcard=0 board_trout.smisize=64 androidboot.baseband=2.22.19.26 androidboot.bootloader=0.95.3000 androidboot.carrier=TMD board_trout.keycaps=qwertz androidboot.mode=normal androidboot.serialno=HT852KV36185 no_console_suspend=1 console=null

PARTITIOM_NUM_MAX =6 Valid partition num=6
jump to linux kernel

Cheers,

scholbert
[G1 Android Development] bart9984:
Hi sholbert,

thank you :)

after seeing this I'll try to do some consideration (maybe I'm totally wrong):

addr=nand addresses

addr=virtualmemory addresses

Start loading boot.img header len=0x800

Load Bootimg header, addr=0x507C0000 taget=0xA8100000

load the kernel (in boot.img starting from offset 0x800 in effects data changes) so kernel is into boot.img? len about 2 Mb

Load Kernel, addr=0x507C0800 taget=0x80008000 Size=0x001E1054

here it load spl?

Load ramdisk, addr=0x509A2000 target=0x81000000 Size=0x00027322

it seems to load the spl after 0x9a2000-0x9a1854 =0x7ac bytes,but spl header seems to be (on my spl sample files) 0x800 bytes

however if my thoughts are right on nand boot.img and spl data are written in succession on nand...

bart99
[G1 Android Development] naack:
hi, i am not sure if this will be in any help to anyone or if related.

from power off, if you press action button + power/end button you will get a solid blue light.... thats it... i am not sure what it does....

i am not sure if its some kind of recovery mode for the g1 ( hoping )

---edit---

same thing happens bricked or no bricked...
[G1 Android Development] ezterry:
It gives you access to the oemspl via serial console via a "HTC Debug serial wire"

The console has the commands noted here (earlier on this thread):

http://xdaforums.com/showthread.php?p=5665547#post5665547

Links to instructions to build the wire are also on this thread.. but while the mode is obviously for debugging and fixing the phone.. we have not found a way with what little access we have to successfully restore a brick.

Both that possibility and flashing the phone via jtag are being explored in this thread.
[G1 Android Development] naack:
thanks for the kind reply...

the chances are you guys have already seen this. http://www.youtube.com/watch?v=eITMEEF_AIc

from the looks of it it seems to be the same box used for the omnia ( with different connectors ofcource.) there could be some info on that end that could piece out the puzzle...
[G1 Android Development] FRSP:
Can anyone tell from the pictures if that adapter is going to the primary jtag or the secondary?

People here seem to have found the arm9 radio processor on the primary, I suspect the arm11 apps processor is on the secondary, and maybe there would be more luck driving that?

My understanding is normally we use the arm11 to flash everything except the radio which is passed to the arm9, but as its the same nand and would get commands confused if the arm9 tried to read it while arm11 was flashing no matter what addresses are being flashed, it seems like the arm11 could write the radio as well? Or just write an spl compatible with the radio believed present.
[G1 Android Development] ezterry:
My understanding is the radio (ARM9) blocks some memory/regions from the OS (WinCE/Android) on the ARM11.

Thus the reason the SPL uses the arm9 to flash the radio is because it can't access the addresses its self. (The arm9 can flash anywhere, even if the SPL/OS use there own internal flash code rather than the radio flash code for other flash updates.)
[G1 Android Development] FRSP:
The nand is memory mapped?

I thought it had command/data ports iomapped? guess I'm wrong?
[G1 Android Development] marxmarv:
Many SoCs contain a memory controller that provides a layer of transparent translation at the hardware level from CPU bus cycle to command/data for SDRAM and/or NAND flash, and many of these do provide a pass-through for low-level access, at least when the controller isn't running.
[G1 Android Development] ezterry:
??? my brick doesn't do SPL/fastboot.. if it did I'd have a working phone.
[G1 Android Development] hause:
And what's about serial I/O?

Any output?

I had no usb in the blue-led-mode.

With the serial console I was able to set my magic to arm bootmode 0.

No HBOOT but fastboot came back and usb was back too.
[G1 Android Development] bart9984:
hi hause,

I've got a Magic 32A.

I tryied your function to flood the phone but in my case it's not rebooting.

If you have fastboot enabled why don't you use it to flash the phone?

If you can't I think you can enter at least downloadmode and so you can flash your device using qpst or qmat/psas tools.

Cheers,

bart99
[G1 Android Development] ezdyy:
bart9984:

hi, checked on your python fu... forget about using spl to load kernel, this is all (.text/stack) IP smashing 101, basically:

since rough addresseses where radio/spl are known i'd try the following way:

1. put at some sufficiently high addr (say 0xc000 for illustration) arm code which does just infinite loop (eq. jmp $-2 in x86 asm).

2. take a look in IDA at sbl driver to determine if its thumb or 32bit mode.

3. create a nopsled from top, terminated by jump to code of 1., ie. according to 2. at sufficiently high address, following by NOPs just above that (ie jmp to 0xc000 @ 0x8000, nop @ 0x4ffe, nop @ 0x4ffc etc).

eventually you'll hit IP the cpu is at and redirect the execution flow to the infinite loop and see the last address before the serial fell silent (prolly followed by watchdog reboot), mark that addr to save during further attempts:).

the rest should be history: kernel is PIC (afaik) and expects address of initrd (check android sdk for info).... so just push this to ram instead of the loop. unless there are gotchas involving mmu this should work out (kernel is pretty self-contained and independent of other stages other than getting loaded and executed).

finally, something very similiar should be done by jtag tools doing jtag dram writes.

edit: forgot to mention, there might be stack at high addresses, instead of code. so instead of nopsled also try just 32bit values you wish the currently called function to "return to" :) again... if you can just dump memory as you highlighted you could save yourself a lot of guesswork, but its definitely doable.
[G1 Android Development] scholbert:
Hey ya!

Primary port is the one that has been prooven for JTAG access.

This port could be switch at least to ARM9 debug (using JTAG as a transport layer) or true JTAG mode.

Though never tested, it could also be configured to give ARM11 access.

Unfortunately i got no debug environment that supports ARM11, that's why i concentrate on ARM9.

Another reason is that ARM9 is the first core involved while starting the system.

ARM9 gives permission to start ARM11 :p

Anyway the radio bootloader is able to recover all areas in NAND and could do lot of other stuff, e.g. low level system diagnostic.

Spent half the night on disassembly and it's quite amazing....

Problem is that it is signed code and seems to use certain keys to activate the special functions.

Very ugly stuff # +!"??

So there are a lot of open issues... the top most wanted is:

How to unlock hidden H-Boot functions???

Hi ezdyy, welcome to forum!

What are you trying to tell us :confused:

Regards,

scholbert
[G1 Android Development] G1Hope:
Hi folks!

The rest of life has been eating me up so I haven't had time to screw around with my brick lately. =(

...but on coming back I am heartened by all the progress that has been made!

Observation

As I understand it, we have the ability to write arbitrary data to memory via serial now! Awesome!

I wonder if the security flag is writable in RAM at all, or a branch where it checks it at least. If we can somehow bypass the security flag check (probably a 1 byte replacement) we should be able to take advantage of the extended command set.

Moreover, it looks like the factory flash routines are still in radio.img, just disabled. I wonder if we can enable this with a write to RAM (or, failing that, jump directly to the routine w/buffer overrun).

If we can do this then we don't need to load a heavily-hacked SPL into RAM to do fastboot -- instead we just use the radio ROM's flash routine to flash the compatible SPL and boom, unbrick!

I've been out of the loop for weeks here, unfortunately, so maybe someone who's pored over the disassembly can comment on this.
[G1 Android Development] scholbert:
Hey G1hope,

welcome back :)

Yepp! This has been discovered first by bart9984 using his Magic 32A device.

Problem here:

The reachable area in RAM is limited.

How to execute code?

Via JTAG you may modify anything you like in RAM, but unfortunately serial communication fails because, debugger is slowing down CPU.

Will need something like realtime debugging environment for that (connecting RTCK maybe also required then).

Anyway would work as a proof of concept and for devlopment, but of course this is not a practicable way...

Here are many open issues...

AFAIK there are many security checks in HTC_BOOT.

Seems that some weird keys are needed to release the command set.

Yesss, that's the theory so far :D

Regards,

scholbert