Is there anything useful that can be done using the low level booloader (with the blank screen)? Is there a driver for it or a boot image?
Windows ask for a driver, and I haven't found one so far.
Hardware id: USB\VID_0830&PID_8070
Or perhaps, its a Linux-only thing:
http://www.webos-internals.org/wiki/Last_Resort_Emergency_BootLoader_Recovery
I'd sure like to know about all the stuff that could be done with this.
Discussed here:
http://rootzwiki.com/topic/4602-qdloader-driver/
Nothing workable yet. I think more research (well above my head) is needed in this area. It's the key to making this thing 'unbrickable'.
Related
Don't know if I should've asked somewhere else but here it goes...
The device I have is a K-Free (or K-Phone) K480 aka Karbonn Titanium S25 Klick (it has another name in the store I bought it jeez) and what I'm specifically trying to do is to boot a kernel from another phone, almost exactly the same model Gigabyte GSmart Mika M3. Both phones run on the MT6582 platform.
Both devices are nearly identical, with the exception of the front facing camera where on the GSmart it is 8MP and on mine it is 5MP (the only difference in H/W mind you) and I even have the case for it on my phone. The point is - the hardware could be considered the same thing. Then I took a look at the software side of things...
Guess what - everything's almost the same as well, down to the partition layout (scatter files identical), littlekernel (uboot) works on my phone and yet I can't boot the boot.img of it or even the OS (haven't tried too hard on copying system.img, it should've worked with the ROM I have) so the only conclusion I can make is that the preloader needs to be flashed as well which is the most scary part.
Comparing the two preloaders from each phone, the one I have is newer than the one from the GSmart and I know why exactly - the dude in the store flashed my phone since it was a "new" model lol. The OEM provided them with software for Karbonn Titanium S25 (v1.7). Other than the date, there are still some differences - at the large chunk at the beginning it is the same, some stuff is moved around and most of all the final portion is different and I assume that's for the kernel side of things, but I could be wrong. So in conclusion, a large part of it is similar as well.
The reason why I make this fuss about is because Gigabyte seems to update their devices more often for one and the second reason would be simply exploring the possibilities of what I can and can't do with my phone and finally, the third reason would be ultimately, Gigabyte provided me with kernel sources for their Mika M3 and yet nobody from K-Free or Karbonn have responded so I have to get the stock GSmart kernel running on my device anyway and I know it's possible.
I need to know one thing for sure - would this work? The only way to find out is to flash it and I am a bit skeptical to try it out. Unless there's a safe escape route (no testpoints or anything, it's under warranty), I really don't know if I'm going to try it at all. At least, if anybody knows if the device will load some preloader or USB VCOM mode if it fails, please let me know.
EDIT: Just to let you know, holding Vol Down while plugged in without battery loads the meta mode, so it may work after all. I ask people who are familiar with MTK devices to confirm if MT6582 after failed preloader will continue doing that.
EDIT2: I was a bit impatient, but hey, flashing the preloader worked! lol Now onto turning the phone into a Mika M3 completely...
EDIT3: OK nevermind it seems I have answered my questions myself. To everyone who owns this device: you can flash Mika M3 software on it. Everything works just fine.
Where to begin? Logic would dictate, the beginning.
I'll do my best to be brief with the backstory.
Months ago I ordered a Jide Ultratablet to use as my portable workhorse. At first things were peachy until a rather monumental lag began to manifest every 15-45 seconds. It made the device impossible to utilize in any productive fashion, so I contacted Jide and opened up a support ticket. After months (in no way an exaggeration) of barely responsive correspondence, during which I sent them a video to demonstrate the problem, they finally came back to me with an email containing a link to a compressed folder containing the Remix 2.0 images, and also a link to a rather vague and complicated tutorial on how to flash Remix 1.5 manually to a device. (In fact, I tried to include a link to the tutorial, but I am unable to since I haven't posted to the forum enough. I am happy to PM it or email it to anyone who might like to help) I can only assume I am meant to apply the same logic to the Remix 2.0 files they sent me. Seemed a bit dicey at first glance, but while I'm by no means an expert, I'm no slouch in this arena and I'm a very quick study.
Now, on to the proverbial meat and potatoes:
If you were able to contact me for a link to the tutorial in question, you will have undoubtedly seen that they indicate one should use ADB-Fastboot as a means to flash the recovery image. No real surprises there. I have ADB and Fastboot installed on my PC (Windows 10). I also have the ADB drivers installed and have confirmed the addition to my PATH. (eg: ;C:\ADB) I can also confirm that it is working fine since I am able to pull up a terminal and issue the ADB command and it gives me the usual wall of commands. The problem is that my device (Ultratablet) is not being seen by ADB. I have checked my USB drivers and they are all up to date and installed properly. My PC sees the device no problem and there is no indication of any sort of connection error. I've also tried different cables and ports. Yet, I can't access it via ADB and thus am unable to issue commands to my device such as "adb reboot bootloader" or "fastboot reboot-bootloader".
My next logical approach was to attempt forcing the device into fastboot mode using the hardware button combination, which is not listed specifically for the Ultratablet anywhere, I might add. (Power key + Volume up) It brings me to a boot options menu with the selections "Continue/Fastboot Protocol/Recovery Kernel/Reboot/Poweroff/Forced Recovery". Ateempting to select Fastboot Protocol causes the display to shut off for a moment, the device to vibrate once, and then the display to turn back on back at the same menu full of selections.
So, in summary, I am expected to flash the device using fastboot and yet I can't even get the device into fastboot mode, let alone issue commands from my PC terminal. As I highlighted near the beginning, teh Jide support team is incredibly unresponsive and not overly helpful. I have notified them of this same set of issues, but I don't expect to hear back in any expedient fashion and I thought one of the mighty members here on XDA might be able to help me come up with a next step in the meantime. I'd cerainly love to be able to use my shiny new tablet.
In any case, thank you for your time.
Kind regards.
Shaiden
Bump? Anyone? Still swinging in the breeze on this one. No word back from the manufacturer, as expected. =/
I have the same problem
Shaiden said:
Bump? Anyone? Still swinging in the breeze on this one. No word back from the manufacturer, as expected. =/
Click to expand...
Click to collapse
I know it's been 4 years but did you find any solution to this? I'm asking because I have the same problem. I decided to downgrade to Remix OS 1.5 in order to root (I have tried 5 rooting apps with no success) but my device refuses to enter fastboot protocol. The whole idea was since I can't find a way to root the damn thing in its current state maybe I can manage it with its older OS version. All this just to turn it to android root apps "testing ground" device. Oof.
First of all, I know that I am the one who is to be blamed, but may be, I can be a help to others or to development. I want to thank the developers for their achievements and do encourage them to continue, even though Microsoft seems to do the same to Windows Phone which IBM did to OS/2.
What did I do?
I have a Lumia 920 with broken digitizer and brownish display, so that was the best device for some testing. With WPInternals I succeeded in routing an unlocked the boot loader.
Switched to MSM, I started to discover the partitions. Unfortunately, I touched the mouse and dragged and dropped "somewhat" in, I think, in the EFIESP partition.
Please don't ask me, why I did not continue with undoing or at least reflash the partitions extracted from an original ffu image.
Well, I rebooted the device and I lost. Damage is about 10 Euro, which I payed for the phone, nothing to be complained about.
With WDRT, I have the well known "device not supported" comments, the same with thor2, WPInternals and Chimera.
If someone has a suggestion, how to force the device to mass storage mode or the cog wheel/flash mode (vol+ and power does not work), you are welcome.
Log files can be provided, if you are interested.
Best regards,
Joachim
At least I solved it by swapping the good display to a device with broken display. I will reassemble the broken device with the broken display (which is still working) and give it away as spare parts.
I have a chinese TVpad2 mini-pc running on custom linux (factory OS) with busybox.
I want to install Android or anything other than the factory OS but there's a lot of problems with this device:
-Filesystem is CRAMFS
-Can only access as root through telnet
-Can't access bootloader or put into FWDN (no info how this is done for this device)
What I have:
-Firmware update that contains the kernel
-Telnet root access
-Physical access to device (USB flashdrive only)
There is a forum dedicated to TVpad but they are also having trouble installing an OS on tvpad2...
What do I need to know that will help me accomplish this?
thanks
TVpad3
Hi,
I actually have TVpad3 which is very similar to your TVpad2, and Im very keen on having Android developed for these TVpads.
Theres probably thousands of these wasted devices around the world after the TVpad pirate network got shutdown.
Ive searched high and low, and so far have Not found any trace of any custom Android development anywhere.
So hopefully we can kick start something here !
This is what I know so far ....
Since the devices run on highly stripped-down Android OS, we know these devices can run android and should be a potential for custom Android development.
Unfortunately theres little hardware or development info out there for these devices.
But as far as I know, the hardware platform for these models are all based on Telechip TCC89xx chips.
https://www.telechips.com/eng/Product/consumer_pro13.asp
I have a TVpad3 personally, which I believe is based on a Telechips TCC8925.
Ive found that there are a few similar devices out there based on this platform, including the Pandawill CX-01 TV sticks which have very similar specs to TVpad3 (512mb RAM, 4gb Flash).
So we definitely know that the TVpad's hardware is capable of running full blown Android !
http://www.cnx-software.com/2012/06...v-box-powered-by-telechips-tcc8923-cortex-a5/
http://www.slatedroid.com/topic/36988-cx-01-cortex-a5/
Telechips has released platform sources here, with the latest being Android KitKat... its a bit old but could have potential for a starting point...
https://www.telechips.com/technical_support/kor/opensource/opensource_list.asp
I havent found anything about booting these devices into Recovery or ADB.
But there seems to be some mention of a "FWDN" mode here:
http://freaktab.com/forum/tv-player-support/other-tv-players/4695-cx-01-information-by-tatubias
http://tvpadtalk.ca/discussion/506/how-to-unbrick-your-tvpad1
http://androtab.info/arm/telechips/how-to-update/
http://auswitch.xyz/2012/08/16/how-to-upgrade-firmware-for-cx-01-mini-pc/
From what I can gather, FWDN works in conjunction with a Windows-based utility used to flash firmware over a USB cable.
And this poses the biggest problem for TVpads, they DONT have any peripheral USB port !
I've pulled my TVpad3 apart, and found what appears to be provision for a USB header, but im not sure if these are functional even if a USB socket was soldered in ?
If we can get a functional USB peripheral port working, then that would lead us to the Second problem, that is, HOW to activate FWDN mode on the TVpad ?
From what I can gather, different Telechip TCC89xx based devices seem to have different ways to enter FWDN mode.
Some devices require a certain key combo to be pressed during power up, while others need a hidden button pressed or certain pins on the circuit board to be shorted.
So before we can even think about developing Android, we need to figure out those two issues...
1 - USB connectivity, so that we can flash it with FWDN tool.
2 - How to enter FWDN mode, so that the FWDN tool can talk to the TVpad.
If we can overcome these two issues, then we can start building sources.
Or even flash ROMs from similar Telechip TCC89xx based devices.
Anyway, I hope this helps anyone out there.
And I hope we can really make some progress here
.
Unfortunately I've hard-bricked my TVpad2 playing around with fdisk command in telnet. I found out that if you repartition and then copied all the data back, changes will be persistent so you can store whatever onto the NAND flash. Just don't delete the partition containing linux which I idiotically did... oh well.
Anyway there's a command utility "tccbox" with various tools one of them having the ability to update firmware. Hopefully TVpad3 has it as well?
Sorry to hear you bricked your TVpad !
I guess your only way back is to FWDN flash it.
I wasnt even aware the TVpads had telnet enabled.
But that "tccbox" utility sounds very interesting.
I wonder if we can use it to flash firmwares from other TeleChips based devices ???
.... such as the Pandawill CX-01 TV sticks.
wildchill said:
Sorry to hear you bricked your TVpad !
I guess your only way back is to FWDN flash it.
I wasnt even aware the TVpads had telnet enabled.
But that "tccbox" utility sounds very interesting.
I wonder if we can use it to flash firmwares from other TeleChips based devices ???
.... such as the Pandawill CX-01 TV sticks.
Click to expand...
Click to collapse
Hi i have found my old TVpad3 but no working now, i want flash it for use to android device, you have any tutorial for this PLS
TY
Hi there. Longtime XDAer (back to the OG Moto Droid) but new account. I am a OnePlus devotee that has converted to Pixel 6. I have used Qualcomm's EDL mode with the MsmDownloadTool in the past, is there an equivalent for the Tensor chip? I have no current need for it, but I like to have the appropriate tools ready for future issues, especially in light of the dumb Android 13 bootloader rollback issue some people seem to have.
FWIW, before posting I searched for EDL but that did not return anything. And the PixelFlasher appears to just be a adb/fastboot GUI, is that correct?
There's none afaik, and yes, PixelFlasher is just an GUI for easier operation
Can someone please tell me what EDL is
taanh1412 said:
There's none afaik, and yes, PixelFlasher is just an GUI for easier operation
Click to expand...
Click to collapse
Thank you for your reply! Bummer, I hope someone updates the forum if/when it gets released. As of right now, there'd be no way to fix a real brick if we don't have a EDL type of mode other than sending back to Google. Maybe one of their engineers could leak a version of it someday
bush911 said:
Can someone please tell me what EDL is
Click to expand...
Click to collapse
A very small embedded OS on Qualcomm chips, think of it kind of like a motherboard controller. Very handy when you have completely FUBAR'd the storage OS or bootloader, essentially bricking the device. EDL allows you to gain very low level SoC access to reflash stock images, thus unbricking. It has no printed screen, it just stays black. You have to use a PC tool to flash
centifanto said:
A very small embedded OS on Qualcomm chips, think of it kind of like a motherboard controller. Very handy when you have completely FUBAR'd the storage OS or bootloader, essentially bricking the device. EDL allows you to gain very low level SoC access to reflash stock images, thus unbricking. It has no printed screen, it just stays black. You have to use a PC tool to flash
Click to expand...
Click to collapse
And since Tensor is a modified Exynos (Samsung) processor there almost certainly is no EDL mode. How Google restores bricked units is anyone's guess, but Samsung does have a dedicated download mode that, combined with Odin / Heimdall on a PC / Mac, allows for flashing of stock images.
EDL is Emergency DownLoad mode on Qualcomm processors.
There's a ROM in Qualcomm processors that is always present and is the first step to booting.
In normal operation it will load the SBL/XBL (secondary bootloader) which will load the aboot (Android application bootloader).
If something goes wrong in booting (or if you configure it by test points or boot config) it can load a diagnostic program which is basically a replacement for the SBL/XBL.
That program (which in Qualcomm parlance is called a "loader") allows you to read/write partitions and even memory.
The difficulty comes that a lot of this is securely signed so there can be problems finding a loader that works.
Other brands have ROMs built in which do the same thing but are all incompatible with each other.
MediaTek has MTK mode, Allwinner has FEL mode...
Note: By "ROM" I mean truly read-only memory built into the processor chip itself.
(I think the casual usage of "ROM" to mean an OS loaded onto R/W flash is misleading.)
Strephon Alkhalikoi said:
And since Tensor is a modified Exynos (Samsung) processor there almost certainly is no EDL mode. How Google restores bricked units is anyone's guess, but Samsung does have a dedicated download mode that, combined with Odin / Heimdall on a PC / Mac, allows for flashing of stock images.
Click to expand...
Click to collapse
Interesting. The only Samsung I have messed with was the old Galaxy S5 that luckily had a bootloader exploit. Was a PIA to root though and after that I swore I'd never buy their junk. Nowadays they are impossible unlock and modify, as Exynos versions don't fully work in the US so you have to buy their Snapdragon variants which are locked down like crazy.
Maybe Google will release the download mode procedures and tooling
Renate said:
EDL is Emergency DownLoad mode on Qualcomm processors.
There's a ROM in Qualcomm processors that is always present and is the first step to booting.
In normal operation it will load the SBL/XBL (secondary bootloader) which will load the aboot (Android application bootloader).
If something goes wrong in booting (or if you configure it by test points or boot config) it can load a diagnostic program which is basically a replacement for the SBL/XBL.
That program (which in Qualcomm parlance is called a "loader") allows you to read/write partitions and even memory.
The difficulty comes that a lot of this is securely signed so there can be problems finding a loader that works.
Other brands have ROMs built in which do the same thing but are all incompatible with each other.
MediaTek has MTK mode, Allwinner has FEL mode...
Note: By "ROM" I mean truly read-only memory built into the processor chip itself.
(I think the casual usage of "ROM" to mean an OS loaded onto R/W flash is misleading.)
Click to expand...
Click to collapse
Wow, this is an amazing reply! Thank you! So much detailed and insightful information I didn't know. This is what makes the XDA forums amazing.
And yes, I have always been confused why the word ROM become the standard for the OS installed on Android phones, precisely for the reason you pointed out. Android ROMs are anything but read only
centifanto said:
Interesting. The only Samsung I have messed with was the old Galaxy S5 that luckily had a bootloader exploit. Was a PIA to root though and after that I swore I'd never buy their junk. Nowadays they are impossible unlock and modify, as Exynos versions don't fully work in the US so you have to buy their Snapdragon variants which are locked down like crazy.
Maybe Google will release the download mode procedures and tooling
Click to expand...
Click to collapse
Yeah, Google won't do that. As for Samsung, the Galaxy S4 I own did have a locked bootloader until I used Chainfire's RegionLock Away to permanently unlock the bootloader. The root process for that device was relatively painless, requiring Odin and - at the time - a specialized recovery payload that would root the device as there was no TWRP.
Well for one y'all are missing the fact that since the chip has an exposed serial unit, we can do some reverse engineering on the bootrom and find jump points to certain addresses in memory. Such as the recovery mode. Google host the gs101 and oriel kernel repositories in its open source git repositories. I've found a tone of useful information in there. Ghirda is a good program for reverse engineering.
EDL for Exynos uses Exynos Dead Boot Mode. After changing the USB mode and using dwusb3 drivers we should have enough range to write/send bytes to chipset
NonStickAtom785 said:
Well for one y'all are missing the fact that since the chip has an exposed serial unit, we can do some reverse engineering on the bootrom and find jump points to certain addresses in memory. Such as the recovery mode. Google host the gs101 and oriel kernel repositories in its open source git repositories. I've found a tone of useful information in there. Ghirda is a good program for reverse engineering.
EDL for Exynos uses Exynos Dead Boot Mode. After changing the USB mode and using dwusb3 drivers we should have enough range to write/send bytes to chipset
Click to expand...
Click to collapse
Wow, this is amazing info! Thanks for sharing, I had no idea about this boot mode. I found these comments in this link:
USB download mode is only accessible if first boot method has failed...Once the first boot method fails, USB download mode can be accessed by pressing and holding power button.
This link also looks interesting.
All of this sounds like only someone with advanced knowledge would be able to figure it out, and with the high risk of truly bricking their device.