Related
I'm considering getting an N1 and I would like to be able to encrypt files; a blog post titled "Android + encryption on the G1 using cryptsetup and LUKS" (I can't post links) seems to indicate that I could get LUKS encryption to work. Would that cross-compilation procedure result in a working binary for a rooted N1?
Secondly, would it be possible to present the unencrypted block device to a USB host over USB mass storage? I'd like to be able to view the encrypted files on a Windows computer without installing anything extra or typing any passwords into an untrusted computer.
I would like to note that I found this to be possible with my current WM6 Standard smartphone using a recompiled version of FreeOTFE4PDA and WM5torage.
Had another thread going about getting my Moto X from Sprint Rooted. I did get the bootloader unlocked, but the problem I have now is that when I plug in the device via usb, it only connects as a camera. I can't find the setting that makes the device look like a disk drive so I can push adb files and stuff to it.
I can't get the thing rooted to save my skin. I'm pretty sure I have the camera update, and I have rooted other devices. It used to be with the EVO 4g that when connected via usb, the device would give you options. I do have usb debugging enabled.
Is there a setting I'm missing?
Kidjoe, sorry for starting another thread but I think the inability to copy files to my device is the source of the problem. Was going to try PwnmyMoto first per the instructions, but all I get is that it shows up as a camera, not as a usb device.
Where's the setting I'm missing?
bullpen7979 said:
Had another thread going about getting my Moto X from Sprint Rooted. I did get the bootloader unlocked, but the problem I have now is that when I plug in the device via usb, it only connects as a camera. I can't find the setting that makes the device look like a disk drive so I can push adb files and stuff to it.
I can't get the thing rooted to save my skin. I'm pretty sure I have the camera update, and I have rooted other devices. It used to be with the EVO 4g that when connected via usb, the device would give you options. I do have usb debugging enabled.
Is there a setting I'm missing?
Kidjoe, sorry for starting another thread but I think the inability to copy files to my device is the source of the problem. Was going to try PwnmyMoto first per the instructions, but all I get is that it shows up as a camera, not as a usb device.
Where's the setting I'm missing?
Click to expand...
Click to collapse
you can push adb when the phone is connected as a camera. To connect it via ptp, you just scroll down your notifications bar and click on the usb notification, you can switch to ptp there. But like i said, adb works when connected as a camera device, so you are doing something incorrectly with adb. Possibly the commands you are running. The OS for your computer might be causing the problem (but that would mean oyu have the wrong stuff downloaded to adb with the computer set up you are using). You don't have the correct drivers. You are using a faulty data cable. you are using a usb 3.0 port that isn't compatible. it is an endless list. Also, you can copy stuff to your device in camera mode as well.
also would like to note that whether you phone is rooted or not has nothing to do with your ability to use adb or push files to your phone.
finally, this is a question which should go under q&a not the general discussion subforum.
I am able to plug phone in and get this:
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\xxxxxxxx>adb devices
List of devices attached
T063202TFL device
C:\Documents and Settings\xxxxxxxxx>
Right click on computer/manage and I see android phone in list of devices there.
I was able to use this same data cable to unlock the bootloader. If it were faulty, I don't think I could have done that.
I have tried both usb ports on front and back of the desktop unit, as well as those on a netbook I have in tow. Same result everywhere.
I don't know what to do next.
The thing that sucks is it has to be something simple.....
Seriously. I'd paypal someone to help me out here. I just can't imagine what's going wrong.
bullpen7979 said:
I am able to plug phone in and get this:
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\xxxxxxxx>adb devices
List of devices attached
T063202TFL device
C:\Documents and Settings\xxxxxxxxx>
Right click on computer/manage and I see android phone in list of devices there.
I was able to use this same data cable to unlock the bootloader. If it were faulty, I don't think I could have done that.
I have tried both usb ports on front and back of the desktop unit, as well as those on a netbook I have in tow. Same result everywhere.
I don't know what to do next.
The thing that sucks is it has to be something simple.....
Seriously. I'd paypal someone to help me out here. I just can't imagine what's going wrong.
Click to expand...
Click to collapse
so whats the problem. you have adb working. What do you mean you can't copy things to the phone. What error do you get when you try to push a file to the sdcard on the phone? You see your phone in the list of devices so you can put files on it that way too. Really confused at your dilemma.
you trying to root? you trying to push files to the phone? IDK, but you clearly should be able to push them if you have adb running. Perhaps you aren't running the right commands to push files to your phone.
Don't you have to have USB debugging on?
Sent from my XT1060 using Tapatalk
bullpen7979 said:
I am able to plug phone in and get this:
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\xxxxxxxx>adb devices
List of devices attached
T063202TFL device
C:\Documents and Settings\xxxxxxxxx>
Click to expand...
Click to collapse
Unless you have another android device connected to your computer, your X has USB Debugging mode turned on, and Windows & ADB properly sees your phone.
As jayboyyyy posted, in this state you can use ADB to push files from the PC to phone, or pull files from the phone onto the PC, assuming you are using the right commands. But if all you are looking to do is copy files back and forth, this is overkill as you can do it with windows. ADB is usually only need for hacking and flashing your phone.
As I said in the other thread... Please include what you were doing and what the results are. You haven't given us a complete enough of a picture to understand 1. what you are trying to do. 2. Any/all steps you have taken. 3. EXACT error message you are receiving.
From your first sentence in the original post in this thread you say you are rooted and have unlocked your boot loader. But your second paragraph starts saying you can't get the thing rooted to save you life.. So which is it? Are you rooted or trying to root? If you are trying to root, what process are you trying to follow? What step in that process are you stuck at? What did you type and what did you get back?
I know you are probably frustrated, but its just as frustrating on this side when you don't give a complete picture that allows us to help you. Look, rooting and hacking isn't easy. It can even result in turning your phone into a paper weight. So these details are important so we don't screw things up and add to the headaches and frustrations.
bullpen7979 said:
Right click on computer/manage and I see android phone in list of devices there.
I was able to use this same data cable to unlock the bootloader. If it were faulty, I don't think I could have done that.
I have tried both usb ports on front and back of the desktop unit, as well as those on a netbook I have in tow. Same result everywhere.
I don't know what to do next.
The thing that sucks is it has to be something simple.....
Seriously. I'd paypal someone to help me out here. I just can't imagine what's going wrong.
Click to expand...
Click to collapse
I'm not sure what you are doing, or trying to do, as you said in the first post that you unlocked the boot loader and rooted.
The Moto X wont show as a drive letter in "My Computer." Even if USB Debugging is on, it should show up as a "Media" device, or Player type device with an icon in a separate section from your hard drives, DVD drive, mapped network drives, or even USB memory sticks/flash drives. It does this because the X supports/uses MTP/PTP, and NOT USB MASS STORAGE MODE.
MTP/PTP wont show a drive letter in My Computer. This is by design. You don't have to "stop" or "eject" the phone from windows when you are done. This mode also allows the phone to access the "storage" or emulated "SD" partition at the same time a connected Computer can.
USB Mass Storage mode will give you a drive letter in My Computer, IF the phone supported it. However the X doesn't, at least not out of the box, and I'm unaware of any app or hack to enable this. In USB Mass Storage mode, the PHONE looses access its storage partition or emulated internal SD card while the PC is connected. You'd need to "stop" or "eject" the device when you want to disconnect form the PC in order to prevent data corruption of the "emulated SD"
So again, its important for us to know exactly what you are trying to do.
From your first sentence in the original post in this thread you say you are rooted and have unlocked your boot loader.
Im sorry I was unclear. Bootloader is unlocked, but I am not rooted. What I said was that I had another thread about getting it rooted.
I'm sorry for the mis-speak. And I'm sorry I'm being such a pain, but others in the thread I'm referencing are clearly having the same issue I am. I just need to know what to do to obtain root access if my bootloader is already unlocked. To be clear, I do NOT have root access.
This is my procedure.
Start with this link:
http://forum.xda-developers.com/showthread.php?t=2509676
Download Cydia Impactor. Check.
Download RockMyMoto.zip attachement. Unzip two files to directory x. Check.
Download PuTTYtel file "puttytel.exe" Check.
Step one. I have my ip address. At bottom of wireless config on phone, it is 10.59.1.6. So far so good.
I run adb shell getprop dhcp.wlan0.ipaddress just to be sure. same ip addy. Good.
I start command window. push the two files to the phone. all is well.
Step two i open the puttytel window and proceed to run the exploit
dalvikvm -cp /sdcard/RockMyMoto.jar RockMyMoto
and I can't run the damn thing because i get PuTTytel Fatal Error
Network Error: connection timed out.
exactly like this dude: http://dl.xda-developers.com/attach...f04a/5290120c/2/3/8/1/6/0/9/1384014224630.jpg
The end. I read the rest of the thread, and post #22 is the first of about five other posts that mentions the same time out problem, a solution for which is NEVER ADDRESSED, except indirectly as a possibility that the the two devices are not on the same network. My wireless card is on dhcp and the phone is the IP address above.
that's where it stops. I can't run the exploit because i can't type the command fast enough. Several people mention this problem, but I read all SIX pages of the thread and this defect is experienced my many and adressed by nobody.
This is driving me stark raving Bat S#!+ crazy.
And yes I have USB debugging on.
If your boot loader is already unlocked, there is another process.
https://plus.google.com/110773150384694258853/posts/VhtJtg92sTP
Is the process and while I think that twrp version should work, you might need the older version. Had to take my mom to the hospital so not in a good position to find older if newer doesn't work.
EDIT: this thread -> http://forum.xda-developers.com/showthread.php?t=2536200 has some discussion too
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
We're back with an OTA update for 1GB and 2GB Remix Minis. Also, please know that if you are experiencing any type of streaming video issues, we've identified the problem, worked on a fix and are currently testing it now. If it passes, it'll be on the next update.
___________________________________________________
Remix OS on Remix Mini (1GB & 2GB) update version: 2.0.626
Release date: November 4, 2016
Release notes:
Updated Remix OS TV mode’s UI to the latest version.
IMPORTANT NOTE: For users who have NOT updated since version 2.0.307, all updates between 2.0.307 and 2.0.626 have been included. This is a critical update for the functions and usability of your Remix Mini. We strongly suggest you update to this version. This also means that this update may take a few minutes longer than regular updates.
__________________________________________________
Please continue to give us feedback here: http://support.jide.com/hc/en-us/requests/new
Thanks!
Do you have it as non ROM but as a firmware file to overwrite all partitions and have a fresh version of 2.0.626?
RemixOS_Jason said:
We're back with an OTA update for 1GB and 2GB Remix Minis. Also, please know that if you are experiencing any type of streaming video issues, we've identified the problem, worked on a fix and are currently testing it now. If it passes, it'll be on the next update.
___________________________________________________
Remix OS on Remix Mini (1GB & 2GB) update version: 2.0.626
Release date: November 4, 2016
Release notes:
Updated Remix OS TV mode’s UI to the latest version.
IMPORTANT NOTE: For users who have NOT updated since version 2.0.307, all updates between 2.0.307 and 2.0.626 have been included. This is a critical update for the functions and usability of your Remix Mini. We strongly suggest you update to this version. This also means that this update may take a few minutes longer than regular updates.
__________________________________________________
Please continue to give us feedback here: http://support.jide.com/hc/en-us/requests/new
Thanks!
Click to expand...
Click to collapse
How to exit TV Mode without restarting?
RemixOS_Jason said:
We're back with an OTA update for 1GB and 2GB Remix Minis. Also, please know that if you are experiencing any type of streaming video issues, we've identified the problem, worked on a fix and are currently testing it now. If it passes, it'll be on the next update.
___________________________________________________
Remix OS on Remix Mini (1GB & 2GB) update version: 2.0.626
Release date: November 4, 2016
Release notes:
Updated Remix OS TV mode’s UI to the latest version.
_______________________________________________
Click to expand...
Click to collapse
Can't find a way to close Tv Mode and back to normal desktop. How?
dinh_duy said:
Can't find a way to close Tv Mode and back to normal desktop. How?
Click to expand...
Click to collapse
press circle next to start button
kesmtk said:
press circle next to start button
Click to expand...
Click to collapse
Thanks. Gonna try it later.
Do you mean, you'd rather have a fresh copy of Remix OS on version 2.0.626 with none of your previous saved data and apps? Did you have your previous version rooted? I believe if you were just looking for a fresh start with the latest version of Remix OS, you can reboot your Mini, and then press F2 when prompted, and then do a factory reset. You may need to go through some updates, but I'm told you should restart in 2.0.626.
I hope this helps.
kesmtk said:
Do you have it as non ROM but as a firmware file to overwrite all partitions and have a fresh version of 2.0.626?
Click to expand...
Click to collapse
RM1C was rooted but unrooted cannot apply OTA
My device is RM1C. I Wanted to root on 2.0.512 version. but it autoupdated to some unstable version 2.0.622 with crashes after exiting fullscreen app. (I noticed there appeared an error messages on some missing file when connected via uart port. this is the message:
init: unknown magic init: unknown magic init: boost open /sys/devices/soc.0/cpu_budget_cool.16/roomage fail, No such file or directory!
init: boost open /sys/devices/soc.0/cpu_budget_cool.16/roomage fail, No such file or directory!
) but 2.0.512 was most stable version for me no errors on the uart also.
I rooted 2.0.622 version and allowed an app that I bought "gamecontroller2touch pro" to grant superuser permissions. It works as mapping xbox360 controller buttons to touch games like a charm, where a jide keymap does not support xbox360 it only works for keyboard input.
Then I saw a version for RM1C 2.0.627 was dowloaded in autoupdater. I unrooted and made system partition as it was. but it detects that the system was accessed as R/W and OTA update aborts with error 7.
I just wonder if the new version will not have that error that makes crash the desktop after exiting from fullscreen(as I found workaround to reutn to desktop after crash is to click xbox360 "back " button ). I have the incremental OTA for RM1C version 2.0.627 on usb, but cant install it . need reflash system.img.
RemixOS_Jason said:
Do you mean, you'd rather have a fresh copy of Remix OS on version 2.0.626 with none of your previous saved data and apps? Did you have your previous version rooted? I believe if you were just looking for a fresh start with the latest version of Remix OS, you can reboot your Mini, and then press F2 when prompted, and then do a factory reset. You may need to go through some updates, but I'm told you should restart in 2.0.626.
I hope this helps.
Click to expand...
Click to collapse
Got it. I remember your issue. I'm trying to work out 2 solutions for you:
1. Downgrade as you asked for. I'm waiting for the Chinese ROM team to give me the package and tutorial to be translated.
2. Flashing the Global (English) ROM into your Mini.
Do you prefer either/or? I'll respond still in private message to you about this.
Thanks!
kesmtk said:
My device is RM1C. I Wanted to root on 2.0.512 version. but it autoupdated to some unstable version 2.0.622 with crashes after exiting fullscreen app. (I noticed there appeared an error messages on some missing file when connected via uart port. this is the message:
init: unknown magic init: unknown magic init: boost open /sys/devices/soc.0/cpu_budget_cool.16/roomage fail, No such file or directory!
init: boost open /sys/devices/soc.0/cpu_budget_cool.16/roomage fail, No such file or directory!
) but 2.0.512 was most stable version for me no errors on the uart also.
I rooted 2.0.622 version and allowed an app that I bought "gamecontroller2touch pro" to grant superuser permissions. It works as mapping xbox360 controller buttons to touch games like a charm, where a jide keymap does not support xbox360 it only works for keyboard input.
Then I saw a version for RM1C 2.0.627 was dowloaded in autoupdater. I unrooted and made system partition as it was. but it detects that the system was accessed as R/W and OTA update aborts with error 7.
I just wonder if the new version will not have that error that makes crash the desktop after exiting from fullscreen(as I found workaround to reutn to desktop after crash is to click xbox360 "back " button ). I have the incremental OTA for RM1C version 2.0.627 on usb, but cant install it . need reflash system.img.
Click to expand...
Click to collapse
option 2 ; ) flash RM1C 2GB ram with RM1G firmware
..........option 2, I have pm'ed a message for you Thank You for help. :good:
RemixOS_Jason said:
Got it. I remember your issue. I'm trying to work out 2 solutions for you:
1. Downgrade as you asked for. I'm waiting for the Chinese ROM team to give me the package and tutorial to be translated.
2. Flashing the Global (English) ROM into your Mini.
Do you prefer either/or? I'll respond still in private message to you about this.
Thanks!
Click to expand...
Click to collapse
How and how long will this go on?
As a long time fan of Android-x86 I didn't really notice the Jide hardware until "The Merge"...
Now I see the Mini being sold off for half price and I wonder: Will it be obsolete on arrival?
I don't think I'd need Nougat on the device. I'd even think I'd be able to live with Lollipop.
But I can't operate a computer in my home network, that is unsafe to operate.
So I need the assurance that it will receive security updates until the end of its life cycle (3-5 years after purchase).
And I need the ability to control any computer I operate.
So will there be security updates until 2020?
Will you provide them or will you enable the community to provide them?
And will I be able to administer the system, de-activating services which have un-fixed vulnerabilities, blocking IPs, etc?
Generally that requires operating with root permissions on Linux systems, including those with an Android GUI.
$40 for a multi-media capable Linux systems running an attractive GUI is a great offer.
$40 for a potential IoT bot in my home network, which I can only throw away once somebody manages to subvert it, is a very bad investment, especially if it causes external damage.
So what will it be?
And will your future systems be any different?
BTW: Apart from 8 big desktops (Windows, Linux & Remix), 2 silent Atoms (Remix, Windows + Linux), 6 Notebooks (Windows, Remix & Linux), I operate 5 Android tablets and 10 Android phones (Canogenmod based Android, rooted by design).
Some of the PC hardware is 10 years old (3.4GHz Quad-Core Penryns work just fine with Nvidia GTX 1070), some of the Androids are still great after almost 6 years (e.g. Asus Eee Pad Transformer).
All of them run up-to-date operating systems with the latest patches. Typically not thanks to the vendor who produced the hardware but to the open source community which maintains Linux and Cyanogenmod.
If you treat the software on your hardware differently than Android-x86, you'll burn the brand very, very quickly.
usb boot
i have the remix mini rm1g with 626 is there a way to boot ubuntu via usb if i can boot into ubuntu can i install it and reinstall remix os on ubuntus root directory using grub customizer i know i can do that with remix os for pc
joeylikesubuntu said:
i have the remix mini rm1g with 626 is there a way to boot ubuntu via usb if i can boot into ubuntu can i install it and reinstall remix os on ubuntus root directory using grub customizer i know i can do that with remix os for pc
Click to expand...
Click to collapse
I don know, havent tried load linux on remix, I have rasbpberry pi and orange pi where they load everything from sd card.....remix mini loads from nand flash.
Maybe if you go to remix about screen and keep clicking build number to activate developer options.
Then dev options appear near about button in the options screen. Then enable usb debugging. select usb0 for debugging (the upper usb port)
install adb driver http://adbdriver.com/ . plug male - male usb cable PC-usb>remix upper usb port. Enter adb and enter root console. Maybe from root console it is possible to setup remix to load from sd card(where you linux kernel will be) by edidting uboot .
kesmtk said:
I don know, havent tried load linux on remix, I have rasbpberry pi and orange pi where they load everything from sd card.....remix mini loads from nand flash.
Maybe if you go to remix about screen and keep clicking build number to activate developer options.
Then dev options appear near about button in the options screen. Then enable usb debugging. select usb0 for debugging (the upper usb port)
install adb driver http://adbdriver.com/ . plug male - male usb cable PC-usb>remix upper usb port. Enter adb and enter root console. Maybe from root console it is possible to setup remix to load from sd card(where you linux kernel will be) by edidting uboot .
Click to expand...
Click to collapse
I don't think so. This is not a developer device, and not a traditional PC. It is a closed Android device (like Android phones and tablets), so would require custom bootloader/boot/etc. to loader other software. The Mini is made to show of Jide's bread and butter, their Remix OS software. They likely won't support officially installing any other 3rd party OS, since again, they are selling software and the hardware is incidental. Compared to the Raspberry Pi, which is open hardware designed for developing, and made to run various Linux releases and has broad support.
Now that it's EOL for the mini and no new updates are coming for it could we PLEASE have root?
4llerbuntu said:
Now that it's EOL for the mini and no new updates are coming for it could we PLEASE have root?
Click to expand...
Click to collapse
rooting easy, you must have uart to usb adapter. if you unscrew two screws under the rubber cover you will see 3 pins with GND tx and rx. Your usb to uart dongle shold have gnd tx and rx pins. 3,2 volt reading on the tx and gnd with multimeter. solder uart gnd pin to remix mini gnd. then uart tx to remix mini rx, and uart rx pin to remix mini tx. Open hyperterminal in windows. dial with com port setting 112500 none 8. and you have terminall root. from there you can cd to usb drive to install root
kesmtk said:
rooting easy, you must have uart to usb adapter. if you unscrew two screws under the rubber cover you will see 3 pins with GND tx and rx. Your usb to uart dongle shold have gnd tx and rx pins. 3,2 volt reading on the tx and gnd with multimeter. solder uart gnd pin to remix mini gnd. then uart tx to remix mini rx, and uart rx pin to remix mini tx. Open hyperterminal in windows. dial with com port setting 112500 none 8. and you have terminall root. from there you can cd to usb drive to install root
Click to expand...
Click to collapse
Looool:crying:
This is "easy"??
Seriously?
I always knew about this method. So there must be a reason I haven't tried it.
Anyways, id prefer rooting similar to what we have on numerous other Android devices, smartphones and TV boxes.
They usually don't require opening the device and a UART cable ......
re
4llerbuntu said:
Looool:crying:
This is "easy"??
Seriously?
I always knew about this method. So there must be a reason I haven't tried it.
Anyways, id prefer rooting similar to what we have on numerous other Android devices, smartphones and TV boxes.
They usually don't require opening the device and a UART cable ......
Click to expand...
Click to collapse
Well I had an old usb nokia adpter I tierd it appart and discoverd it has an uart interface with 3.2 volt communications sigal logic which is what is needed for remix mini. I soldered communications and boom I am as root user for remix mini . I copied supersu.zip and a instalation file from zip file inthe same foler. ran instalation file via sh command and root installed.
Maybe its possible to access root terminal from usb debugging.. I didnt try that.
You can install adb driver from adb.com. then click remix mini settings about. keep clicking version to get developer. enable developer. click settings menu again. click developer. click usb debuugging on. click usb0. then connect upper usb remix mini to pc usb. open pc cmd line and enter adb console. maybe from there you could do the stuff as root . I could
How do you install this? I'm currently on 2.0.203 and it says it fails trying to check for a new version. My internet is working fine though.
jbradshw said:
How do you install this? I'm currently on 2.0.203 and it says it fails trying to check for a new version. My internet is working fine though.
Click to expand...
Click to collapse
You must donwload phoenixsuit
https://www.dropbox.com/s/x7mnzui95c4459z/PhoenixSuit_EN_V1.0.8.msi?dl=0
adbdriver from
adbdriver.com
remix image
https://osdn.net/projects/remixos/downloads/66607/factory_image_rm1g_B2016110301-secure.img/
Warnining you will lose your all remix mini data.! games apps etc.
go to remix mini settings > abount. keep clicking on version number . the developer options will enable.
again go to settings>developer options > enable usb debuging , select usb0.
UNplug remix mini power cable.
Get a cliper and make a tool to push a "reset" button that is located in the hole in the back of remix mini. Try to for yourself by sticking cliper in the hole and feel the putton presses.
use usb MALE-MALE cable. connect remix mini upper usb port to laptop/PC usb.
I use windows 7 64bit
in laptop/PC:
1. Install the ADB tool
2. INstall PhoenixSuit. You will be guided through their installation instructions.
!let it autoupdate and restart it after updated
3. After the installation finishes, you can run PhoenixSuit by double-clicking the PhoenixSuit icon on the desktop.
4. Click ‘Firmware’ to enter the firmware flashing interface.
5. Click ‘Image’ to select the Remix OS img file.
!! click download one or multi partition to flash:
https://p5.zdusercontent.com/attach...Df0FXhMJxbcJLYkUku2_vQ.bLJYy1dgTWPhpfUCaIS3WA
6. Connect your Remix Mini to the PC via a USB-USB cable. NOTE: The cable must be plugged into the top USB port of remix mini.
7. Insert a straightened paperclip into the hole ar the back of your Remix Mini to press reset button.
8. while keeping clip inserted (reset button pushed) insert power cable to remix mini. Flashing image will start automatically, you can release the clicp holding reset button.
9. wait to complete, reboot mini.
Wow... what happened to the auto-update feature?
Impossible for me now to transfer files from PC to P7. Whenever the content loads, the explorer windows shuts down. Very annoying.
Any fix ?
StressFull said:
Impossible for me now to transfer files from PC to P7. Whenever the content loads, the explorer windows shuts down. Very annoying.
Any fix ?
Click to expand...
Click to collapse
What happens when you use the pull command?
Android Debug Bridge (adb) | Android Studio | Android Developers
Find out about the Android Debug Bridge, a versatile command-line tool that lets you communicate with a device.
developer.android.com
I had to use usb 3.0 port because 2.0 was giving me the exact same problem as you're facing.
Alternatively you can copy the files you want onto a usb stick and then connect it to your phone using the provided usb c adapter. I've done it few times and it works well.
innit said:
I had to use usb 3.0 port because 2.0 was giving me the exact same problem as you're facing.
Alternatively you can copy the files you want onto a usb stick and then connect it to your phone using the provided usb c adapter. I've done it few times and it works well.
Click to expand...
Click to collapse
Worked, thank you. Very strange.
Can you totally deny it is frozen because the transfer is taking time (ongoing) ?
I could imagine that it just waits for the task to be finished before accepting further commands.
I had this happen as well, I would select the MTP mode (file transfer/android auto or something) and it would disconnect from the computer. Switching to another USB-C cable fixed the issue