Database Develop

G1 Debug Mode

Hi Guys,
I just rooted my T-Mobile Unlocked G1.
After doing this I updates it with Jesusfrek 1.5 ADP.
I want to start learning to create Android application so I was trying to connect the G1 in USB Debug mode.
When the option is selected and connected to usb it does not recognise any new hardware.
On mounting I can view files in the memory card.
Without mounting also I can see Disk Drive>HTC Andoid Phone USB Device
I want to use the device to test my application.
Please help.
Please note: I have bought an unlocked G1 and not the Dev Phone.
Thanks,
Chinmay
Hey Got the problem Solved :
Problem - G1 Not detecting in Debug Mode / ADB Mode
Reason - Windows Automatic Driver Update for USB Disk.
Solution:
Edit the registry
Disclaimer: be careful what you do in regedit.
If you're not sure,don't use it
- Open the Registry Editor (Start > search/run > regedit)
- You *may* need to be administrator to do that
- Search for "vid_0bb4&pid_0c02" in keys or values. It makes take a
while. If you find in a value, delete the whole key folder.
- Some keys might be "locked": right-click them and add "everyone:
full control" to the permissions. Then delete the key folder.
- Repeat the search till no more instances are found.
- Close regedit.
Now the devices will ask for driver and locate the android-sdk\usb_driver\x86
There the phone is now in ADB Mode.
Solution
Click to expand...
Click to collapse

so are you saying if u put it in USB mode it disconnects and not be able to detect it as new device? if its not disconnecting, then its working fine... and go ahead and use adb mode

1st, do you have the SDK and drivers installed on your computer. 2nd, do you know what ADB is?

Start asking your questions in the right sub-forum (Q&A) (Theme) or even in (General), or i will be forced to ban you for 3 days or till you learn.
Thanks
Thread Trashed!!

Gilliland12 said:
1st, do you have the SDK and drivers installed on your computer. 2nd, do you know what ADB is?
Click to expand...
Click to collapse
Hi,
Yes I have the SDK Installed and the Environment variables set.
I dont have the Dev phone but I have the dev phone firmware updated on my T-Mobile G1.
Does it require a different cable.
I need to get the phone in debug mode so I can start testing my applications on the phone. Testing the app on the phone is netime better then the emulator.

You missed the 2nd part of question 1 and you didn't answer question 2.
Does 'adb devices' show anything?

G1 Debug
evilkorn said:
You missed the 2nd part of question 1 and you didn't answer question 2.
Does 'adb devices' show anything?
Click to expand...
Click to collapse
ADB shows no devices connected.
When I read the instruction on getting the G1 on Debug mode. It said that when you connect a new hardware would be detected then install the new hardware with the usb drivers in the SDK Tools. - this never happenes when I connect my phone. It does not detect as a new hardware
I can see removable disk in My Computer - if I try to access it says please insert disk. Files are not accessible without mounting the SD Card.
Instead of the Removable Disk being detected the phone should be detected in debug mode right ?

Have you turned on USB debugging in Settings>Applications>Development?

chinmayfun said:
ADB shows no devices connected.
When I read the instruction on getting the G1 on Debug mode. It said that when you connect a new hardware would be detected then install the new hardware with the usb drivers in the SDK Tools. - this never happenes when I connect my phone. It does not detect as a new hardware
I can see removable disk in My Computer - if I try to access it says please insert disk. Files are not accessible without mounting the SD Card.
Instead of the Removable Disk being detected the phone should be detected in debug mode right ?
Click to expand...
Click to collapse
you need to go to this thread it is how I got adb to work on my computer. just make sure instead of the old sdk it has listed make sure you have 1.5r3

Solution
Hey Got the problem Solved :
Problem - G1 Not detecting in Debug Mode / ADB Mode
Reason - Windows Automatic Driver Update for USB Disk.
Solution:
Edit the registry
Disclaimer: be careful what you do in regedit.
If you're not sure,don't use it
- Open the Registry Editor (Start > search/run > regedit)
- You *may* need to be administrator to do that
- Search for "vid_0bb4&pid_0c02" in keys or values. It makes take a
while. If you find in a value, delete the whole key folder.
- Some keys might be "locked": right-click them and add "everyone:
full control" to the permissions. Then delete the key folder.
- Repeat the search till no more instances are found.
- Close regedit.
Now the devices will ask for driver and locate the android-sdk\usb_driver\x86
There the phone is now in ADB Mode.

Do Vote
Let me know if this post has helped you !!

IMEI ****

hi i have cm 7.1 and restore it to stock
only my phone say wrong IMEI numer i try
1. Connect phone by USB
2. Enter 1809#*990# in dialer
3. Select Port Settings -> Select CP USB
4. Start hyperterminal, in COM settings select same port like in devide manager -> LGE mobile USB Serial Port, 115200
5. Type AT if response is not OK, change port number
6. Type at%imei, it should display your current IMEI
7. Type at%imei=x,x,x,x,x,x,x,x,x,x,x,x,x,x,x , where x,x,x... is your orginal IMEI number
8. Reset
step 1 2 3 is good and de rest i dont understand what i must do , cam some one help me ?

Hyper terminal is a tool normally pre-installed in windowsXP windows2000 etc allowing you to communicate raw data to a device via a COM port. (In the old days it could be used to connect to dialup modems etc which were plugged in via RS232 ports). I dont think it comes pre installed on windows 7 by default so you may need to manually install it.
In Win XP it can normally be found Start Menu -> All Programs -> Communications -> Hyper terminal or found here C:\Program Files\Windows NT\hypertrm.exe*
*Assuming you installed this windows component when windows was installed.
Hope this helps - good luck

Seem like one who doesn't know about Seagate Barracuda problems
Simply that's the last time i used one... just google the problem, and where the solution is should also be hyperterminal zips around there to for newer OS.
PUTTY should also work...

Cant Connect to PC

hello guys can you help me coz i cant connect my lg optimus 2x to my pc
when i connect my o2x is charging but my pc cant recognize it
i tried reinstalling drivers, change usb cable, change my OS from win7 to xp, flash stock rom ( cant flash because my pc cant recognize my o2x so i cant start flashing), use nvflash (my pc cant detect apx device)

brymarti said:
hello guys can you help me coz i cant connect my lg optimus 2x to my pc
when i connect my o2x is charging but my pc cant recognize it
i tried reinstalling drivers, change usb cable, change my OS from win7 to xp, flash stock rom ( cant flash because my pc cant recognize my o2x so i cant start flashing), use nvflash (my pc cant detect apx device)
Click to expand...
Click to collapse
please dont use any USB hubs...connect it to the USB port on the motherboard side....normally on the rear side for the Desk tops.....on the laptop all ports are directly connected normally...
secondly, what is your config? ROM?Kernel?please state your current configuration which can allow others to understand the situation.
Thanks

yeah i dont use usb hub i connect it directly i tried it on my laptop but its not working
my o2x dont say that usb debugging is connected it only charge
im on stock GB now 2.3.4 v20g

Don't want to hijack this thread, just got the same problem. (Not a complete noob here, rooted lots of different devices)
Bought a used 2x today. Froyo 2.2.2 german stock on it.
It just doesn't show the prompt that USB is connected
Tried:
- LG Mobile Driver from version 2.x.x up to 3.7.2
- on Win7 32 bit, Win7 64bit, Win XP 32 bit on various USB ports
- LG PC Suite obviously doesn't connect too
- checked/unchecked USB debugging, USB mass storage and all the obvious settings
- tried different cables
Would be really great if someone experienced could point us in the right direction.
EDIT:
After lots and lots of google I found out about a menu when dialing: 1809#*990#
With these options available:
CP Image Download
FET Disable
FET Enable
AP UART
CP UART
AP USB
CP USB
CP UART gave me at least a life sign once by saying that Windows wasn't able to recognize the device.
Is this issue really unsolvable?

Sorry for the bump, but I got some update.
when dialing the above mentioned 1809#*990# in the Port menu, switching from default AP USB to AP/CP UART gave me life signs.
After switching to AP UART I linked the Unknown device driver to lgusbdiag.inf located in C:/ProgramFiles(x86)/LG United Mobile Driver.
Suddenly it started installing it and is now recognized as: LGE Platform Android USB Device.
Once disconnected I lose USB again, I'm able to recreate the first steps though even in default AP USB mode by now.
The only thing I need USB for is for flashing a custom recovery but the only thing I don't have is ADB somehow : / Clockwork telling me: device not found.
Any help on this one?

any idea guys about my problem?

Have you tried my method?
After manually installing drivers with CP UART on, switching back to default permanently enabled access with default AP USB settings as well.

i tried that but it only charge
theres a weird thing in my cp when i switch to cp uart my o2x says it charging even i dont connect it to my pc or charge it

Ap uart - p990 / p999
I have LG P999. rooted and cyanogen.
None of the special DTMF dialing # codes is not working (also code changed from 990 to 999) (i sow some other in another posts)
is anybody know a way to change to AP UART by software (with eclipse...)
or with a special cable?
i need to use AP UART - meaning to have a serial com in AP(app).
Thanks,
Tamir

guys,
Have you tried to install MyPhone Explorer and try the same....it can connect your device via wifi,USB or Bluetooth....so some way should work....
any Android version above Froyo(included) should work....I use this always...one of very useful and bug free apps.
Try it

Heimdall Firmware detect error guide.

Information is hard to find nowadays. Finding the info you need is one thing, but comprehending it can be difficult sometimes. Since I came from a military background, I like to do the same here and hopefully answer all your Heimdall curiosity.
HEIMDALL IN GENERAL
I consider it as Odin evil twin. Simply just 2 different operating personality. In this case, Odin uses Window, and Heimdall uses Linux
Will not work without a proper USB software. Odin uses manufacture that either achieve through your Samsung devices, Kies or Samsung. Hiemdall uses Zadig to configure it USB port channel.,
Last requirement. Correct operating system with the most compatible version for your system. (Mac-note3), (S3-win) etc.. Newer isn't always better. Check with developer website to get the correct version along with others require adds on for your system.
Extra Note: When verifying if you are using the correct Heimdall for your computer, make sure you right click on Heimdall Front End and go into properties. Just because you downloaded for Win/Mac doesn't mean the setting are set to a specific OS. Should you have to make changes, make sure you restart your computer or restart the application (advance user) for changes to take place[/B]
ATT GLX NT3 HEIMDALL
USB you need will be MSM8960. This is the Linux code for your phone download mode. If you are able to locate and install this on Zadig, then the problem is not at your USB port. *Note: There are more than one driver within MSM8960. The recommended dr is not always the working one. Don't forget to check out the others. (Libusb, winucd, etc)
Heimdall is running as device Admin. This step doesn't make much difference. If you are troubleshooting, I would consider every single possibilities.
Make sure your download mode is listing the correct firmware for your device. People do bad flash, wrong installation, all kind of mix and match. If you somehow, got the wrong version of download mode into your operating system, or viceversa. You're on your own.
Hiemdall is a Linux program, so if you're familiar with ADB and already have that setup on your OS. You won't even need to go through the USB process for detection. ADB is a better method for Heimdall, but i'm not a Linux guy. So when my device wasn't detecting. I had to try a lot of different method. And that's when I came up with the 3 basic requirement.
Along with the basic, there are a few others thing you can look at should you're still unable to connect.
1. Only one can be use between Heimdall and Odin. If your Odin com port is connected, then you need to install/re-install usb for heimdall, or it not config correctly. It's easier for ODin to detect your phone since it is working directly with phone device. Not so much with Heimdall, since you have to fetch all the right tools to get it to work.
2. Most detection issues should be fix by correcting to the proper Usb drive, and the correct Heimdall version for your phone. Also, try to get the software from the Heimdall website.
TROUBLESHOOT PERTAIN TO evilpotatoman Restore for MJ5--Doesn't trip Knox post
1. I had to run HD front end as admin
2. Change the operating system within HD front end properties to my comp OS.
3. Finally got the device to detect, but it wasn't the right driver because HD was not able to flash files to my phone.
4. Open Zadig again, and navigate to( Libusb 1.2.5) and install the driver under MSM8960.
MSM8960 has 3 driver within it. One of the is Window something, and the other 2 is the Libusb. The window driver doesn't always work, so try the others if it gives you a problem. In my case, I had to install libusb and that got me to complete the rest of the process on the tutorial.
Hopefully this help, or at least provide you with better details so you can guide your self to the solutions.
Don't forget to thank.

[Workshop] Unbrick fully bricked I9070

Hi,
I'm launching this thread to work on an unbrick procedure for fully bricked I9070/P without JTAG or Riffbox (same as Adam Outler, TheBeano, Odia etc... 's project "let's save some bricks")
Reminder : fully bricked = no download/recovery mode, no display, not charging, not going to recovery with a 301k Ohm jig.
I have a fully bricked I9070P and a fully functionnal I8090 (same processor).
Based on the sources and tools for the U8500 that were disclosed in january, I've managed to make my dead phone and my PC talk "a bit" together (under Windows with the VSIW tool, and under linux with recompiling the "flashkit" tools): when plugged in and inserting the battery, the tool sees the terminal, gets its serial number and various data and fails while trying to send and execute a boot file because the terminal closes the USB port.
I've managed to get a certain degree of communication with the "riff" tool (open source) of the Snowball project too (the dev board based on a U9500).
Based on this half successes, I'm pretty sure we are close to a clean solution to revive a fully bricked terminal without soldering JTAG.
Here are the main docs I've read so far :
* most posts from the threads "let's save some bricks" and "fun with resistors"
* the reference documents of the I9070 (Samsung_GT-I9070_Galaxy_S_Advance_Galaxy_S_II_Lite_service_manual.rar)
* the reference manual of the U9500 (http://www.calao-systems.com/reposi...X/DATASHEETS/AP9500_reference_manual_rev1.pdf)
* TSU6111 datasheet from TI (the USB/UART switch the 9070 is using, cf the service manual -> Lite Schematics -> u-USB SW IC part)
* lots of docs from the "flashkit" sources
My setup :
* a fully bricked I9070P
* a fully working I8190P
* an 8GB SDCard
* a Windows/Linux workstation (Ubuntu 12.04LTS + Android compiling environment + disclosed sources)
* terminal emulators
* a Prolific cable (PL2303) (any USB to TTL adapter would do it, you can buy one for 3$ as Arduino accessory, or reuse a Nokia DKU 5 -see hackaday website for a link). Take care with Prolifics : they don't work under Windows 8 with the last driver, you have to use the version before, Google is your friend)
* a set of resistors
* a multimeter
* libusb win32 drivers setup, see sourceforge (use the tool included in the drivers package to generate the right .inf file for the U8500 (or use 04CC and 8500)
Here are my conclusions so far :
* based on the Snowball docs and the U9500 spec, we don't seem to have any need to modify anything (resistors) on the mainboard to change boot sequence. The dev board does not have any switch for that and my dead I9070 and working I8190 exibit the same behaviour at bootup : the appear as a "U8500 USB ROM" for a seconds and disconnect when going on farther in the boot sequence.
Moreover, the fact that I managed to have my dead phone talk with the flashtool confort me in the fact that we are almost done.
* I have *not* managed to get any output on my terminal with my Prolific cable plugged in with a 630kOhm resistor on the pins 4 and 5. My resistor setup might be good because it make my working I8190 boot when I plug it in.
But I'm not sure of my RX/TX setup, I have crossed the RX/TX of the phone and the ones of the Prolific but I might have been wrong identifying the pins of my modified USB plug (D+ and D-).
But I'm sure the RX and TX wires of my Prolific are the right ones : when I connect them together (nullmodem configuration), the characters typed on my terminal are displayed.
So the main issue is : how can we have the dead phone keep the USB port open and not close it after 2 seconds?
My assumption is that it is always probing different boot methods (UART, USB, MMC etc) and then attempts to boot normaly from eMMC.
I don't know which part of the bootchain sequence I've garbaged on my I9070: IBL, PBL, SBL, PARAM? Managing to get any debug output on my console would greatly help me.
Has any of you tried to achieve something similar? If yes, could you post your setup and results?
Let's save some bricks another time!

any progress
flentus said:
Hi,
I'm launching this thread to work on an unbrick procedure for fully bricked I9070/P without JTAG or Riffbox (same as Adam Outler, TheBeano, Odia etc... 's project "let's save some bricks")
Reminder : fully bricked = no download/recovery mode, no display, not charging, not going to recovery with a 301k Ohm jig.
I have a fully bricked I9070P and a fully functionnal I8090 (same processor).
Based on the sources and tools for the U8500 that were disclosed in january, I've managed to make my dead phone and my PC talk "a bit" together (under Windows with the VSIW tool, and under linux with recompiling the "flashkit" tools): when plugged in and inserting the battery, the tool sees the terminal, gets its serial number and various data and fails while trying to send and execute a boot file because the terminal closes the USB port.
I've managed to get a certain degree of communication with the "riff" tool (open source) of the Snowball project too (the dev board based on a U9500).
Based on this half successes, I'm pretty sure we are close to a clean solution to revive a fully bricked terminal without soldering JTAG.
Here are the main docs I've read so far :
* most posts from the threads "let's save some bricks" and "fun with resistors"
* the reference documents of the I9070 (Samsung_GT-I9070_Galaxy_S_Advance_Galaxy_S_II_Lite_service_manual.rar)
* the reference manual of the U9500 (http://www.calao-systems.com/reposi...X/DATASHEETS/AP9500_reference_manual_rev1.pdf)
* TSU6111 datasheet from TI (the USB/UART switch the 9070 is using, cf the service manual -> Lite Schematics -> u-USB SW IC part)
* lots of docs from the "flashkit" sources
My setup :
* a fully bricked I9070P
* a fully working I8190P
* an 8GB SDCard
* a Windows/Linux workstation (Ubuntu 12.04LTS + Android compiling environment + disclosed sources)
* terminal emulators
* a Prolific cable (PL2303) (any USB to TTL adapter would do it, you can buy one for 3$ as Arduino accessory, or reuse a Nokia DKU 5 -see hackaday website for a link). Take care with Prolifics : they don't work under Windows 8 with the last driver, you have to use the version before, Google is your friend)
* a set of resistors
* a multimeter
* libusb win32 drivers setup, see sourceforge (use the tool included in the drivers package to generate the right .inf file for the U8500 (or use 04CC and 8500)
Here are my conclusions so far :
* based on the Snowball docs and the U9500 spec, we don't seem to have any need to modify anything (resistors) on the mainboard to change boot sequence. The dev board does not have any switch for that and my dead I9070 and working I8190 exibit the same behaviour at bootup : the appear as a "U8500 USB ROM" for a seconds and disconnect when going on farther in the boot sequence.
Moreover, the fact that I managed to have my dead phone talk with the flashtool confort me in the fact that we are almost done.
* I have *not* managed to get any output on my terminal with my Prolific cable plugged in with a 630kOhm resistor on the pins 4 and 5. My resistor setup might be good because it make my working I8190 boot when I plug it in.
But I'm not sure of my RX/TX setup, I have crossed the RX/TX of the phone and the ones of the Prolific but I might have been wrong identifying the pins of my modified USB plug (D+ and D-).
But I'm sure the RX and TX wires of my Prolific are the right ones : when I connect them together (nullmodem configuration), the characters typed on my terminal are displayed.
So the main issue is : how can we have the dead phone keep the USB port open and not close it after 2 seconds?
My assumption is that it is always probing different boot methods (UART, USB, MMC etc) and then attempts to boot normaly from eMMC.
I don't know which part of the bootchain sequence I've garbaged on my I9070: IBL, PBL, SBL, PARAM? Managing to get any debug output on my console would greatly help me.
Has any of you tried to achieve something similar? If yes, could you post your setup and results?
Let's save some bricks another time!
Click to expand...
Click to collapse
dude did you find any solution??same problem here

up up this thread.... i'm also experiencing with my s3 mini i8190 continuously disconnecting libusb-win32 driver... my phone is at deadboot and unable to resurrect with RIFFBOX...

neilPD_07 said:
up up this thread.... i'm also experiencing with my s3 mini i8190 continuously disconnecting libusb-win32 driver... my phone is at deadboot and unable to resurrect with RIFFBOX...
Click to expand...
Click to collapse
Mebay u have dead mini USB port in SIII mini ?
Sent from my GT-I9070 using Tapatalk

Hi guys,
I had a little time playing with this, but I have good news :
I modified the default profile used for the flashtool backend to "ADL boot" : my "dead" phone now stays connected to the USB and is reported as "started" by the flashtool CLI ("flash-tool get_connected_equipments") however, when I try some "active" flash-tool CLI commands, the backend crashes.
As I was running it either in windows 8.1 64 bits or Linux in a VM, their might have some bad interactions with the OS on the one hand and the USB port forwarding on the other hand (there was issues with the LCD and LCM drivers in Windows, I grabbed the 64 bits ones from VSIW...).
-> I have to test on a 32 bit Windows.
Good to read to understand further (extracted from flash-tool-backend.html file) :
Note : ME stands for mobile equipment, "boot indication" can take the following values : ADL, ALT, Normal, Production, Programming : set into the config files pointed by the .mesp file)
Boot process description
When the peripheral boot sequence starts, the ME sends an asic id to the connected PC tool. The PC tool then answers with a boot indication. If normal, "ADL" or "production" is sent as boot indication; this means that the x-loader will start the binary software stored at the corresponding location in the boot image (based on the location stated by the TOC). If programming is used as boot indication, the PC will send a completely new set of boot code to the ME. This is used when a loader is downloaded during service mode startup via the Flash Tool Backend. When the normal boot indication is sent, Flash Tool backend sends no more data and the ME is booted with the binary software stored in the place where the normal software is stored according to the TOC.
The ADL boot scenario works like this:
1. Flash Tool Backend receives asic id
2. Boot indication ADL is sent
3. Flash tool backend starts LCD and LCM and waits for a loader startup message.
The loader is stored at the ADL location of the boot image (this is supported by the assemble tool).
I think I'd have to assemble the correct bootloader to enable "profile-STE_DBX500_flashloader.prfl" profile to work (we are missing corresponding loader.ldr loader). It would enable the use of the "LoaderCommunication"
I think I have all the pieces and the docs (we even have the certificates to sign it !): just need time and a better GFAF (Girlfriend acceptance factor).
The guys who managed to unbrick some Qualcomm based devices might be of a huge help, they would be much more efficient than I can be... I any of you have time to drive them around here, do not hesitate!
Enjoy!

flentus said:
Hi guys,
I had a little time playing with this, but I have good news :
I modified the default profile used for the flashtool backend to "ADL boot" : my "dead" phone now stays connected to the USB and is reported as "started" by the flashtool CLI ("flash-tool get_connected_equipments") however, when I try some "active" flash-tool CLI commands, the backend crashes.
As I was running it either in windows 8.1 64 bits or Linux in a VM, their might have some bad interactions with the OS on the one hand and the USB port forwarding on the other hand (there was issues with the LCD and LCM drivers in Windows, I grabbed the 64 bits ones from VSIW...).
-> I have to test on a 32 bit Windows.
Good to read to understand further (extracted from flash-tool-backend.html file) :
Note : ME stands for mobile equipment, "boot indication" can take the following values : ADL, ALT, Normal, Production, Programming : set into the config files pointed by the .mesp file)
Boot process description
When the peripheral boot sequence starts, the ME sends an asic id to the connected PC tool. The PC tool then answers with a boot indication. If normal, "ADL" or "production" is sent as boot indication; this means that the x-loader will start the binary software stored at the corresponding location in the boot image (based on the location stated by the TOC). If programming is used as boot indication, the PC will send a completely new set of boot code to the ME. This is used when a loader is downloaded during service mode startup via the Flash Tool Backend. When the normal boot indication is sent, Flash Tool backend sends no more data and the ME is booted with the binary software stored in the place where the normal software is stored according to the TOC.
The ADL boot scenario works like this:
1. Flash Tool Backend receives asic id
2. Boot indication ADL is sent
3. Flash tool backend starts LCD and LCM and waits for a loader startup message.
The loader is stored at the ADL location of the boot image (this is supported by the assemble tool).
I think I'd have to assemble the correct bootloader to enable "profile-STE_DBX500_flashloader.prfl" profile to work (we are missing corresponding loader.ldr loader). It would enable the use of the "LoaderCommunication"
I think I have all the pieces and the docs (we even have the certificates to sign it !): just need time and a better GFAF (Girlfriend acceptance factor).
The guys who managed to unbrick some Qualcomm based devices might be of a huge help, they would be much more efficient than I can be... I any of you have time to drive them around here, do not hesitate!
Enjoy!
Click to expand...
Click to collapse
Any good updates & tested solution sir? I'm still waiting for a big solution for this kind of problem... TIA

Hi !
well, I'm almost done with the bootloaders: I have a loader.ldr compiled + 2 bin.
I've reset my dev. env. to an Ubuntu 10.04 according to a .doc I found in the sources (search for "*.doc", you will find "getting_Started_with_Android_and_Linux.doc"): I now have far less compilation errors, but I'm still struggling to get the full compilation process just right. For eg. I had to remove the "alsactrl" component due to dependency issues I've not been able to solve.
As already stated, I'm far from being a dev. expert so it takes me a lot of time to acheive the right compilation.
I would highly need the help of s/b who is fluent with Android compilation/dev env.: first it would be necessary to establish how to merge correctly the disclosed sources with Google's sources + the open sources from Samsung (kernel + system) (we have duplicates here as the kernel is also available in the disclosed sources, but both are different releases).
As already stated, given the few spare tile I have and without the help of the right people this will take me ~4 months+ to have this unbrick done (if I face no deadlock).
So, if you want this faster: get the right guys on the forum (from the "dev" branches) and drag them here so we can go forward much faste!

Hi!
So, I think I'm getting close: I now have the boot files build procedure working (+kernel and sytem, but I don't need those).
When I try to boot my phone with those boot files using the "flasher -tXXXX -X0,normal.bin" command, it seems that they are rejected as the phone connects and disconnects (boot loop on the iRom startup, I believe).
So, now I really need to have some kind of debug console setup to understand what's going on (cause of rejection, like signature problem etc...):
I've been working blindly up to now hopping that the software would work "off the shelves"... it never does
I'll have to try to understand how the "trigger UART" parameter of flashkit backend works and what is it intended to (I'll have to read the code for that as I've never seen any explanation about it anywhere in the docs). I don't figure out how this could work as on the backend GUI it lists the host PC's serial ports...
Another option would be to have my FTDI debug setup working. Maybe it's not "another option" but is required if the "trigger UART" is just enabling UART debug on the phone and requires a debug cable to read these debug data. My problem in that case would be how to have USB *and* UART on the same port... unless all this is designed for dev targets that have 2 USB ports as the Calao's u8500 targets. In that case, i'd have to find something smarter
As usual, if someone with knownledge on all this is willing to help: wave your hand, I'd happy to share my researches and go forward much faster. But I really feel I'm alone on this (even if I know that there will be tons of leechers when/if I manage to have this work
That's life on XDA!

Nice nice
flentus said:
Hi!
So, I think I'm getting close: I now have the boot files build procedure working (+kernel and sytem, but I don't need those).
When I try to boot my phone with those boot files using the "flasher -tXXXX -X0,normal.bin" command, it seems that they are rejected as the phone connects and disconnects (boot loop on the iRom startup, I believe).
So, now I really need to have some kind of debug console setup to understand what's going on (cause of rejection, like signature problem etc...):
I've been working blindly up to now hopping that the software would work "off the shelves"... it never does
I'll have to try to understand how the "trigger UART" parameter of flashkit backend works and what is it intended to (I'll have to read the code for that as I've never seen any explanation about it anywhere in the docs). I don't figure out how this could work as on the backend GUI it lists the host PC's serial ports...
Another option would be to have my FTDI debug setup working. Maybe it's not "another option" but is required if the "trigger UART" is just enabling UART debug on the phone and requires a debug cable to read these debug data. My problem in that case would be how to have USB *and* UART on the same port... unless all this is designed for dev targets that have 2 USB ports as the Calao's u8500 targets. In that case, i'd have to find something smarter
As usual, if someone with knownledge on all this is willing to help: wave your hand, I'd happy to share my researches and go forward much faster. But I really feel I'm alone on this (even if I know that there will be tons of leechers when/if I manage to have this work
That's life on XDA!
Click to expand...
Click to collapse
U R great man..UP UP UP :good::good::good:

use UART debug on USB
This will help me, I'll test it on my working S3 mini (same proc and very similar HW)... when I have time...
-> this will validate my UART debug setup : http://forum.xda-developers.com/showthread.php?t=2100809

ok, UART debug up and partially running on my SIII mini: debug messages displayed on terminal but keystrokes do not reach the phone, this is secondary for me at the moment, I may have a bad contact somewhere.
Tested on my dead I9070: no display, so the Xloader on my eMMC is garbaged (or Xloader UART debug is disabled, but this is less likely).
As expected, I now have to figure out how to have flashloader boot files upload *and* debug working together to understand what's wrong with my compiled boot files. I think the "trigger UART" thing is a good track, but I'm really puzzled by how to have the USB *and* the UART setup at the same time.
I fear to fry something by having phone D+/D- connected to USB port of the PC and connected at the same time to my Prolific TxD/RxD + 5V VCC connected to PC USB... sounds like a bad thing.
Another track would be USB debug I see in some parts of the code, but I don't know how to read the debug from there, more code to inspect...

got it~
---------- Post added at 02:03 PM ---------- Previous post was at 01:22 PM ----------
I also have a fully bricked I9070( not I9070P).I`m waiting for your good news.Thanks first.

I received this PM, I believe it can be useful for others experimenting with it
flentus said:
Ola Paul,
I contact you on an advise from Cocafe.
I launched a while ago the thread "[Workshop] Unbrick fully bricked I9070" (http://forum.xda-developers.com/showthread.php?t=2701363)
I'm looking for help to acheive the task as I don't have very much time to spend on it due to huge work I have this year.
Would you be ok to participate if you have a little spare time and interest in it?
I think I'm very close to the solution, and this would help a lot of 9070 owners (and maybe SIII mini and Sony too).
As explained in my thread, I have difficulties getting the disclosed sources to build correctly up to the end when integrated with Google SDK. As a result the "finalizing" scripts (that gather the binaries and tidy the "out" directory) don't execute: I end up with a large mess and STE tools don't work out of the box. I have to gather the pieces one by one to have them run which is very time consuming and error prone.
I can say that the recovery process won't need any kind of soldering, wiring or whatever: just a regular USB cable and the right sofware.
The disclosed sources contain everything we need: PBL/SBL sources, signing tool+certificates, the software to talk to the iROM + various documentation.
The problem is just a question of assembling the pieces...
My idea is to assemble an Xloader (PBL) + Uboot (SBL) + recovery and boot from that to execute recovery.
The "flashkit" tool enables this process, I quote the docs: "If 'programming' boot indication is used as boot indication, the PC will send a completely new set of boot code to the ME. This is used when a loader is downloaded during service mode startup via the Flash Tool Backend.".
Tell me if you wish to help me, or if you know someone who has competencies and would wish to!
I speek average spanish if you prefer to exchange in this language.
Regards
Click to expand...
Click to collapse
I am sorry for pointing this out, STE tools wont work ever on i9070, the reason being that we do not have a STE bootloader, heck, most of the low level stuff do not resemble the ST-Ericsson Montblanc development board. You can't even change the bootloader arguments, you can only add to them (the way I first enabled SELinux), the Samsung Bootloader version that we have may be not as restrictive as others, but Sonys bootloader resembles more to STE's than ours.
The only way you may found how to restore it is accessing the JTAG mode (something that is determined only if JTAG is connected and recognized) and depends solely on the emergency bootloader (if that exists, because I am not sure how the device powers on without PBL), the "seconds" of power you get on the USB is the device looking for JTAG.
The "disclosed" sources are for ST-Ericsson devices
Something you should do, is analyze the structures of /dev/block/mmcblk0p10, which contains our partition table (GUID Partition Table - GPT).
Simple way of doing it, you have to do dd if=/dev/block/mmcblk0p10 of=/sdcard/janice.pit on terminal emulator, this is ROM agnostic, because the structures are the same on both stock and any custom ROM. Of course, that is from a working device, I'll do that and drop it here later since I am working on something else right now, and thanks diegoch for discovering this.
Anyway, as diego pointed to me, our partition table is like this.
PIT, CSPSA, EFS, MODEM fs, SBL, SBL2, PARAM, IPL modem, MODEM, Kernel, Kernel2, system, data, cache, preload, fota, sdcard
This is the correct order I believe, since basically, when you use ODIN and use a PIT file, the partition table gets rewritten according to whatever is on that .pit file. So PIT is basically the GPT partition table; obviously SBL is the Samsung bootloader, and SBL2 I believe it's either stage 2.5 or a backup of the first.
So, no clue by going the STE way, something familiar here.
So, I may say something good at the end, see if the i9100 guys ever did it, and go from there, since our device is largely based around i9100 (Galaxy S II)

Hi Paul,
thanks for your contribution.
A few replies/questions :
* you state that Montblanc dev board and I9070 are completly different: isn't the aim of dev dev board to be close to ME while adding extra connectors to ease debug and interfacing for prototyping? Calao dev board looks very close to I9070: I have compared the schematics and component list: they look very very much alike. For me, NovaThor U8500 plateform consists of a DB8500 SoC, a Mali 400, a built-in modem + chips for USB, audio and SIM operations.
So, to me, I may be wrong, at least the processor (u8500), PLL, eMMC, SDRAM, UART + several low level controlers should be the same. As we are trying to work at such level (just trying to get the basic system to boot to just enable eMMC write), don't we have a chance to manage to have those work (maybe with adressing adaptation, those might be tough)?
* I can't agree with you that "the "seconds" of power you get on the USB is the device looking for JTAG.": on boot time, even without trashed PBL, the ME connects to USB properly with vendor/ID=04cc/8500, and sends its ASIC ID (displayed on PC screen). As stated earlier in the thread, I manage to send some commands and receive response from the ME in this state using STE tools (flashkit_cli, sending commands threw flashkit_backend).
It's definetly not any JTAG stuffs. JTAG on the I9070 is accessible on the mainboard via dedicated pads, you can locate using the light schematics provided in the "Service manual" package.
This early boot behaviour is documented in the "flash-tool-backend.html" document (available in s-4.1_vendor_st-ericsson.tar in ./s-4.1_vendor_st-ericsson/vendor/st-ericsson/tools/platform/flash_kit/flash_tool_backend/com.stericsson.sdk.backend.build/doc):
Boot process description
When the peripheral boot sequence starts, the ME sends an asic id to the connected PC tool.
The PC tool then answers with a boot indication.
- If normal, ADL or production is sent as boot indication; this means that the x-loader will start the binary software stored at the corresponding location in the boot image (based on the location stated by the TOC).
- If programming is used as boot indication, the PC will send a completely new set of boot code to the ME. This is used when a loader is downloaded during service mode startup via the Flash Tool Backend.
- When the normal boot indication is sent, Flash Tool backend sends no more data and the ME is booted with the binary software stored in the place where the normal software is stored according to the TOC.
The ADL boot scenario works like this:
1. Flash Tool Backend receives asic id
2. Boot indication ADL is sent
3. Flash tool backend starts LCD and LCM and waits for a loader startup message.
The loader is stored at the ADL location of the boot image (this is supported by the assemble tool).
* If I understand well, as we don't have the sources for the bootloader, your proposal is to grab one from a working device.
That sounds a really good idea!
Here is the complete partition table/PIT of the I9070 (recovered by someone with a Riff box from a GB archive, if I remember well):
(copy/paste it in a traditional editor and add padding to recover the table).
Partition number Filename in archive Name in PIT starting offset HEX Size in bytes HEX
MBR, GPT 0 20000
STE_boot.bin TOC ISSW XLOADER 20000 60000
mmcblk0p10 GT-I9070P_EUR_XX_8G.pit PIT 80000 100000
mmcblk0p6 cspsa.img CSPSA FS 180000 180000
EMPTY 300000 100000
mmcblk0p7 EFS.img EFS 400000 A00000
mmcblk0p2 modemfs.img MODEM FS E00000 100000
mem_init.bin STE MEM INIT 1E00000 80000
power_management.bin PWR MGT 1E80000 80000
mmcblk0p14 normal.bin SBL 1F00000 200000
mmcblk0p16 normal2.bin SBL_2 2100000 200000
mmcblk0p1 param.lfs PARAM 2300000 1000000
mmcblk0p12 ipl.bin IPL MODEM 3300000 200000
mmcblk0p13 modem.bin MODEM 3500000 1000000
mmcblk0p15 kernel.bin KERNEL 4500000 1000000
mmcblk0p17 kernel2.bin KERNEL2 5500000 1000000
mmcblk0p3 system.img SYSTEM 6500000 26400000
mmcblk0p5 userdata.img DATAFS 2C900000 80000000
mmcblk0p4 cache.img CACHEFS AC900000 13200000
mmcblk0p9 hidden.img HIDDEN BFB00000 14000000
mmcblk0p11 ssgtest.img FOTA D3B00000 3200000
mmcblk0p8 ums.rfs UMS D6D00000 FAA00000
--> PBL corresponds to "TOC ISSW XLOADER" (STE_boot.bin in the flash archive) and SLB to normal.bin. So basically we have our boot files. We can extract them from the GB flash archive or from a ROM dump (I have dd'ed every partitions from 2 different I9070P + a full recovery dump from a 9070 provided by Riff box support files I found once I don't remember where).
So, if I have time one of theses days, I'll try to build a flash archive based on these files and try to boot from STE tools on it using "programming" as boot indication.
* Using the knowledge of the I9100 (Galaxy S II): I'm afraid this is a very different hardware, I9100 uses an Exynos 4210, so I hardly see what we could use from there... Could you give us some more advise on that idea?
Regards

Hi!
I had no time working on this for a while: extremely busy at work.
Maybe this weekend...
@cocafe: I've read you know how to extract the initramfs from the kernel, modify, repack, and reflash it. I'll need to do that to modify the "on boot" section of the init.rc to launch the recovery from standard boot. Could you drop me here the command lines to do that? Thanks in advance!

This looks by far the most advanced research into bringing back a hard bricked i9070.
@flentus Did you manage to upload a new bootloader?

Hi,
had to time at all to play with this for a loooong time.
I have grabed a few new phones so me 9070 is now burried deep into a drawer but I really wish to finish this one day because I feel I'm very close to something.
If anybody would like to take over this, feel free, I can provide support for the stuff I have understood (and remember of...)
Regards