Hello there,
I now am a happy owner of a HTC Prophet ( I bought it as an O2 XDA neo) for about two weeks.
The thing works fine, but I am interested in installing linux on it (that's the main reason why I registered at this site).
But because this little piece of hardware is quite expensive I have some concerns about flashing the rom. So I have to ask:
Is there a SAFE way to try a new/altered/old/linux rom on my Prophet;
e.g. if the newly installed rom isn't working/ I don't like it/ the flashing process crashed/... can I somehow get the original state(e.g. the O2 branded WM5) back on the machine?
I cannot afford to try something with this machine and afterwards I have to put it in a trashcan :-(
-regards,
traintop
There are no 'safe' way of doing it. Probably the safest way of doing it to let an experience person to flash it for you, still there are certain risks.
For your case, I don't think you should flash it yourself. BTW, there is linux ROM for Prophet?
If you want to deal with linux, you need to modify bootloader.
This is not safe. You may turn your device into brick quite easy.
If you want experementing with linux, then look on Nokia 770, it would be your choice. Linux is by default installed on Nokia 770. And you don't need to modify bootloader.
regards,
de fdp24
hanmin said:
BTW, there is linux ROM for Prophet?
Click to expand...
Click to collapse
I haven't found one yet; and I believe there aren't any. But if you want to try a compiled kernel on a PocketPC, I would think putting it into a ROM and flashing this one to your machine is the best way...
-I have to say I have experience in building linux on Intel-based PCs from scratch and I just wanted to know whether there is way of trying linux on my Prohpet in a way similar to the one used on your desktop (e.g. dual-booting).
But because storage-capacities (ROM) is quite tiny in comparison to desktop PCs (where another hard drive or at least a partition ist easily installed to switch between) I think you have to
backup your current state of the Prophet,
save it to your PC,
flash the new to-be-tested ROM on the Prophet,
reboot and try.
After testing you can flash back the "original" (in my situation: WM5) ROM, reboot and you're fine.
With this process I have no problems at all (although a bit time-expensive) if and only if the flashing of the Prophet can be done quite safely...
I have read a lot about linux on HTC devices and found out that the Prophet is nearly an exact copy of the Wizard, just without keyboard.
So how do the guys from the Wizard-Team do the testing of the newly compiled kernels and so on...
-If they would have to fear the end of their machine each time flashing the ROM I think they are either very brave men or they have good tools.
I think I will post my question in the wizard thread as well but thought to ask here first because they will probably say: I have no idea; I only have a wizard! ... :-(
-cu,
traintop
ps: after reading my post again I remember an old SUSE-distribution (I think it was 5.4) where you could install a little Programm on your Windows-partition.
When you started this programm it booted a linux kernel which in some way managed to get windows completely out of RAM and you could work with your linux-box as if it was booted with linux from the very beginning...
-perhaps this could also be a solution...
If you are not familiar with Linux - never try to play it with mobile devices. Just a good advice: use your desktop and let your handheld live as it born
Hi Universal cracks,
i got a Qtek device which seems totally bricked.
The history of the device is unknown, so my investigation is getting deeper and deeper.
On gathering all information together it seems that the IPL and maybe also the SPL is damaged and cannot be easily revovered, because the bootmenu is not reachable in any way (believe me, i read everything about recovering intensely ).
That's why i'm looking for a general way to recover bricked devices using JTAG.
The idea is the following:
1. Access the device via jtag
2. Setup ram according to the setting used in wince or linux kernel
3. Rewrite IPL (it is yet unknown how to do it!)
4. Load SPL as executable binary into RAM using JTAG
5. Start the SPL from RAM
6. With SPL running from RAM Re-format the DOC reinstall SPL into DOC
Restart
That's it!
To resume my efforts so far i may report:
1. JTAG connection established (using OpenOCD or OCD Commander)
2. Init SDRAM (using intel PXA270 development kit setup)
3. Write a file to SDRAM and start it
4. Made a dump of IPL and SPL (using haret)
What did not work???
1. Access mDOC G3 in normal mode via JTAG (seems to stick in reset mode)...
2. Rewrite IPL using JTAG...
3. Start the SPL successful from SDRAM base address....
What do you think specialists!
Anyone willing to help?
Cheers,
scholbert
Hello Scholbert,
Sorry I couldn't help you out on this matter. But When I read your post I thought that you gone deeper than me in this technically.
So can Please go though my problem http://forum.xda-developers.com/showthread.php?t=353063 & help me out to solve WHITE SCREEN Problem?
Thanks in Advance.
bootloader
Hi scholbert, it couldn't be enough to simply rewrite the bootloader?
Please could you post the patched version of openwince jtag?
Hi roglio,
roglio said:
Hi scholbert, it couldn't be enough to simply rewrite the bootloader?
Click to expand...
Click to collapse
Maybe you're right , restoring the uni via JTAG could be mission impossible (at least the way described in my starting post).
As far as i got to know from various postings, the bootloader itself does some security checks during runtime (password checking, CRC checking ...).
It could require some real awful hacks, to start the SPL from RAM with an external debugger.
Please could you post the patched version of openwince jtag?
Click to expand...
Click to collapse
I made a lot experiments on other platforms using the openwince jtag.
In this case i used the famous OpenOCD:
http://openfacts.berlios.de/index-en.phtml?title=Building_OpenOCD
There's PXA270 support out of the box!
You have to download the sources from their SVN-repository .
Anyway i'll have a look on my workstation in a few days, what could be of interest for the geeks out there.
Regards,
scholbert
Geek inside
Hi scholbert, all bricked universal are broken because the bootloader was wrongly updated or overwritten with a bad update. If we look for a fresh bootloader, the right starting address and wrote it back we've fixed the major problem. Recover a universal starting from this point is already well documented...
Tomorrow I'll download OpenOCD and try to compile it on cygwin to start doing some experiments.
I lack of some informations anyway: the most important is the address where to put the correct bootloader...
I'll post any further step ahead.
Thanks.
roglio
Hi again,
roglio said:
Hi scholbert, all bricked universal are broken because the bootloader was wrongly updated or overwritten with a bad update.
Click to expand...
Click to collapse
this seemed to be happened to my device too. With single stepping starting at address 0x0 there's an error after some instructions. So it seems there's wrong assembler code in the IPL section already.
If we look for a fresh bootloader, the right starting address and wrote it back we've fixed the major problem. Recover a universal starting from this point is already well documented...
Click to expand...
Click to collapse
That's the theory .
Tomorrow I'll download OpenOCD and try to compile it on cygwin to start doing some experiments.
Click to expand...
Click to collapse
Good luck for this action! I did compile it on a debian linux system.
I lack of some informations anyway: the most important is the address where to put the correct bootloader...
Click to expand...
Click to collapse
Let's assume we got a working device .
As far as i know, this is what happens after coldboot (comments welcome):
1. DOC is in reset mode, processor jumps to address 0x0 and excutes IPL
2. IPL initializes RAM, switches DOC to normal mode and copies SPL to RAM
3. further details of IPL functions unknown
4. leaving IPL, jump to physical address 0xa0000000
5. execute SPL ....
The problem is, that at this point various system checks are following.
If something goes wrong before we good USB serial connection or bootloader screen. The processor simply could stop at any instruction and we won't know why .
I'll post any further step ahead.
Thanks.
roglio
Click to expand...
Click to collapse
Good luck for your next steps!!!
Maybe, we may draw some attention with this little discussion. It would be nice to get things rollin' and someday there'll be hope for all those bricked devices around .
P.S.:
I already made bootloader dumps. See attachments!
IPL and IPL2 got the same content but they were dumped on different physical addresses. SPL was dumped from RAM. Of course these files were taken from a working device.
scholbert
Hi, after your description of the boot process I'm not so optimist anymore...
Anyway, I've just finished to compile OpenOCD under cygwin, without any major problem.
Just a doubt: which configuration file are you using?
Does you have already configured also the flash banks?
I share your doubts about what's happen after SPL execution... IMHO anyway we should give a chance to a complete reflash: fully dump a working device and after wrote it back to a bricked uni just to see what happen.
Some time ago, I've accidentally overwritten the bootloader of a Toshiba e740 PDA (very nice device indeed). After using a proprietary jtag sw/hw I've resurrected it simply writing the bootloader back in place.
This give me at least a hope...
Hi roglio,
Anyway, I've just finished to compile OpenOCD under cygwin, without any major problem.
Click to expand...
Click to collapse
Great!!!
Just a doubt: which configuration file are you using?
Click to expand...
Click to collapse
I will post the configuration file as soon as possible (it's on my linux machine at work ).
Does you have already configured also the flash banks?
Click to expand...
Click to collapse
No, only the PXA270 chip select for the DOC device was set up. These NAND flashes need special initialisation to switch form reset mode to normal mode to be programmed or to read the filesystem.
This process was not yet successful using JTAG .
I share your doubts about what's happen after SPL execution... IMHO anyway we should give a chance to a complete reflash: fully dump a working device and after wrote it back to a bricked uni just to see what happen.
Click to expand...
Click to collapse
If we are able to access the DOC device in a proper way, this may work.
At least there are professionel programmers on the market, that are able to reprogram these devices using the JTAG interface. But these are very, very expensive .
Some time ago, I've accidentally overwritten the bootloader of a Toshiba e740 PDA (very nice device indeed). After using a proprietary jtag sw/hw I've resurrected it simply writing the bootloader back in place.
Click to expand...
Click to collapse
Yes basically this also possible for the uni, but this damn#?=% DOC device is very hard to handle. There's also no linux device driver for these devices yet.
Great work anyway!!!
This give me at least a hope...
Click to expand...
Click to collapse
Our hope should never die .
Best regards,
scholbert
Googling
Hi, scholbert! Today I was googling around and I've found some interesting informations about mDOCs... These special flashrom are internally handled as NAND flash but with the cpu (when used to eXecute In Place XIP) are handled as NOR flash chips. I haven't still found useful information to understand how this could be useful for our goal.
Another interesting information about mDOCs is that exists some pc software that permit to flash them via jtag but are part of very expensive development packages!
Anyway mDOCs are handled by linux! Basically it is possible to patch the linux kernel to handle them via trueffs. I'll be more detailed tomorrow, but my first impression is that these information about linux drivers for mDOC family aren't useful for our project...
Does you have retrieved the conf file for openocd?
Hi roglio,
that's nice information. I also gathered together anything about the mDOC series i could find, all over the planet. If you need more details
Unfortunately, there's no source code of the low level routines to access this device. If someone would share m-systems BDK for the G3, you're welcome!
Does you have retrieved the conf file for openocd?
Click to expand...
Click to collapse
Yes, but i realized that i used a slightly modified one of the standard package (no SDRAM init, nothing but access PXA270).
You will find it attached!
My efforts with the uni using OpenOCD get stuck at a point, because i only got a very simple JTAG hardware. To use it as a debugger you also need to have influence on the systems reset.
That's why i decided to used some Macraigor stuff to get nice hardware debugger for accessing the universal hardware with OCD Commander.
Obviously both systems are very similar.
OpenOCD is completely GPL, so this should be first choice in the end!!!
You will also find the OCD Commander config file (htc-uni.zip) attached.
This could be the base for an OpenOCD script (very similar stuff).
Just an additional information:
I successfully disassembled the IPL . At the moment i'm in the process of clearing up, how the basic init process is working!
I nearly forgot to mention, that you'll need to update the description for the stepping of PXA270 in the OpenOCD source code. If i remember correctly, the C5 is missing. Without it the PXA is not recognized correctly. I will post the updated file tomorrow.
Stay tuned!!!
scholbert
scholbert said:
I also gathered together anything about the mDOC series i could find, all over the planet. If you need more details
Click to expand...
Click to collapse
Yes! Post it! Thank you! (or send them to rapidshare or similar).
scholbert said:
Just an additional information:
I successfully disassembled the IPL . At the moment i'm in the process of clearing up, how the basic init process is working!
Click to expand...
Click to collapse
A weird idea... What do you think about relocate and then recompile IPL and run it from SDRAM?
You should remove and/or modify IPL routines related to SDRAM init anyway!
Which tools are you using to decompile IPL?
Hi,
Yes! Post it! Thank you! (or send them to rapidshare or similar).
Click to expand...
Click to collapse
I will somehow. Maybe i'll put on my website or post it here!
Very busy at the moment .
A weird idea... What do you think about relocate and then recompile IPL and run it from SDRAM?
You should remove and/or modify IPL routines related to SDRAM init anyway!
Click to expand...
Click to collapse
The first attempt will be to enhance the JTAG config file with all that stuff i already found out, e.g. setup all GPIO, alternate functions .....
Relocate and compile would be nice too, but more work .
Which tools are you using to decompile IPL?
Click to expand...
Click to collapse
Someone in the forum pointed out to use radare. This was the starting point for further investigation.
At least radare uses objdump for disassembly.
So i decided to use the tools itself.
Here's a short howto:
How to convert raw arm binaries to elf and disassemble the code:
Although not every ARM code is compiled with the famous GCC (e.g. wince binaries) you may use some tools
of the GCC to convert raw binary code that is executable on ARM platforms.
Make sure that you made a real memdump or read out pure flash files from a known offset (reset entry points, direct jumps into code, etc).
In other words use pure binaries!!!
Otherwise this method won't work. It is nice to disassemble bootloader code for example.
Image files with filesystem information won't work, either!!
You'll need a working ARM cross compiler in this example the arm-none-eabi gcc version 4.2 from codesourcery was used.
1. first you have to build an elf-binary for ARM without offset (assumed 0x0) from the raw binary.
arm-none-eabi-objcopy -I binary -B arm -O elf32-littlearm ipl_0x0-0x800.bin ipl_0x0-0x800.elf
2. second simply disassemble the elf-binary!
arm-none-eabi-objdump -D ipl_0x0-0x800.elf > ipl_0x0-0x800.asm
That's it!
scholbert
Click to expand...
Click to collapse
Of course you need some skills to point out how assembler code is organized and you'll have to find out where ASCII strings are stored. If you don't check this everything looks like instruction code!
Regards,
scholbert
scholbert said:
Hi,
I will somehow. Maybe i'll put on my website or post it here!
Very busy at the moment .
Click to expand...
Click to collapse
Ok... I'll look forward for these documents! Thanks!
scholbert said:
The first attempt will be to enhance the JTAG config file with all that stuff i already found out, e.g. setup all GPIO, alternate functions .....
Click to expand...
Click to collapse
Great!
After my jtag will be fully functional, I'll try to do some experiments running IPL from memory...
scholbert said:
Of course you need some skills to point out how assembler code is organized and you'll have to find out where ASCII strings are stored. If you don't check this everything looks like instruction code!
Click to expand...
Click to collapse
I'm a little rusty... but I'll try!
Anyway I found a very great tool for disassembling arm code: IDA Pro v5.2
It is awesome.
Cheers,
roglio
Anyway I found a very great tool for disassembling arm code: IDA Pro v5.2
It is awesome.
Click to expand...
Click to collapse
Yeah i know. I once worked with the eval version.
Very nice piece of software, but no freeware.
Good luck for your experiments!!!
scholbert
IPL disassembled
Hi scholbert!
Attached you will find the IPL asm I've disassembled with IDA.
I hope it could be of some usefulness!
Cheers,
roglio
Hi,
roglio said:
Hi scholbert!
Attached you will find the IPL asm I've disassembled with IDA.
I hope it could be of some usefulness!
Cheers,
roglio
Click to expand...
Click to collapse
Great work!
Here's mine. As you will see it's very equal (at least it should be ).
I made some comments already, but it's not finished yet.
The structure can be seen already. It is soon possible to reconstruct the whole asm code and compile it .
scholbert
is it all necessary ?? more easy way in desoldering flash ... and program it or change to flash from dead device
@scholbert: wow you're always at least a step ahead!!!
Great!
@mo3ulla: hi! yes it is worth the effort because the chance to have skills to build a jtag connector is greater than have skills (and tools) to reball a bga chip (and program it!).
With jtag interface and a relocated IPL we can resurrect bricked uni simply loading it in ram and running. Then reflash the pda with a simple usb cable
Hi,
roglio thanks for the credits .
But at least this no competition, it's really great that someone took a look at this posting and started to discuss.
This goes out to you roglio .
mo3ulla said:
is it all necessary ?? more easy way in desoldering flash ... and program it or change to flash from dead device
Click to expand...
Click to collapse
When i started this topic, i thought about a way to de-brick some uni's without touching the hardware. So roglio is absolutely right!
Once tried reballing at home???
At least the major point is:
Why touch the hardware, when it's a software problem?
Obviously no one got a programmer for mDOC devices!
If the universal would have NOR flash all things would be less complicated.
So what we are doing here, is to replace a 10.000$ programmer.
These professional devices do the same in the end, they use software algorithm to programm these NAND flashes.
The SPL uses the same software parts to reprogram G3 NAND flashes, but to start SPL (get into bootloader menu), IPL is needed. On a heavily bricked device these parts are damaged.
If we setup the device like IPL does or recompile IPL to run from RAM using JTAG, it could be possible to start SPL and get into bootloader menu.
The rest is already described here ....
Regards,
scholbert
O.K., here's dump from the bricked uni.
The screenshot shows the IPL section. It seems to be IPL version 2.36 which is for devices with a G4 NAND.
Mine is a G3, so this is the reason why it got bricked.
Someone updated the bootloader with a wrong version .
I enhanced the config file for the JTAG debugger with the settings i found out by disassembling IPL version 0.36 (G3 devices).
But unfortunately no success. The SDRAM is not accessible .
Without SDRAM initialised, i am not able do download SPL to the platform.
grumbl....
I'll have to check all settings again.
Especially the SDRAM setup...........
No time for that at the moment.
Anyone who'd like to join our experiments????
Cheers,
scholbert
I've been reading the forums but the information seems fragmented. Is there a single source that describes the reset vector, bootloader start-end address, ram start address, etc.?
I'd like to either replace the bootloader if the current loader sources are not available or use the current loader to bootstrap a non-windows image.
I just need to understand the board bring-up basics.
Any help would be great.
After looking further I found the processor docs here: http://www.marvell.com/products/cellular/application/PXA27x.jsp
Anyone know if HP has a custom asic such that the addresses are not the same as what is listed in the processor doc?
What is the best jtag to use on this processor? I'd like to be able to flash and load to ram directly with the jtag.
unfortunately this is way too advance that I don't think anyone can answer you...
Beside tinker boot loader can really brick your device..I would rather figure out how does wm os image got load up. May be you can check other htc device forum in xda to see if any of them can load android directly without using another loader(haret) although I think right now haret is still the only option
Hello, I accidentally flashed my device on PVT Board with DVT firmware. Naturally, the tablet is no longer power on. Send me please a correct PVT dump for programmer. In advance, thank you very much.
attached... there's a risc processor inside the SoC that has anti-theft and firmware tpm technology so be careful at what you feed in your programmer
Thank you very much. But, if not difficult, write what exact tablet was this dump and how programmer.
crosstech said:
Thank you very much. But, if not difficult, write what exact tablet was this dump and how programmer.
Click to expand...
Click to collapse
it's not a dump, is the original firmware from Lenovo for 830 and 1050 models
do you have a hw programmer and if so what model? or you intent on buying one
All a little different. I passed the tablet to the service center and the master could not find a dump for the BIOS chip. All I know about the programmer, is the fact that it should support the flash mode at 1.8 volts.
However, plans to buy the programmer, if necessary.
crosstech said:
All a little different. I passed the tablet to the service center and the master could not find a dump for the BIOS chip. All I know about the programmer, is the fact that it should support the flash mode at 1.8 volts. However, plans to buy the programmer, if necessary.
Click to expand...
Click to collapse
he can use the file i attached, it was already used by many to restore their bios (with my restore kitkat bios tool for the 830-1050 models)
if he does in circuit programming he should leave the battery on and do a programming cycle, afterwards remove the battery connector then reconnect and now he can program (this is needed so that the processor hangs completely, the first time the programming will fail because the processor is still accessing at random times the bios together with the programmer, and the bios will have a bricked firmare, but after that if he removes then plugs back the battery then the processor will hang completely and this time programming will succeed
the thing is not only about the programmer but about your expertise in doing the job, the components are small and you will need the specific smd tools, a special connector that might not even connect as it was in my case due to the placement of the ic, so i had to solder very thin wires on the spi, all in all it's a risky job and you must have the know-how to do it. i am not discouraging you, just trying to say that if you have comeone who did this kind of stuff before let him do it.
Thank you very much for your advice. I will look for the wizard, if I don't, I will try myself. Although I had this experience only with laptops.
please help i also need to flash the bios as my 830LC wont turn on after OTA.
nsxt99 said:
please help i also need to flash the bios as my 830LC wont turn on after OTA.
Click to expand...
Click to collapse
could anyone tell how to differentiate PVT & DVT board?
i tear down my 830LC & found the bios contain in a 25Q64FW chip whereby its support by my RT809F programmer.
nsxt99 said:
could anyone tell how to differentiate PVT & DVT board?
i tear down my 830LC & found the bios contain in a 25Q64FW chip whereby its support by my RT809F programmer.
Click to expand...
Click to collapse
there are no PVT or DVT boards, those are manufacturing stages (PVT being the ready to ship one, while DVT is only used in factory). you can use the file in the zip i attached a few posts above.
is the programmer capable of programming at 1.8V? the FW and DW chips from WinBond are working at 1.8V nominal Vcc (with a peak transitory absolute maximum voltage of Vcc+1V = 2.8V) if it is a 3.3V programmer could cause issues (can work but it can also cause problems)
Hi,
Could anyone please re-post the BIOS file that ionioni attached before? Thanks so much!
find the attachment of BIOS file you want
serepok said:
Hi,
Could anyone please re-post the BIOS file that ionioni attached before? Thanks so much!
Click to expand...
Click to collapse
here attached
if need more help then attach pics with problem description.
Regards
Thank you so much @KAASHP
will this bios work on 1050? how do we apply it?
Thanks for your
Sage said:
will this bios work on 1050? how do we apply it?
Click to expand...
Click to collapse
This works for Lenovo Yoga 830 series. Also may be work on 1050 variant.
you can try it for your device probably it will not brick your device.
reply here if you succeed. good luck :good: