Related
Introduction:
I have found that many people are unaware how to use fastboot, which if you have ever owned an HTC phone or something from the Nexus line you know how important it can be.
About a year ago I got sick of answering questions about fastboot so I made a guide, but it was device specific. Not too bad but I was constantly giving the links to it for other phones... of course more questions just popped up.
So here i am making a comprehensive yet easy to follow (I hope) guide on how to set up and use fastboot. I will cover the basics for Windows and Liunx (sorry Apple users, just cant stand the product/company)
I plan to make a series of guides for XDA-University Thus far there is this guide and:
[Guide] How To Create Recovery Flashable .zips / update.zips
First a short explanation:
Fastboot, like ADB, is a tool to communicate from PC to Android phone. There are times when it is a must to use, and times when it is just helpful.
ADB is used within your recovery or within your OS, but when you are in bootloader mode and need to communicate with your phone then you need fastboot.
And you may ask why would i ever need this?
Well many reasons. Main one is knowledge, learning the ins and outs of fastboot, like learning ADB, can get you out of many jams.
And if you want to unlock your bootloader this is done through fastboot. Granted HTC's unlock is... well crap, but for a Nexus this is how its done.
One other reason I have to stress is learning for safety reasons, This is about the safest way possible to flash firmware to your phone (ie Radio, Hboot, Recovery)
Lastly you may want to know the limitations,
There are many of course, this isnt JTAG, it will not resurrect a hard brick, but it often save peoples phones from 'soft bricks' and lots of time when know how and when to use it.
Think of fastboot as the program that takes over when ADB cant be used, it works with firmware more than software.
So where do i get fastboot? There are a few ways but most often I would recommend getting it from the Android SDK as it is will be up to date.
or you can use THIS HANDY TOOL created by @shimp208
Click to expand...
Click to collapse
Click to expand...
Click to collapse
I will go over the Download and Installation Process in the Next Post
Then i will go over useful commands.
*Just a note, This guide is to always be considered under construction as I plan to continue to make additions such as more commands and pictures
I will continue to attempt to clarifiy when needed and add what I have missed. I have yet to drop any project or guide I have made on XDA and will help where I can
As always I encourage questions I may miss something or be vague, it is best to understand fully then not ask.
Setting up fastboot on Windows and Linux
What is Fastboot?
Fastboot is a protocol designed to flash signed/unsigned partitions to android phones directly into the phones flash memory. If you are familiar with ADB think of it in the same way.
If you're not, just understand it is a tool designed to help flash images such as recoveries, bootloaders, kernels, etc. to your android phone. For the most part you can not use much of fastboot unless you are rooted and have an engineering SPL (Hboot/Bootloader)
If using a Nexus device you in a sense have an engineering bootloader already so don't need to worry about it like HTC folks need. But Some Nexus lines will have different bootloaders with different capabilities.
This however is not a tutorial to root your phone so i will not explain this. I will though go over SOME basics as in unlocking your bootloader to allow it to be rooted.
Click to expand...
Click to collapse
Click to expand...
Click to collapse
How do I get fastboot for Windows?
Fastboot.exe can be downloaded to your computer from Google's SDK found
HERE download the proper package depending on what system you are using.
also
you will need the proper drivers to allow your PC and phone to communicate. You will find these in your devices specific forum or possibly you can use PdaNet
Okay i got it, whats next?
After you downloaded the SDK package to your PC see where it is located, somewhere like this for Windows
C:\android\android-sdk-windows\platform-tools
Click to expand...
Click to collapse
Of course put it where you like, just know where fastboot.exe lies
*If you want to skip the SDK, you can get ADB and Fastboot by themselves with THIS HANDY LITTLE TOOL created by shimp208
Note: After you have ADB and Fastboot you will may want to finish following this guide to add a path in environmental variables.
For Windows:
Although not necessary, but to make it easier i really suggest doing these steps:
left click the Windows (start) button > right click on computer > choose properties > go to advanced system settings > advanced tab > environmental variables > in the first box (user variables for _____) click new > name it
adb
Click to expand...
Click to collapse
> the value is the path from earlier
C:\android\android-sdk-windows\platform-tools
Click to expand...
Click to collapse
(yours may differ from this so double check it!) > in the second box (system variables) find a variable named
path
Click to expand...
Click to collapse
if one doesn't exist make one > double click on it > at the very end of the variable value add the same line as before but with a ; in front of it. like this:
;C:\android\android-sdk-windows\platform-tools
Click to expand...
Click to collapse
alright click ok and you are done!
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Why did I just do all that?
Well this allows you to open a command line from anywhere on your computer without changing directories to use fastboot. Pretty much we told your PC that when you type
fastboot
Click to expand...
Click to collapse
or
adb
Click to expand...
Click to collapse
into CMD where to find it. As you learn how useful fastboot and adb are this will help a lot as CDing to where you want to be is wasted time.
So I still don't know what to do or how to do it!
All right lets start simple, click the windows button and in the search field type
cmd
Click to expand...
Click to collapse
you will notice a window pop up that looks suspiciously like DOS. View attachment 1980110
Here you will see a blinking cursor after your directory, lets try this type
Code:
fastboot
a whole bunch of probably unfamiliar stuff should now pop up View attachment 1386065 (for the most part this is a list of commands that can be used in fastboot) if you get something like
fastboot is not recognized as internal or external command operable program or batch file
Click to expand...
Click to collapse
then we need to troubleshoot, but for now i will assume it worked.
Now try typing
Code:
fastboot devices
...and nothing will happen, Why? because there isn't a device attached. Make sure you have android debugging turned on in your phone (not really needed for fastboot but you do need for ADB), plug it into your computer and boot into fastboot mode. On many phones hold volume down while powering on, if this wont bring you to bootloader mode then see your device specific forum, if needed choose fastboot. Again try typing
Code:
fastboot devices
this time you should have a list of attached devices, this is displayed as the serial number to each. Being many commands will "do" things to your phone try typing
Code:
fastboot reboot
If your phone is now back and running your existing OS, congratulations! :good: You now at least have fastboot set up and working properly. Now lets try a few things out and see why this can be so helpful!
Click to expand...
Click to collapse
How do I get fastboot for Linux?
To get fastboot installed on your Linux box first download appropriate SDK package From Here
*Not all Linux distros are the same and I don't consider myself a Linux guru, I will explain what I know about the few distributions I've used but remember if something don't work look up specifics for yours HERE
After SDK is downloaded extract contents into home folder, maybe in a folder called Android, your choice.
Now we need to make sure we have the latest java JDK installed found HERE or if you prefer you can get it from the terminal
Code:
sudo apt-get update
sudo apt-get install openjdk-6-jdk
or if using Ubuntu, the software center. (I have heard people complain about JDK7 so to be safe stick with JDK 6 for now)
**I have a 64bit machine so I needed the 32bit libraries, you may not need this. If you do run this from terminal
Code:
sudo apt-get install ia32-libs
**As pointed out to me by trevd, if you are using Ubuntu 12.10 or newer you should simply open a terminal and run these two commands
Code:
sudo apt-get install android-tools-fastboot
and
Code:
sudo apt-get install android-tools-fastboot
If you never plan on developing for android or using other tools that come with the SDK
then this should be all you need. And you may also skip the JDK install. As most people will never attempt to create
an app or ROM or mod their phone in a way that they would need more than this, these simple commands should suffice.
Downloading Fastboot
ummm.. isn't that what I just did? Possibly, but as far as I know ADB, fastboot and everything else in platform-tools wont automatically download with the SDK.
Other have told me it does, so feel free to navigate to the platform-tools folder and see if you see these applications.
If you skipped installing the SDK and just installed fastboot and ADB from the command line you can skip down to creating a path. So if you got them, skip this, if you don't, do this:
From in a terminal type
Code:
cd ~/android-sdk-linux/tools
./android
**note depending on what you named the folder the downloaded and extracted SDK is in you may need to change your cd command to something else.
Now a new window will pop up, Click on "Available Packages" and you will be see two boxes. One is Android Repository and the other is Third-party Add-ons.
Click on "Android Repository" then click on Install Selected. now click on "Accept All" and then click on the Install button.
Personally I like downloading all that is possible here, you may have limited space or bandwidth so all you 'need' is the contents of platform-tools.
If you want to download some API's later go for it, they aren't needed unless you are developing.
Adding a Path
Just like in windows changing directories can be brutally annoying so lets add a path. Open a Terminal and type:
Code:
nano ~/.bashrc
or you can use gedit, whatever you have/like to use (sudo gedit ~/.bashrc)
At the end of this text (or at the begining add the following
Code:
Android tools
export PATH=~/android-sdk-linux/platform-tools:~/android-sdk-linux/tools:$PATH
**again be sure this is your path (neat trick, find fastboot from within platform-tools, right click on it, go to properties, highlight the location/path and copy/paste this)
Now click save, this will make so you no longer need to type ./adb all the time
I have been told a reboot is needed here but I don't think so, just type this into a command line:
Code:
source ~/.bashrc
Drivers? I don't need no stinking drivers!
True, sorta, but more than likely we will need to add the android rules so your device can communicate with PC. Open a Terminal and Type
Code:
gksudo gedit /etc/udev/rules.d/51-android.rules
now add the following lines:
Code:
SUBSYSTEM=="usb", ATTRS{idVendor}=="0bb4", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="0502", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="12d1", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="1004", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="22b8", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="04e8", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="0fce", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="0489", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="18d1", SYMLINK+="android_adb", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="04e8", MODE="0666", GROUP="plugdev"
Depending on your device this should be all you need and then some, feel free to check out THIS for the most up to date vendor list.
View attachment 1980099
Now for a test!
So plug your phone into PC via usb, have it in fastboot mode (from within bootloader) and open a new terminal, type:
Code:
fastboot devices
If you see a string of #s and letters then success! :good: you are ready to learn the ins and outs of fastboot!
Click to expand...
Click to collapse
Using Fastboot To Unlock Your Bootloader
Do You need to unlock your bootloader?
For many phones this is necessary to root, for others it is a poor way to root your phone as you may not have full access.
Many HTC model phones can be rooted with various exploits, sometimes removing the radio secure flags completely.
If you have one of these devices than I recommend this, as true radio s-off is far superior to an unlocked bootloader.
But other phones, including the Nexus line, will be fine just unlocking and do not need to worry, Although some phones like the Nexus One can profit from a new bootloader altogether.
To begin the rooting process you simply need to unlock your bootloader with this command from a terminal/CMD
Code:
fastboot oem unlock
and the reverse of course is
Code:
fastboot oem lock
Be prepared for a full wipe of your phone when unlocking the bootloader!
But quickly if you have an HTC and choose to unlock your bootloader to root your phone follow these step:
Select your phone from the list HERE (you will need to create a log in)
there will be some legal mumbojumbo to click through (just saying you void your warranty but you knew this!)
you may need HTC sync found HERE as well as the proper RUU for your phone, the HTCDev site will inform you.
After which the site will move you through the steps to gain fastboot access, but if you followed my guide above just skip it all.
next you will need to get the identifier token, this is unique to your device and really just getting probably voids your warranty,
even if you stopped the guide here. to do so, open terminal/CMD and type
Code:
fastboot oem get_identifier_token
copy and paste this information into the prompt at the bottom of the page. Now wait for an email to get your token....
once you get the email with the token you can now follow their steps to unlock your bootloader...
really if at all possible i recommend not to do this method of rooting. But if you do, follow these same next steps that the Nexus devices will be doing...
Now that your bootloader is unlocked:
We will flash a custom recovery to your phone, then a custom already rooted ROM. To flash the recovery go to your device specific forum HERE and find the developers section.
Look for a custom recovery option and consider reading up on it there.
Different Android phones will have different custom recovery options depending on the developers for it. The most common is ClockworkMod, there are both touch and none touch recovery options.
some others are TWRP, 4EXT, AmonRa and Cannibal. Find out what your options are, pick one and download it.
If possible check the MD5Sum, Windows use: THIS and Linux use a terminal and type
Code:
md5sum <filename>
of course replace <filename> with the file name.
View attachment 1980095
If you prefer, GTK Hash is a nice program as well.
Now this should be an image not a zip, so if the extension is .img your good, if its in a .zip or .jar or whatever extract the image.
Take this image and (for simplistic sake) name it
recovery.img
Click to expand...
Click to collapse
**if using windows be sure to pay attention if your file extensions are hidden, don't name it recovery.img.img!
So be sure your phone is in fastboot mode and connected to PC, open a terminal/cmd in the same location that recovery.img is in
(cd to that directory or windows users can hold shift > right click in the folder it's in > choose open command here)
Code:
fastboot erase recovery
fastboot flash recovery recovery.img
**erase recovery is not necessary but i am OCD about wiping...
now if you get an okay! then your good :good:
Code:
sending 'recovery' (4930 KB)...
OKAY [ 0.521s]
writing 'recovery'...
OKAY [ 0.489s]
finished. total time: 1.10s
If not let me know what the output is and ill help you fix it. (I will also make a troubleshooting section in my final post)
Great! Now Let's Flash a ROM
In that same developers section for your phone, you should pick out a ROM of your licking. If possible i would suggest an older version of CyanogeMod as these builds tend to be quite stable.
Also some phones may have newer ROMs requiring you to do various things to your phone. Such as changing radios or bootloaders or other things we haven't gotten to yet.
So for now try to read the OP of the ROM you like and make sure you meet all requirements.
So Im not going deep into how to flash a ROM from recovery as this is not part of a fastboot guide.
But pretty much just pick a ROM and anything else you may need (gapps, kernel, etc) and put on root of SDcard (no other folder)
Then boot to recovery, wipe all you can (I'll teach you fastboot wiping soon!) and then flash ROM + whatever else you need to and then reboot.
Another Issue With HTC's Unlocked Bootloaders
Well if this not yet another reason to try to gain true radio s-off for your phone...
From with in that ROM that you flashed you also need to unzip and extract the kernel (boot.img) this will need to be flashed through fastboot.
Once all the above steps are completed reboot into fastboot mode, if your recovery doesn't have a quick way to do so just open a terminal/cmd and type:
Code:
adb reboot-bootloader
from here you will need to then open a terminal/cmd in the same location as that boot.img is and type:
Code:
fastboot flash boot boot.img
If it says okay you are finally done!!! Well done with flashing your first ROM but can you flash a ROM in fastboot? I mean do you need recovery at all?
There are ways, and ill teach ya in the next post!
Click to expand...
Click to collapse
Click to expand...
Click to collapse
Flashing a ROM through Fastboot
So Why Do I Need To Do This?
You don't, normally you would flash a ROM through recovery, but why not have another way? Maybe your recovery partition on your phone is corrupt?
Maybe you just want to say "I learned something new!" whatever your reason here are the simple steps:
To start:
We need to download the ROM of choice to your computer. Once complete find the folder that ROM is in and open terminal/cmd to that directory
(quickest way for windows; just hold shift and right click within that folder > open command window here) of course make sure your phone is plugged into computer and in fastboot mode.
Lets see how quick and easy this really is...
In the command line type:
Code:
fastboot devices
Seeing your serial number means we know all is good
Now lets type these commands:
Code:
fastboot erase system -w
fastboot erase boot
fastboot update superawesomerom.zip
Of course replace <superawesomerom.zip> with the correct file name
and last but not least:
Code:
fastboot reboot
*Its been a little while since i did this but the phone might automatically reboot after flash so no need to run the reboot command
As your phone boots into the new ROM, pat yourself on the back...
Click to expand...
Click to collapse
Click to expand...
Click to collapse
A Note on Erasing/Formatting
You may have noticed earlier that I had you erase your recovery before flashing a new one,
now here I had you erase system and boot, you may be wondering why.
I find that a large amount of complaints in developer threads are due to people not properly wiping before a flash.
Of course there is times when a 'dirty' flash is fine, but if you're ever not sure, wipe as cleanly as possible.
fastboot allows for about the cleanest of wipes by the way. And each partition can be done separately too.
Code:
fastboot erase system
fastboot erase data
fastboot erase cache
can all be done individually, but to do these all in one command
Code:
fastboot erase system -w
If possible I recommend to do these steps before flashing a ROM, and now that you know you can do this all within fastboot mode i suggest to try it out, its quick and painless!
Don't forget to wipe your kernel too! (fastboot erase boot)
~Important~ If your device uses an emulated SD card (as in no removable micro SD but an SD partition on phone)
Then be careful wiping data/userdata as this will erase all contents of internal SD - you are forewarned!
Click to expand...
Click to collapse
Click to expand...
Click to collapse
What about just flashing a single partition?
Sure this can be done, hell you can restore a nandroid if you want!
well first you need to make a nandroid back up (unfortunately fastboot cant make a nandroid for you :crying: ) Put it some where on your computer.
Personally I only keep maybe 2 or 3 nandroids on my phone's SD card as why waste space. I do however keep almost all my nandroids on my computer separated into different folders for different phones. So my path to a nandroid backup would be something like:
android/htcg2/nandroids/<nameofnandroid>
Click to expand...
Click to collapse
But here's the catch, most newer recoveries do tar backups I believe TWRP uses .win, these can not be flashed in their current form!
However most older recoveries use yaffs2 format for their backups, these will always work. Pretty much if you get a backup with various partitions as .img you're good to go!
**Hypothetically speaking here: you installed a new recovery and want to flash a nandroid made in old recovery but the two recoveries used different formats...
Well you can flash the images with fastboot, then make a new nandroid and you got them back!
...Maybe I'm stretching... oh well, here's how to!
Now the obvious stuff:
Have phone plugged into PC via USB and in fastboot mode, open terminal/cmd and change directories to that folder where your nandroid is in (or again just hold shift and right click > open command window here if using windows)
Now in terminal/cmd type:
Code:
fastboot devices
all is good when serial number is displayed, now type:
Code:
fastboot erase system -w
fastboot erase boot
*This isn't 100% necessary but I'm a firm believer in wiping before any flash, even a backup
Code:
fastboot flash userdata data.img
fastboot flash system system.img
fastboot flash boot boot.img
fastboot reboot
(of course change the image names if needed)
Click to expand...
Click to collapse
Click to expand...
Click to collapse
And you did it! :good: now you are almost a pro at using fastboot!
keep playing around, you'll get the hang of it and will quickly see that this is one of the best tools in the Android SDK.
It makes things much faster and easier and in many cases safer than the alternatives. Any questions... feel free to ask!
Happy Flashing!
What About Flashing Firmware?
Flashing any firmware to your phone can be dangerous but if possible the best and safest way is with fastboot.
Hypothetically you flash a new Hboot through recovery and this Hboot was corrupt in some way, if the flash takes you will have a bricked phone, hard bricked, only JTAG can bring it back.
But with fastboot you get to input your command to terminal/cmd an see the output, if something goes wrong, just DO NOT REBOOT until you fix the problem.
And again, checking MD5sums is nice when flashing software but a must when flashing firmware.
I will again recommend THIS for windows and using the terminal for Linux
Okay, Time To flash A New Bootloader!
Some phones will not allow bootloader flashes unless you remove the radio secure flags, if you have a phone like this check the developers thread for a how to.
To begin, find the appropriate bootloader (sometimes referred to as an Hboot or SPL) for your phone,
Now download and check MD5sum, have your phone in fastboot mode and open a terminal/cmd in the location your Hboot.img is stored.
Code:
fastboot devices
fastboot flash hboot hboot.img
and of course replace 'hboot.img' with whatever you titled your image
**Do not reboot if you see 'sending.... failed' need to see the 'okay!'
I am not trying to scare you as these instances are so rare, but knowing what to do ahead of time is just common sense.
Not all devices use the same terminology for partitions, so if the above does not work than consider changing to this command:
Code:
fastboot flash bootloader bootloader.img
Again replacing <bootloader.img> with the name of your image
Now flashing a new bootloader will more than likely repartition your phone, so from here you probably should flash a new recovery, then flash a new ROM.
Be prepared to do all this before flashing a new Hboot!
Click to expand...
Click to collapse
Click to expand...
Click to collapse
I'm ready to flash a new radio!
Flashing a radio can also be dangerous, but again the safest way to do so is within fastboot. So if possible always flash radios in fastboot mode!
**I am not referring to the FM radio in your car, rather your cellular Radio, you know where you get reception... don't ask me how to add a FM radio to your phone!
Also know OEMs commonly use baseband and radio as interchangeable terms, for the most part this is the exact same thing
First things first, know why you are flashing a new Radio. Is it because you have poor reception? Poor data speeds? Poor battery life?
Yes a new radio can cure all this, but NO ONE can tell you which radio is best for your phone, not even someone living in the same city.
The best radio for my phone will not for sure be the best for yours, even if you live down the road from me. Don't ask what Radio is best! and only flash a radio meant for your device!
Now that that's out of the way, lets do the same steps as before:
Download appropriate radio
Extract if needed (should be in .img format)
For simplistic sake name it 'radio.img'
Plug in phone to PC and open a terminal/cmd in the same location as your radio.img
Code:
fastboot devices
fastboot flash radio radio.img
fastboot reboot-bootloader
Again only reboot if all goes well (It will if you follow all direction)
Upon rebooting your bootloader you will notice your radio version has changed, congrats! You're becoming a pro!
*note, occasionally OEMs package another image called rcdata.img along with a firmware release, if they do I also recommend to flash this along with the radio
Code:
fastboot flash rcdata rcdata.img
**another note, if possible try to match the ril libraries between your ROM and radio, this is device specific and you will need to see your developers thread for this info.
It is not always possible or necessary to do so, but many do say it help quite a lot
Click to expand...
Click to collapse
Click to expand...
Click to collapse
Flashing a Kernel
Earlier I went over flashing kernels as part of HTC Unlocked Bootloader Flashing, the process is the same for anyone else as well.
Locate the Kernel you want to flash
navigate to the folder it is in (should be in .img format and lets name it boot.img)
Code:
fastboot flash boot boot.img
But lets say you are a developer and have worked on a new kernel for your device, a quick and easy way to test it out may be to fastboot load the kernel:
Code:
fastboot erase boot
fastboot boot kernel ramdisk
As usual replace file/image names accordingly
If you do not want to erase the current kernel, just skip erasing.
But I would just have a working kernel.img handy and erase, this way I know there are no residual effects from previous kernel - choice is yours
Code:
fastboot flash:raw boot kernel ramdisk
fastboot reboot
Test it out and see how things go! Good luck! :good:
Click to expand...
Click to collapse
Click to expand...
Click to collapse
As always, if you have questions or comments feel free to leave them here!
Happy Flashing!
What Are Some Other Things That Fastboot Can Do?
A Whole lot really... This guide would be forever long going through all of this. But I'm trying to progressively go through as many options as I can in order from simple to complicated.
I mainly am making this guide for beginners but I want the Advanced Android user to learn something too! Hope we can all learn from each other!
RUUs or HTC's ROM Utility Updates
This can be a way of returning to stock or updating to an official OEM update.
To do this make sure your bootloader is locked
(as far as I know RUU's fail if unlocked, but depending on phone engineering SPLs or having radio s-off can be safe - but not always so check device forum)
So boot into fastboot mode, open cmd/terminal in location of RUU then
If needed:
Code:
fastboot oem lock
then to get into RUU mode
Code:
fastboot oem rebootRUU
Then you will flash the zip, change command to correspond to proper name
Code:
fastboot flash zip rom.zip
If it gets stuck and you see a message like flush immediately! just do the above command again, often first try fails for some reason
Always know if you need to or should be flashing an RUU, some people do more damage to their phone just because they thought they were bricked and tried 'everything'
And if you're looking for OTA's (over the air updates) or RUU's for your phone HERE is a great source!
Click to expand...
Click to collapse
Click to expand...
Click to collapse
Some Useful Information About Your Phone
Lets say you want something basic like your device's model number, type:
Code:
fastboot getvar mid
the return output is your model number. Some phones are locked into only allowing new versions of an OS to be flashed, to check yours type:
Code:
fastboot getvar cid
cid: 11111111
Click to expand...
Click to collapse
If your return value looks like this then you have superCID, meaning you are allowed to flash older and newer versions of Android OS. And depending on phone you can just use this command:
Code:
fastboot oem changeCid
or possibly a common cid (SuperCID)
Code:
fastboot writecid 11111111
If you want to get a bunch of info quickly try this:
Code:
fastboot getvar all
Here you will receive an output of much of your devices specifics, such as bootloader and radio versions, devices name and if its locked, IMEI # and so on.
Click to expand...
Click to collapse
Click to expand...
Click to collapse
What about trouble shooting?
There have been various devices over the years which have used inferior parts. like the HTC DZ/G2 or Glacier.
These phones, like some others, had two different emmc's installed; one worked great and one was prone to failure.
I found the easiest way to check which emmc was in the phone was with a few fastboot commands:
Code:
fastboot oem list_partition_emmc
fastboot oem check_emmc
fastboot oem check_emmc_mid
Of course this couldn't prevent a phone from the mysterious random hard brick, but it could tell you if your hardware was prone to failure or not.
There are also a serious of tests that can be performed depending on the bootloader you have installed:
Code:
fastboot oem list_partition all
fastboot oem partition_test all
Both of these commands you can substitute 'all' for 'system' 'cache' or whatever if you just need info or test a single partition.
You may have noticed that some of these commands require knowledge of hex editing, which of course no one is good at but the info is there if you want to search for it! So here is some more!
Code:
fastboot oem heaptable
fastboot oem imgcrc
The second command here will run a checksum for your hboot, recovery, boot, and system partitions.
I find it helpful to know the value of what the should be when phone is working good and can use this against another checksum if i have issues down the road.
System and boot will change of course, but recovery and hboot wont unless i flash a new recovery or bootloader, this can help check for bad blocks.
Speaking of bad blocks, lets look for some:
Code:
fastboot oem rbchk
Now having some bad blocks in your nand is not always going to cause your phone to be unusable, sometimes its a partition thing too.
Some of these commands don't do anything...
True, various devices and bootloaders will allow for various fastboot commands. two tests you can do to see what yours supports
fastboot
Click to expand...
Click to collapse
or
fastboot oem ?
Click to expand...
Click to collapse
typing just this into a terminal/cmd will give you an output of available commands for your device. I hope to add a bunch more soon but i need to finish my papers and studying for finals!
Click to expand...
Click to collapse
Click to expand...
Click to collapse
A Bit More Helpful Tips For Booting
Sometimes you may have issues booting, earlier we went over booting a kernel you made yourself as well as flashing a kernel
What about just booting a kernel without flashing it to your device?
Code:
fastboot boot boot.img
The above, when executed properly, will boot a kernel from pc on your phone without flashing directly. There are times we need to force boot or just test.
What may be even handier is to boot a recovery without flashing it, this is done in the same manner as above and can let you use a recovery on your device without installing it.
Plug phone into PC, connect with USB cable and have phone in fastboot mode, now open CMD/Terminal in the same directory as your recovery image
Code:
fastboot boot recovery.img
Of course name image correctly to fit command or vise versa
Now you are in recovery of choice within your device without it being flashed to your recovery partition. There is a time and a place for everything, can you think of ways this may help you? Sure you can!
Click to expand...
Click to collapse
Click to expand...
Click to collapse
as always... Happy Flashing!
Is There Anything Fun I can Do With Fastboot?
How would you like to go from this:
to this to this to this to this
Or really just about anything you want?
Click to expand...
Click to collapse
Click to expand...
Click to collapse
Of course I'm referring to the splash screen, the one that appears when you first boot your device, before the bootanimation.
This is a static image put there by the OEMs and often is real boring. True some phones have some neat ones, others little gifs, but really why not change it if we can?
Well in order to do this we need to know where our device in question stores the splash screen. If it has its own partition, your rooted, and your bootloader has fastboot capabilities we are good to go!
...well almost, remember when i talked about s-off earlier? This is low level firmware stuff, at least the way many device see it. Having root access doesn't mean we can do anything unfortunately.
I would suggest checking your phones forum to see if anyone know specifics to your device and where this partition is stored, if you need help other than from this guide feel free to post and ill see what i can do!
Ok, so I'll use HTC as an example here, we are rooted, we have an engineering bootloader, and security flags are removed. Now we need to find partition location.
Code:
mmcblk1p2 - "sd-ext"
mmcblk1p1 - "sdcard"
mmcblk0p31 - "misc"
mmcblk0p29 - "pdata"
mmcblk0p27 - "devlog"
mmcblk0p26 - "modem_st2"
mmcblk0p25 - "modem_st1"
mmcblk0p24 - "cache"
mmcblk0p23 - "userdata"
mmcblk0p22 - "system"
mmcblk0p21 - "recovery"
mmcblk0p20 - "boot"
mmcblk0p19 - "adsp"
mmcblk0p18 - "radio_config"
mmcblk0p17 - "radio"
mmcblk0p16 - "misc"
mmcblk0p14 - "splash1"
mmcblk0p12 - "bootloader" hboot
So this device keeps the splash screen in mmcblk0p14, this is very important to know and will change with most devices.
We will know extract original splash before we change it. Again I cant stress how important it is to know what you're doing when using dd commands!
So open a terminal/cmd
Code:
adb shell
su
dd if=/dev/block/mmcblk0p14 of=/mnt/sdcard/splash.img
This will now pull the original splash and place it on your sd card named splash.img
***remember the above command differs for every phone!!
Now that we have this, keep a copy somewhere just in case.
You can now use a tool like FFmpeg to extract the image, use gimp to make a new one, and follow this simple guide if your confused. Or ask here and I can help.
Click to expand...
Click to collapse
Click to expand...
Click to collapse
You may have noticed none of the above used fastboot... huh, and here this is a fastboot guide!
Ok we'll just say you have a new splash image all ready and you want to flash it, but how? In the case of this phone fastboot is the way to go
Code:
fastboot flash splash1 splash.img
fastboot reboot
And done! :good: way to easy I know, put you're a pro at fastboot now so what did you expect!
Click to expand...
Click to collapse
Click to expand...
Click to collapse
And for future reference you can use dd commands to flash to your phone as well, but the don't call the "disk destroyers" for nothing!
Also its possible to flash in recovery, to the best of my knowledge I'm the only one to create flashable .zips for this (not bragging just saying I'd like to see more)
HERE Is an Aroma flashabe I made for the HTC Doubleshot
HERE Is an Aroma flashable I made for the HTC Vision
Both recovery flashable.zips allow the user to flash one of many custom splash screens and bootanimations with the easy UI Aroma brings
It is not as safe as fastboot, but I have never seen an issue when the code is done right.
I plan to make more for other phones as I have time, want one for your phone? Go through my scripts, feel free to copy and paste, I need no credit, just glad to see more people with more options!
If you need help making them, again just ask. I prefer in this thread over pm though as my inbox fills to quick...
Click to expand...
Click to collapse
Click to expand...
Click to collapse
Old stuff... in the process of editing to make things more clear....
Come one, like the previous stuff isn't fun!
Well many aren't aware that they can change the splash screen on their phone or tablet, this is just another partition most often like system, or cache.
Yes some phones will have it built into params or locked elsewhere in the firmware but often fastboot is a simple way of flashing a new splash screen.
To find out a list of your device's partitions i would advise to check you sites development thread here in XDA. But we can quickly do it as well with some simple ADB commands.
This guide does not go over ADB and for a better understanding search out one of many guides in XDA and elsewhere. (I am considering making one here as i have yet to see a comprehensive yet easy to follow guide)
Having said this, here are a few things you need to know. If you followed this guide and have fastboot working, ADB should also work just fine.
Know that fastboot is to be used in bootloader mode and ADB is used when booted into the OS or in most recoveries.
So now boot to your OS, make sure debugging is turned on, android 2.x and older this is found under settings>applications. 4.x and up it will be under developer options in settings.
Now connect your PC and phone via USB (wireless options are also a possibility here) You should notice a symbol in your status bar confirming debugging is on. (unless disabled) open a terminal/CMD and type:
Code:
adb devices
If you see your serial number lets proceed, if not post in this thread and i'll help.
Code:
adb shell
cat /proc/partitions
This will list all your partitions and their size, but this wont give you what each partition stores. There are different ways to do this for different devices, so you may need to try a few commands
Code:
ls -l /dev/block
ls -l /dev/block/platform/sdhci-tegra.3/by-name
the last command is for a device with a tegra 3 processor, of course will only work if yours has one (you may need to type 'su' to get commands to work)
you can also try:
Code:
df
busybox df -hm
Really all this isn't 100% necessary as someone probably found this out for you already. If not we just need to know the location and proper size of the image to flash.
I will help further if requested but as of know I'm going to assume we have this.
Alright lets flash the new splash screen already!
So we have a new image in .img format and it is the proper size. we will name it splash.img And as most phones that allow flashing a new splash we will call the partition its it splash1
**If your phone is different than whats listed here commands may very or not be allowed without changing bootloaders.
Back in fastboot mode, plug in phone... the usual
Code:
fastboot flash splash1 splash.img
fastboot reboot
Now that initial boot screen (before animation is replaced!) congrats!
**As you can see this section is poorly written, it is hard to universally apply a command to all phones as this command differs between them.
There are dd commands to flash just about anything, including splash screens, but dd commands can be dangerous and I would not recommend them to anyone who doesn't fully understand what they are doing.
Feel free to post with any questions!
Troubleshooting and FAQs
Some Common Questions and Answers
Q: When I open terminal/cmd and type fastboot devices i just get a blank line...
A: Well there are a number of reasons why this could happen, but here are the things you should check:
*Is the device powered on in fastboot mode?
*Is the USB cable in good shape (not a junky .99 cable)
*Do you have the proper drivers installed (Windows) Android Rules (Linux)?
*Do you have fastboot.exe on PC?
*Have you set up a path in environmental variables (Windows) or the path in .bashrc (Linux)?
****If not then what if you open the terminal/cmd in the location of adb/fastboot?
Click to expand...
Click to collapse
Click to expand...
Click to collapse
Q: When I type in command fastboot <whatever command> I get < waiting for device >
A: Then you are either not in fastboot mode on phone, bad connection to PC, missing drivers (or android rules) - fastboot is installed and working just your devices isn't communicating
Click to expand...
Click to collapse
Click to expand...
Click to collapse
Q: When I type in command fastboot <whatever command> an error message like
Code:
...
(bootloader) [ERR] Command error !!!
OKAY [ 0.016s]
finished. total time: 0.016s
A: This means the fastboot command you are trying to use isn't supported by your current bootloader, to find the list of commands available to you type in one of these two commands:
Code:
fastboot
fastboot oem ?
Q: When I type in a command to flash <XXX> it starts to work but then I get this error:
FAILED (remote: Download size too large) finished. total time: 0.002s
A: Chances are this is not the proper image for your device or your are trying to flash to the wrong partition, double check that this is the correct .img (md5sums help)
Click to expand...
Click to collapse
Click to expand...
Click to collapse
Q: When I tried to flash <XXX> I keep getting this error
Code:
sending 'recovery' (3518 KB)... OKAY
writing 'recovery'... INFOsignature checking...
FAILED (remote: signature verify fail)
A: This is because you don't have the proper permissions, you are trying to flash an unsigned image to a write protected partition. You will need to unlock bootloader or flash and engineering SPL, or find an OEM image.
This error is very device specific in the sense that I would need to know more about what you are trying to flash and what bootloader you have to answer properly
Click to expand...
Click to collapse
Click to expand...
Click to collapse
Q: When I tried to flash <XXX> or fastboot boot <XXX> I keep getting this error
Code:
downloading 'whatever here'....
FAILED (status malformed (1 bytes))
finished. total time: 0.000s
A: This is often because of a few things:
first, make sure you have a high quality USB cable, and USB port is good. Just because the cable works for charging does not mean it is a good cable.
second way I've seen this issue, user is in bootloader mode but not fastboot mode. yes I often say this is one in the same, but double check, some devices specifically have a fastboot mode within bootloader!
Click to expand...
Click to collapse
Click to expand...
Click to collapse
*Note I have found many errors are due to not running fastboot with elevated privileges, try running fastboot as administrator (Windows) or su/sudo (Linux)
As people post errors or questions I will try to add more Q&As
Happy Flashing!
Nice Guide
Hi There
Nice guide there, good to see some of the more advanced stuff like booting over usb covered :good:
Couple of things
Fairly sure you don't need java or ia32-libs to run fastboot on linux but I suppose it doesn't hurt to install it . Also if you're running the last 2 version ubuntu , 12.10 or 13.04 ( or any ubuntu flavoured Linux ) then fastboot can be installed through apt.
Code:
sudo apt-get install android-tools-fastboot
adb is in there as well
Code:
sudo apt-get install android-tools-adb
EDIT: Also you don't have to do the erase command before doing the boot command as you can use it just to boot a kernel on it's own which would be very difficult if you just used erase to erase the ramdisk, the following are both valid
Code:
fastboot boot kernel
fastboot boot kernel ramdisk.img
Thanks
Thanks for the reply!
I'll be sure to add that in, I read a bit about this but I've just used old fashion install on all my Linux distros I've used. I'll be sure to add as many new Linux user choose ubuntu and apt get is just way easier.
I haven't had a chance to edit through everything yet, last day of finals were today and I needed some study breaks, hence a quickly written guide. I have lots more to add, and looking over some of my write up I'm far from clear on some pieces.
So yeah any input is much appreciated and I'll be cleaning this up soon!
Sent from my Nexus 7 using xda premium
thank you!
good man.
demkantor said:
what is fastboot?
Click to expand...
Click to collapse
can i use fastboot to flash firmware onto my phone and bypass getprop("ro.product.name") in the updater-script? or somehow flash an unsigned update.zip?
edit: thanks for this great guide, if you could just tell me which bits of the guide you think would be relevant to me that would be awesome. i just don't want to do something off my own bat and then it be absolutely redundant.
sure, fastboot should bypass the ro.product.name (but this is also easy to take out of the updater-script) and it allows to flash unsigned zips as well.
maybe explain to me in a little more detail what you want to accomplish and I could help you do it.
The reason i ask is that flashing firmware is very dangerous and flashing the wrong firmware can easily give you a brick. If all security flasgs are removed on your device you can flash whatever you want in fastboot (for the most part) but that wont mean you should. Let me know what it is you want to flash and hopefully i can tell you if it is safe to do or not.
demkantor said:
sure, fastboot should bypass the ro.product.name (but this is also easy to take out of the updater-script) and it allows to flash unsigned zips as well.
maybe explain to me in a little more detail what you want to accomplish and I could help you do it.
The reason i ask is that flashing firmware is very dangerous and flashing the wrong firmware can easily give you a brick. If all security flasgs are removed on your device you can flash whatever you want in fastboot (for the most part) but that wont mean you should. Let me know what it is you want to flash and hopefully i can tell you if it is safe to do or not.
Click to expand...
Click to collapse
I want to update my KIS LITE (v790 with 256mb ram) with a KIS LITE firmware from ZTE website. It's for a different country/telco, the product names match but the one in the update has productname_telco instead of the stock productname on my phone which i bought directly from china. I'm pretty sure it's all compatible, i have a rooted phone, and i changed the build.prop to match productname_telco but it still errors out updating in recovery at the product name check. (weird???) if i change the zip which is quite easy, it's unsigned and won't update. i'm trying to update specifically to "Greece KIS LITE SD card upgrading instruction & software package(Cosmote)-213550B0197ZTE Kis LiteV1.0.0B01\update.zip"
@knifey_au
ok so I downloaded and took a look at the file you want to flash
Code:
assert(getprop("ro.product.device") == "roamer2" ||
getprop("ro.build.product") == "roamer2");
assert(getprop("ro.product.name") == "P752D01_Cosmote_GR");
these are the three lines that need to be the same in build prop, but in truth if you havent a custom recovery than it may still see your product info in your recovery as you have the stock kernel=stock recovery
and these are all the lines in the new build.prop you are trying to flash
Code:
# begin build properties
# autogenerated by buildinfo.sh
ro.build.id=GRK39F
ro.build.display.id=ZTE Kis LiteV1.0.0B01
ro.build.version.incremental=20130427.041932.31486
ro.build.version.sdk=10
ro.build.version.codename=REL
ro.build.version.release=2.3.6
ro.build.date=Sat Apr 27 04:30:41 CST 2013
ro.build.date.utc=1367008241
ro.build.type=user
ro.build.user=
ro.build.host=zte
ro.build.tags=release-keys
ro.product.model=ZTE Kis Lite
ro.product.brand=ZTE
ro.product.name=P752D01_Cosmote_GR
ro.product.device=roamer2
ro.product.board=roamer2
ro.product.cpu.abi=armeabi-v7a
ro.product.cpu.abi2=armeabi
ro.product.manufacturer=ZTE
ro.product.locale.language=el
ro.product.locale.region=GR
ro.wifi.channels=
ro.board.platform=msm7k
# ro.build.product is obsolete; use ro.product.device
ro.build.product=roamer2
# Do not try to parse ro.build.description or .fingerprint
ro.build.description=P752D01_Cosmote_GR-user 2.3.6 GRK39F 20130427.041932.31486 release-keys
ro.build.fingerprint=ZTE/P752D01_Cosmote_GR/roamer2:2.3.6/GRK39F/20130427.041932.31486:user/release-keys
# end build properties
#
# system.prop for surf
#
rild.libpath=/system/lib/libril-qc-1.so
rild.libargs=-d /dev/smd0
persist.rild.nitz_plmn=
persist.rild.nitz_long_ons_0=
persist.rild.nitz_long_ons_1=
persist.rild.nitz_long_ons_2=
persist.rild.nitz_long_ons_3=
persist.rild.nitz_short_ons_0=
persist.rild.nitz_short_ons_1=
persist.rild.nitz_short_ons_2=
persist.rild.nitz_short_ons_3=
ril.subscription.types=NV,RUIM
DEVICE_PROVISIONED=1
debug.sf.hw=1
debug.composition.7x27A.type=mdp
debug.composition.7x25A.type=mdp
dalvik.vm.heapsize=40m
#
# system props for the cne module
#
persist.cne.UseCne=none
persist.cne.bat.range.low.med=30
persist.cne.bat.range.med.high=60
persist.cne.loc.policy.op=/system/etc/OperatorPolicy.xml
persist.cne.loc.policy.user=/system/etc/UserPolicy.xml
persist.cne.bwbased.rat.sel=false
persist.cne.snsr.based.rat.mgt=false
persist.cne.bat.based.rat.mgt=false
persist.cne.rat.acq.time.out=30000
persist.cne.rat.acq.retry.tout=0
persist.cne.fmc.mode=false
persist.cne.fmc.init.time.out=30
persist.cne.fmc.comm.time.out=130
persist.cne.fmc.retry=false
#
# system props for the MM modules
#
media.stagefright.enable-player=true
media.stagefright.enable-meta=false
media.stagefright.enable-scan=true
media.stagefright.enable-http=true
media.stagefright.enable-fma2dp=true
media.stagefright.enable-aac=true
media.stagefright.enable-qcp=true
#
# system prop for opengles version
#
ro.opengles.version=131072
#
# system props for the data modules
#
ro.use_data_netmgrd=true
persist.data.ds_fmc_app.mode=0
#
# system props for IMS module
#
persist.ims.regmanager.mode=0
#
# system prop for requesting Master role in incoming Bluetooth connection.
#
ro.bluetooth.request.master=true
#
# system prop for Bluetooth FTP profile
#
ro.qualcomm.bluetooth.ftp=false
#
# system prop for Bluetooth SAP profile
#
ro.qualcomm.bluetooth.sap=false
#
# system prop for Bluetooth Auto connect for remote initated connections
#
ro.bluetooth.remote.autoconnect=true
#
#system property for Bluetooth discoverability timeout in seconds
#0: Always discoverable
debug.bt.discoverable_time=0
#
# System prop to enable/disable OMH. Enabled by default
#
persist.omh.enabled=1
#System prop to enable ehrpd capability
ro.config.ehrpd=true
# System property for cabl
ro.qualcomm.cabl=1
#
#System prop to determine availability of
#analog fm path
#
ro.fm.analogpath.supported=true
#
#System property for FM transmitter
#
ro.fm.transmitter=false
#
#System property for single instance recording
#
ro.fm.mulinst.recording.support=false
#
#System property for msm
#
ro.hw_plat=7x27a
#
#System property for Power Saving
#
persist.radio.add_power_save=1
#
# ADDITIONAL_BUILD_PROPERTIES
#
ro.com.google.clientidbase=android-zte
ro.com.google.clientidbase.yt=android-zte
ro.com.google.clientidbase.am=android-tmobile-{country}
ro.com.google.clientidbase.ms=android-tmobile-{country}
ro.com.google.clientidbase.gmm=android-zte
ro.build.baseband_version=P752D01_Cosmote_GRB01
ro.build.sw_internal_version=COS_GR_P752D01V1.0.0B01
ro.build.baseband_version=P752D01_EUROPEB01
ro.build.sw_internal_version=P752D01_EUROPEV1.0.0B07
ro.build.baseband_version=P752D03B01
ro.build.software_version=GENERIC_P752D03V1.0.0B01
ro.build.sw_internal_version=GENERIC_P752D03V1.0.0B01
ro.camera.intrplt.2mpto3mp=true
ro.build.baseband_version=V766B01
ro.build.software_version=GB_P752A10V0.0.0B01
ro.build.sw_internal_version=GB_P752A10V0.0.0B01
ro.config.ringtone=COSMOTE_1_BACKRINGTONE_A_2.mp3
ro.config.notification_sound=F1_New_SMS.ogg
persist.sys.timezone=Europe/Athens
ro.config.notification_sound=OnTheHunt.ogg
ro.config.alarm_alert=Alarm_Classic.ogg
ro.setupwizard.mode=OPTIONAL
ro.com.google.gmsversion=2.3_r11
persist.sys.usb.enable_switch=1
persist.sys.usb.linux_switch=1
persist.sys.usb.switch_pid=0x1351
persist.sys.usb.linux_pid=0x1351
persist.sys.usb.default.pid=0x83
ro.com.google.clientidbase=android-zte
ro.com.google.clientidbase.yt=android-zte
ro.com.google.clientidbase.am=android-zte
ro.com.google.clientidbase.ms=android-zte
ro.com.google.clientidbase.gmm=android-zte
ro.camera.intrplt.2mpto3mp=true
net.bt.name=Android
dalvik.vm.stack-trace-file=/data/anr/traces.txt
not sure what your current android version is but this one is 2.3.6 and should be fairly easy to build a custom recovery for your phone allowing you to flash nonstock .zips
just follow clockwork or twrp guide on how to create your own
and there is no firmware in this package, just kernel, ROM, and recovery so it should be safe enough to flash as long as you have a backup of original.
best of luck!
i downloaded so many new updates trying to get one to flash that i actually forgot to check the version. i'm trying to upgrade from 2.3.6. now i feel dumb. i'll try and find the right update and actually check the version number this time. *facepalm. i'll get back to you.
knifey_au said:
i downloaded so many new updates trying to get one to flash that i actually forgot to check the version. i'm trying to upgrade from 2.3.6. now i feel dumb. i'll try and find the right update and actually check the version number this time. *facepalm. i'll get back to you.
Click to expand...
Click to collapse
how do i get to the version number in the update.zip? Never mind i got it.
All the KIS lite downloads from ZTE are 2.3.6. Which is a pitty, since the 512mb version of the v790 is supposed to have ICS and go a lot faster with it. nfi if ram is the only thing they changed though so i'm not going to try and install KIS firmware on KIS lite when I don't know if it will bork things up. Unless you want to look at the phillipenes download for the v790 from ZTE website and tell me if you think it will work for the kis lite.
Hate to say it but it will doubtfully work without a lot of modifications, as handy as fastboot is it won't help with this.
Unfortunately if your phone doesn't have any custom ICS ROMs your best bet in getting one is to create a devices tree and then make it yourself. Simply flashing it from another device will probably leave you in a boot loop at the least and possibly a brick
Sent from my Nexus 4 using xda premium
Would you mind if I linked this thread in my signature?
russellvone said:
Would you mind if I linked this thread in my signature?
Click to expand...
Click to collapse
Of course not! Feel free to share this thread with whomever you choose, my goal is to help anyone and everyone. Now if I could just finish adding all I plan to...
Sent from my Nexus 4 using xda premium
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
Hi,
Platform/Software
Asus MemoPad 7 ME176CX
Adroid Lollipop 5.0 most recent (second Lollipop firmware)
and thanks to cyandro and Mis012, who had helped a lot: The device is happily rooted.
Also:
A Gentoo Linux PC, updated daily
***NO WIFI*** (due to the vendor, who prints on the box "linux driver available" and "Linux compatibel" and
the offered driver is for kernel 2.6.x. Thank you vendor for supporting linux!
Many things I did by connecting my tablet via USB and MTP-stuff to my Gentoo Box.
But with Lnux deploy, which was mentioned positively elsewhere on this forum, I failed.
For good reasons, the Linux Deploy apk is an Linux Installer, which fetches the "real thing"
(the linux distro) via Wifi from the internet...and BANG! I am out of luck.
I definetly want a Linux on my tablet and I dont want to destroy Android. Dual boot
would be fine, chroot may be ok (but then, the unmodified Android kernel will run.).
Is there any trick, to convince Linux Deploy to access the SDCard for fetching the
distro or circumvent the need of a working WiFi connection aomehow?
Or is there any other way to install/dual boot a Linux from SDcard?
(I have some experience with Linux and Linux setup...but not on
a tablet, which is build to run a (in comparison) locked Android).
Thank you very much for any Linux on my tablet in advance!
Best regards,
tuxic
tuxic001 said:
Hi,
Platform/Software
Asus MemoPad 7 ME176CX
Adroid Lollipop 5.0 most recent (second Lollipop firmware)
and thanks to cyandro and Mis012, who had helped a lot: The device is happily rooted.
Also:
A Gentoo Linux PC, updated daily
***NO WIFI*** (due to the vendor, who prints on the box "linux driver available" and "Linux compatibel" and
the offered driver is for kernel 2.6.x. Thank you vendor for supporting linux!
Many things I did by connecting my tablet via USB and MTP-stuff to my Gentoo Box.
But with Lnux deploy, which was mentioned positively elsewhere on this forum, I failed.
For good reasons, the Linux Deploy apk is an Linux Installer, which fetches the "real thing"
(the linux distro) via Wifi from the internet...and BANG! I am out of luck.
I definetly want a Linux on my tablet and I dont want to destroy Android. Dual boot
would be fine, chroot may be ok (but then, the unmodified Android kernel will run.).
Is there any trick, to convince Linux Deploy to access the SDCard for fetching the
distro or circumvent the need of a working WiFi connection aomehow?
Or is there any other way to install/dual boot a Linux from SDcard?
(I have some experience with Linux and Linux setup...but not on
a tablet, which is build to run a (in comparison) locked Android).
Thank you very much for any Linux on my tablet in advance!
Best regards,
tuxic
Click to expand...
Click to collapse
I have my tablet back and I am working on it
For the chroot, I recommend Complete Linux Installer (linuxonandroid project) and x86 ubuntu from their site.
Mis012 said:
I have my tablet back and I am working on it
For the chroot, I recommend Complete Linux Installer (linuxonandroid project) and x86 ubuntu from their site.
Click to expand...
Click to collapse
Hi Mis012,
in the meanwhile I got a chrooted Linux (ARCH Linux) running via Linux Deploy. I checked Linux complete installer, but it does not work for me.
This is the result of buying a new USB WIFI dongle, which this time is proofen to run with drivers, which already are included
in the Linux kernel -- by the company, which build the chipset.
For those who haveing the same problem I had:
I used a USB WIFI dongle with Atheros chipset:
lsusb -v said:
idVendor 0x0cf3 Atheros Communications, Inc.
idProduct 0x9271 AR9271 802.11n
Beside the normal Wifi stuff you need in the kernel, these drivers are
needed for that chipset (excerpt of lsmods output):
ath9k_htc, ath9k_common, ath9k_hw, ath
The only drawback of this setup is, that it only runs via VNC (Juice VNC).
I tired the framebuffer and X11 automatic setup of Linux deploy but did not receive anything more
than a black screen.
It would be nice to have a real X11 running, so the delays, which come with VNC are no longer there.
Best regards,
tuxic
tuxic001 said:
Hi Mis012,
in the meanwhile I got a chrooted Linux (ARCH Linux) running via Linux Deploy. I checked Linux complete installer, but it does not work for me.
This is the result of buying a new USB WIFI dongle, which this time is proofen to run with drivers, which already are included
in the Linux kernel -- by the company, which build the chipset.
For those who haveing the same problem I had:
I used a USB WIFI dongle with Atheros chipset:
lsusb -v said:
idVendor 0x0cf3 Atheros Communications, Inc.
idProduct 0x9271 AR9271 802.11n
Beside the normal Wifi stuff you need in the kernel, these drivers are
needed for that chipset (excerpt of lsmods output):
ath9k_htc, ath9k_common, ath9k_hw, ath
The only drawback of this setup is, that it only runs via VNC (Juice VNC).
I tired the framebuffer and X11 automatic setup of Linux deploy but did not receive anything more
than a black screen.
It would be nice to have a real X11 running, so the delays, which come with VNC are no longer there.
Best regards,
tuxic
Click to expand...
Click to collapse
Don't worry, tutorial is coming
I succesfully loaded rEFInd without powered hub, so some config editing and maybe sdcard linux?
As for complete linux installer, it is important to not download image in the app, but download one of these http://sourceforge.net/projects/linuxonandroid/files/Ubuntu/13.10/x86/
Mis012 said:
Don't worry, tutorial is coming
I succesfully loaded rEFInd without powered hub, so some config editing and maybe sdcard linux?
As for complete linux installer, it is important to not download image in the app, but download one of these http://sourceforge.net/projects/linuxonandroid/files/Ubuntu/13.10/x86/
Click to expand...
Click to collapse
Hi Mis012,
oh wait wait...!!!
You are WAY TOO FAST for me!
Did I understand that correctly:
After I googled for rEFInd, which seems to be a EFI bootloader and reading your words a second++ time, it /sounds/ to me, that you have found
a way around the locked bootloader of our beloved ME176CX? ... or does my brain need just another cold boot ?
I bougth an OTG enabled powered hub from Amazon, with which I could enter the UEFI of the tablet with some luck. Since in a previous posting in another thread
one reports, that this alone had bricked his tablet on a very low level I left UEFI as soon I had entered it.
What I don't understand: If one enters the bootloader screen (adb reboot-bootloader) "secure boot: YES" is displayed. From another posting I think to remember
that in UEFI itsself "secure boot: NO" is displayed.
And as far as I know, the bootloader is locked until now, which means nothing else can be booted than a signed kernel/image. That's why things like Cyanogenmod are
diamonds we simply have to say "Fair well, good bye" to? Or is there any silver lining on the horizon?
As a anti depressive medicine I to pills of took X-Posed forte yesterday, which gave me a bootloop whith a certain module. But I could fix that.
X-Posed seem to be half Lollipop ready. The main reason (X-Privacy) was a disappointment, since it (and other firewall/privacy modules I tested) does not work on Lollipop yet.
I really don't like a man in the middle, even it is the biggest search engine ever.
Which brings me back to Ubuntu. According to this
http://ubuntuforums.org/showthread.php?t=2141952
https://micahflee.com/2014/04/ubuntu-is-finally-taking-privacy-seriously/
and the need for this to exist
https://fixubuntu.com/
makes me feel not THAT comfortable when it comes to UBUNTU.
Will be there a way to install something else Linuxish with your recipe, Mis012, without
leaving the glorious path of you enlightened mind ? 8) <very big smiley here!>
I am totally curious about what you have found in the Deep Web of the ME176CX ...
Best regards,
tuxic
tuxic001 said:
Hi Mis012,
oh wait wait...!!!
You are WAY TOO FAST for me!
Did I understand that correctly:
After I googled for rEFInd, which seems to be a EFI bootloader and reading your words a second++ time, it /sounds/ to me, that you have found
a way around the locked bootloader of our beloved ME176CX? ... or does my brain need just another cold boot ?
I bougth an OTG enabled powered hub from Amazon, with which I could enter the UEFI of the tablet with some luck. Since in a previous posting in another thread
one reports, that this alone had bricked his tablet on a very low level I left UEFI as soon I had entered it.
What I don't understand: If one enters the bootloader screen (adb reboot-bootloader) "secure boot: YES" is displayed. From another posting I think to remember
that in UEFI itsself "secure boot: NO" is displayed.
And as far as I know, the bootloader is locked until now, which means nothing else can be booted than a signed kernel/image. That's why things like Cyanogenmod are
diamonds we simply have to say "Fair well, good bye" to? Or is there any silver lining on the horizon?
As a anti depressive medicine I to pills of took X-Posed forte yesterday, which gave me a bootloop whith a certain module. But I could fix that.
X-Posed seem to be half Lollipop ready. The main reason (X-Privacy) was a disappointment, since it (and other firewall/privacy modules I tested) does not work on Lollipop yet.
I really don't like a man in the middle, even it is the biggest search engine ever.
Which brings me back to Ubuntu. According to this
http://ubuntuforums.org/showthread.php?t=2141952
https://micahflee.com/2014/04/ubuntu-is-finally-taking-privacy-seriously/
and the need for this to exist
https://fixubuntu.com/
makes me feel not THAT comfortable when it comes to UBUNTU.
Will be there a way to install something else Linuxish with your recipe, Mis012, without
leaving the glorious path of you enlightened mind ? 8) <very big smiley here!>
I am totally curious about what you have found in the Deep Web of the ME176CX ...
Best regards,
tuxic
Click to expand...
Click to collapse
It is boot manager, not bootloader. Sorry
But, I (or you using my tutorial) can try grub2 or so
Theoreticaly, you only need to take some linux, install it on your PC, delete things you do not need, install the VNC server linuxonandroid uses (ThightVNC or something like that) and copy the init.sh from their image, and slightly edit it, then move it to the same location they had it in. Then use dd command to make a .img of this linux system, and try it in the app. You can try kali linux and post the working result to me
Look at first part of my tutorial: http://forum.xda-developers.com/memo-pad-7/help/how-to-dual-boot-me176cx-part-1-t3183437
Mis012 said:
It is boot manager, not bootloader. Sorry
Click to expand...
Click to collapse
Oh...uuuh...sorry...I confused that...
Is that correct:
CPUs "mini loader in CPU ROM" loads UEFI
UEFI loads Android bootloader
Android bootloader loads Android Linux kernel
Kernel starts init and here we go...
WIth rEFInd you will do:
CPUs "mini loader in CPU ROM" loads UEFI
UEFI loads rEFIind
(user choose from which source to boot)
rEFInd loads either
Android bootloader or Ubunto kernel (or ? Or is a grub layer needed here?)
(and in case the user has choosen Android
Android bootloader loads Android Linux kernel
Kernel starts init and here we go...
Correct? I am sure, I confused another detail...
tuxic001 said:
Oh...uuuh...sorry...I confused that...
Is that correct:
CPUs "mini loader in CPU ROM" loads UEFI
UEFI loads Android bootloader
Android bootloader loads Android Linux kernel
Kernel starts init and here we go...
WIth rEFInd you will do:
CPUs "mini loader in CPU ROM" loads UEFI
UEFI loads rEFIind
(user choose from which source to boot)
rEFInd loads either
Android bootloader or Ubunto kernel (or ? Or is a grub layer needed here?)
(and in case the user has choosen Android
Android bootloader loads Android Linux kernel
Kernel starts init and here we go...
Correct? I am sure, I confused another detail...
Click to expand...
Click to collapse
Yes, that's it. The grub layer is not needed as linux kernel acts as bootloader from some version. But, maybe you can use another bootloader to load android kernel (grub2 ?) and then hire someone to make the cyanogenmod.
Mis012 said:
Yes, that's it. The grub layer is not needed as linux kernel acts as bootloader from some version. But, maybe you can use another bootloader to load android kernel (grub2 ?) and then hire someone to make the cyanogenmod.
Click to expand...
Click to collapse
Why not to load Cyanogenmod (supposing one would exist) with rEFINd. Why do we need grub here?
tuxic001 said:
Why not to load Cyanogenmod (supposing one would exist) with rEFINd. Why do we need grub here?
Click to expand...
Click to collapse
Becouse rEFInd is not a bootloader. You need bootloader. But, maybe when we will obtain kernel source code, we can convert it to efi binary and then run it with refind?
Mis012 said:
Becouse rEFInd is not a bootloader. You need bootloader. But, maybe when we will obtain kernel source code, we can convert it to efi binary and then run it with refind?
Click to expand...
Click to collapse
...I thoughr the Linux kernel contains its own bootloader...does Google removed that stuff?
...I am still confused....
<scratching my head>
tuxic001 said:
...I thoughr the Linux kernel contains its own bootloader...does Google removed that stuff?
...I am still confused....
<scratching my head>
Click to expand...
Click to collapse
It doesn't contain it, it can be converted to efi binary so it will work like bootloader (i think)
maybe this is what I meaned https://www.kernel.org/doc/Documentation/efi-stub.txt
---------- Post added at 12:42 PM ---------- Previous post was at 12:37 PM ----------
http://kroah.com/log/blog/2013/09/02/booting-a-self-signed-linux-kernel/
This is what I wanted to say. Do this with our kernel, and we have won the game
Mis012 said:
It doesn't contain it, it can be converted to efi binary so it will work like bootloader (i think)
maybe this is what I meaned https://www.kernel.org/doc/Documentation/efi-stub.txt
---------- Post added at 12:42 PM ---------- Previous post was at 12:37 PM ----------
http://kroah.com/log/blog/2013/09/02/booting-a-self-signed-linux-kernel/
This is what I wanted to say. Do this with our kernel, and we have won the game
Click to expand...
Click to collapse
Hi Mis012,
VERY interesting links! Thanks a lot!
...but for now I fear this stuff is far from what I am capable to do...
Yesterday XPosed and a fixed bootloop and today the boot of an self signed kernel
from a locked bootloader ? I think, THIS learning curve is a little TOO steep for me in
the moment.
One would need tools or scripts to automate that process and a way to recover from
even the worst blocks/bricks/hangs...
But if I understood you correctly from you previous posting, with rEFInd we have
a "loader in the middle" (I know, it is not a bootloader) to get other things booted than
linux?
tuxic001 said:
Hi Mis012,
VERY interesting links! Thanks a lot!
...but for now I fear this stuff is far from what I am capable to do...
Yesterday XPosed and a fixed bootloop and today the boot of an self signed kernel
from a locked bootloader ? I think, THIS learning curve is a little TOO steep for me in
the moment.
One would need tools or scripts to automate that process and a way to recover from
even the worst blocks/bricks/hangs...
But if I understood you correctly from you previous posting, with rEFInd we have
a "loader in the middle" (I know, it is not a bootloader) to get other things booted than
linux?
Click to expand...
Click to collapse
Yes, it is supposed to run .efi binaries. My problem is, that even in ugly text mode, I can select with volume buttons, but I can NOT confirm the selection with power button. Maybe you could fix it in the source (there should be something like menu.c) so the power button would make selections. Even with powered hub (which I do not have) I would like to select the OS to boot just with device buttons.
http://sourceforge.net/projects/refind/files/0.9.0/refind-src-0.9.0.zip/download
---------- Post added at 03:30 PM ---------- Previous post was at 03:15 PM ----------
Code:
// react to key press
switch (key.ScanCode) {
case SCAN_UP:
UpdateScroll(&State, SCROLL_LINE_UP);
break;
case SCAN_LEFT:
UpdateScroll(&State, SCROLL_LINE_LEFT);
break;
case SCAN_DOWN:
UpdateScroll(&State, SCROLL_LINE_DOWN);
break;
case SCAN_RIGHT:
UpdateScroll(&State, SCROLL_LINE_RIGHT);
break;
case SCAN_HOME:
UpdateScroll(&State, SCROLL_FIRST);
break;
case SCAN_END:
UpdateScroll(&State, SCROLL_LAST);
break;
case SCAN_PAGE_UP:
UpdateScroll(&State, SCROLL_PAGE_UP);
break;
case SCAN_PAGE_DOWN:
UpdateScroll(&State, SCROLL_PAGE_DOWN);
break;
case SCAN_ESC:
MenuExit = MENU_EXIT_ESCAPE;
break;
case SCAN_INSERT:
case SCAN_F2:
MenuExit = MENU_EXIT_DETAILS;
break;
case SCAN_F10:
egScreenShot();
break;
case 0x0016: // F12
if (EjectMedia())
MenuExit = MENU_EXIT_ESCAPE;
break;
}
This appears to be the part of code we need to change. But question is, when volume keys act as arrows up/down (how is this possible?), as what key does act the power button?
---------- Post added at 04:11 PM ---------- Previous post was at 03:30 PM ----------
Mis012 said:
This appears to be the part of code we need to change. But question is, when volume keys act as arrows up/down (how is this possible?), as what key does act the power button?
Click to expand...
Click to collapse
Maybe we can set volume up to confirm, so you can only scroll down?
Or set the timeout to not disappear but to select the option selected at the point when it goes to zero?
Maybe just delete this:
Code:
if (HaveTimeout) {
// the user pressed a key, cancel the timeout
StyleFunc(Screen, &State, MENU_FUNCTION_PAINT_TIMEOUT, L"");
HaveTimeout = FALSE;
if (GlobalConfig.ScreensaverTime == -1) { // cancel start-with-blank-screen coding
GlobalConfig.ScreensaverTime = 0;
if (!GlobalConfig.TextOnly)
BltClearScreen(TRUE);
}
tuxic001 said:
I bougth an OTG enabled powered hub from Amazon, with which I could enter the UEFI of the tablet with some luck.
Click to expand...
Click to collapse
If you've a powered hub, there nothing is preventing you from booting Linux directly on your tablet. For example if you put an Ubuntu ISO (like Lubuntu or Xubuntu, normal Ubuntu might be too heavy) on a USB stick, then plug in your powered hub and go to the boot order you can select to boot from the USB stick and it should boot without any problems. I made myself a custom Arch Linux installation which is now able to boot on the ME176C directly when I plug it in with the USB stick. Haven't tested with the SD card yet, not sure if UEFI can boot from it.
tuxic001 said:
Since in a previous posting in another thread
one reports, that this alone had bricked his tablet on a very low level I left UEFI as soon I had entered it.
Click to expand...
Click to collapse
No worries, I've been in there several times and my tablet is still fine. As long you only touch the boot order in the boot menu you shouldn't get any problems.
tuxic001 said:
What I don't understand: If one enters the bootloader screen (adb reboot-bootloader) "secure boot: YES" is displayed. From another posting I think to remember
that in UEFI itsself "secure boot: NO" is displayed.
And as far as I know, the bootloader is locked until now, which means nothing else can be booted than a signed kernel/image. That's why things like Cyanogenmod are
diamonds we simply have to say "Fair well, good bye" to? Or is there any silver lining on the horizon?
Click to expand...
Click to collapse
I don't know exactly but I can definitely confirm that we can boot even unsigned UEFI installations on our tablet, Secure Boot is definitely turned off in UEFI. The Android bootloader is locked though so you can't simply boot an Android installation without replacing the bootloader too. If someone manages to compile/get an alternative bootloader running on our device that is easily unlockable then CyanogenMod will be definitely possible. So tl;dr it's possible but not that easy to accomplish (for me at least, not experienced enough in this field). I think UEFI's Secure Boot is not the same as the bootloader's Secure Boot here, they just happen to have the same name.
cyandro said:
If you've a powered hub, there nothing is preventing you from booting Linux directly on your tablet. For example if you put an Ubuntu ISO (like Lubuntu or Xubuntu, normal Ubuntu might be too heavy) on a USB stick, then plug in your powered hub and go to the boot order you can select to boot from the USB stick and it should boot without any problems. I made myself a custom Arch Linux installation which is now able to boot on the ME176C directly when I plug it in with the USB stick. Haven't tested with the SD card yet, not sure if UEFI can boot from it.
No worries, I've been in there several times and my tablet is still fine. As long you only touch the boot order in the boot menu you shouldn't get any problems.
I don't know exactly but I can definitely confirm that we can boot even unsigned UEFI installations on our tablet, Secure Boot is definitely turned off in UEFI. The Android bootloader is locked though so you can't simply boot an Android installation without replacing the bootloader too. If someone manages to compile/get an alternative bootloader running on our device that is easily unlockable then CyanogenMod will be definitely possible. So tl;dr it's possible but not that easy to accomplish (for me at least, not experienced enough in this field). I think UEFI's Secure Boot is not the same as the bootloader's Secure Boot here, they just happen to have the same name.
Click to expand...
Click to collapse
As you have powered usb hub, you can try to boot android with GRUB2, or compile the kernel as efi binary so you can run it directly.
Mis012 said:
Yes, it is supposed to run .efi binaries. My problem is, that even in ugly text mode, I can select with volume buttons, but I can NOT confirm the selection with power button. Maybe you could fix it in the source (there should be something like menu.c) so the power button would make selections. Even with powered hub (which I do not have) I would like to select the OS to boot just with device buttons.
http://sourceforge.net/projects/refind/files/0.9.0/refind-src-0.9.0.zip/download
---------- Post added at 03:30 PM ---------- Previous post was at 03:15 PM ----------
Code:
// react to key press
switch (key.ScanCode) {
case SCAN_UP:
UpdateScroll(&State, SCROLL_LINE_UP);
break;
case SCAN_LEFT:
UpdateScroll(&State, SCROLL_LINE_LEFT);
break;
case SCAN_DOWN:
UpdateScroll(&State, SCROLL_LINE_DOWN);
break;
case SCAN_RIGHT:
UpdateScroll(&State, SCROLL_LINE_RIGHT);
break;
case SCAN_HOME:
UpdateScroll(&State, SCROLL_FIRST);
break;
case SCAN_END:
UpdateScroll(&State, SCROLL_LAST);
break;
case SCAN_PAGE_UP:
UpdateScroll(&State, SCROLL_PAGE_UP);
break;
case SCAN_PAGE_DOWN:
UpdateScroll(&State, SCROLL_PAGE_DOWN);
break;
case SCAN_ESC:
MenuExit = MENU_EXIT_ESCAPE;
break;
case SCAN_INSERT:
case SCAN_F2:
MenuExit = MENU_EXIT_DETAILS;
break;
case SCAN_F10:
egScreenShot();
break;
case 0x0016: // F12
if (EjectMedia())
MenuExit = MENU_EXIT_ESCAPE;
break;
}
This appears to be the part of code we need to change. But question is, when volume keys act as arrows up/down (how is this possible?), as what key does act the power button?
---------- Post added at 04:11 PM ---------- Previous post was at 03:30 PM ----------
Maybe we can set volume up to confirm, so you can only scroll down?
Or set the timeout to not disappear but to select the option selected at the point when it goes to zero?
Maybe just delete this:
Code:
if (HaveTimeout) {
// the user pressed a key, cancel the timeout
StyleFunc(Screen, &State, MENU_FUNCTION_PAINT_TIMEOUT, L"");
HaveTimeout = FALSE;
if (GlobalConfig.ScreensaverTime == -1) { // cancel start-with-blank-screen coding
GlobalConfig.ScreensaverTime = 0;
if (!GlobalConfig.TextOnly)
BltClearScreen(TRUE);
}
Click to expand...
Click to collapse
Hi Mis012,
sorry for not responding for a while: I had to buy something to eat and drink.
By the way: May be it would ease the postings exchange a little bit; I am here at UTC+1 (+1 additional hour
summer saveing time. Currently it is 17:19 local time).
To the code and the handling of keys in general (please excuse if I am talking about already known for centuries...):
The SoC( System on Chip) -- in this case the CPU and the chipset) in embedded system often are handling the recognition
of key pressing events via GPIOs (General Purpose Input/Output <pins>). This CPU/chipset pins can be configured via software
to what they have act as: Input line, output (signal) line, A/D converter input, PWM pins etc....
There are only three keys (on/off switches): Volume Up, Volum Down (two seperate switched combined under one big plastic "bridge")
and one power switch (on/off). ALL switches are open by default and if released. Even the power switch is no bistable switch with two
rest positions but a switch witch only gives contact when pressed.
There are three GPIO lines - each used for one of the switches. Each line is "pulled up" via a resistore to 5V+. The switch pulls the line
down to ground when pressed.
When done a certain bit in a certain register of the CPU is switched and/or an interrupt is generated.
A piece of software is tied to that interrupt (good solution) or is polling the according registers (active idle processing. BAD!).
What use see in the source code is the keyScanCode, which is the software representation of the register/s in question.
The case-switch is comparing the keyScancode with the bit pattern of the register for that case of certain key press events.
The reason, why "on/off" is not recognized is either: The case switch is not asking for the correct keyScanCode for "Power button pressed"
OR (which would be bad) "Volume up/down" is represented by the content of "keyScanCode" and "Power key pressed" is handled via
another register.
If you can find a piece of code, which seems to print anything onto the screen AND you can get out of the program while it is executed, my suggestion would be to
modify the code like this:
[/COLOR]
Code:
// react to key press
### Add print code here THIS IS ONLY AN EXAMPLE!
printf( "[keycode]>0x%02<\n",key.ScanCode );
switch (key.ScanCode) {
case SCAN_UP:
UpdateScroll(&State, SCROLL_LINE_UP);
break;
case SCAN_LEFT:
UpdateScroll(&State, SCROLL_LINE_LEFT);
break;
case SCAN_DOWN:
UpdateScroll(&State, SCROLL_LINE_DOWN);
break;
case SCAN_RIGHT:
UpdateScroll(&State, SCROLL_LINE_RIGHT);
break;
case SCAN_HOME:
UpdateScroll(&State, SCROLL_FIRST);
break;
case SCAN_END:
UpdateScroll(&State, SCROLL_LAST);
break;
case SCAN_PAGE_UP:
UpdateScroll(&State, SCROLL_PAGE_UP);
break;
case SCAN_PAGE_DOWN:
UpdateScroll(&State, SCROLL_PAGE_DOWN);
break;
case SCAN_ESC:
MenuExit = MENU_EXIT_ESCAPE;
break;
case SCAN_INSERT:
case SCAN_F2:
MenuExit = MENU_EXIT_DETAILS;
break;
case SCAN_F10:
egScreenShot();
break;
case 0x0016: // F12
if (EjectMedia())
MenuExit = MENU_EXIT_ESCAPE;
break;
}
This way each keycode is printed onto the screen (ATTENTION! This can and will completly scre up the contents of the screen!!! That's why you need a way
out of it *blindly*!)
No press power and release it. WIth luck you can see the changes in the print and can change the case-switch accordingly.
But this is only a rugh idea.
First I need something to eat and later I will take a look into the code itsself...
Keep hacking! 8)
Best regards
tuxic
cyandro said:
If you've a powered hub, there nothing is preventing you from booting Linux directly on your tablet. For example if you put an Ubuntu ISO (like Lubuntu or Xubuntu, normal Ubuntu might be too heavy) on a USB stick, then plug in your powered hub and go to the boot order you can select to boot from the USB stick and it should boot without any problems. I made myself a custom Arch Linux installation which is now able to boot on the ME176C directly when I plug it in with the USB stick. Haven't tested with the SD card yet, not sure if UEFI can boot from it.
No worries, I've been in there several times and my tablet is still fine. As long you only touch the boot order in the boot menu you shouldn't get any problems.
I don't know exactly but I can definitely confirm that we can boot even unsigned UEFI installations on our tablet, Secure Boot is definitely turned off in UEFI. The Android bootloader is locked though so you can't simply boot an Android installation without replacing the bootloader too. If someone manages to compile/get an alternative bootloader running on our device that is easily unlockable then CyanogenMod will be definitely possible. So tl;dr it's possible but not that easy to accomplish (for me at least, not experienced enough in this field). I think UEFI's Secure Boot is not the same as the bootloader's Secure Boot here, they just happen to have the same name.
Click to expand...
Click to collapse
Hi cyandro,
iiieee... I am not feeling very comfortable with the fiddling in the UEFI...
On the other hand:
As far as I don't know: Reaching the UEFI cannot be block by any setting, which can be made
in the UEFI, or? Otherwise UEFI would make itsself needless.
Or is this a wish of a wannabe hacker?
Best regards,
tuxic
tuxic001 said:
Hi cyandro,
iiieee... I am not feeling very comfortable with the fiddling in the UEFI...
On the other hand:
As far as I don't know: Reaching the UEFI cannot be block by any setting, which can be made
in the UEFI, or? Otherwise UEFI would make itsself needless.
Or is this a wish of a wannabe hacker?
Best regards,
tuxic
Click to expand...
Click to collapse
It's much like going into the BIOS settings or UEFI settings on an usual PC, the setup is very similar to one you would also find on normal PCs. There is not much you can break as long you don't stop fiddling around with the minor settings and use it only for the boot order. I guess you could set a password for UEFI access (but why?), if you forget it you will at least have a major problem to get in there again, but otherwise as long you actually read and know what you're changing you can't do much wrong.
tuxic001 said:
Hi cyandro,
iiieee... I am not feeling very comfortable with the fiddling in the UEFI...
On the other hand:
As far as I don't know: Reaching the UEFI cannot be block by any setting, which can be made
in the UEFI, or? Otherwise UEFI would make itsself needless.
Or is this a wish of a wannabe hacker?
Best regards,
tuxic
Click to expand...
Click to collapse
Not reaching UEFI at all, but the simple way (pressing f2 on keyboard) will only work if the timeout is set to something other then 0. This can be edited with efibootmgr so it is not a big problem On our tablet it is set to 1 by default so you can set it to 0 to speed up booting by one sec, but if anything goes wrong then you would have a serious problem.
Make sure to read this guide completely before starting.
You will lose all data on the tablet, make a backup of important data before you start.
What you need:
- a Linux installation. Don't use a VM! Use a live USB, if you don't have Linux installed, but don't use a virtual machine.
- a microusb cable to connect your tablet to the PC
- (if you go with hw option) some way to open the tablet (pry tool, opening picks, etc)
- (if you go with hw option) something conductive (metal tweezers, a paper clip, a piece of wire, etc)
- (if you go with sw option) mtk-su from https://forum.xda-developers.com/android/development/amazing-temp-root-mediatek-armv8-t3922213
- amonet-mustang.zip from this post
- finalize.zip from this post
- update-kindle-NS6312_user_1827_0002517050244.bin: https://fireos-tablet-src.s3.amazon...ate-kindle-NS6312_user_1827_0002517050244.bin
- Magisk-v19.3.zip: https://github.com/topjohnwu/Magisk/releases/download/v19.3/Magisk-v19.3.zip
Install python3, PySerial, adb and fastboot. For Debian/Ubuntu something like this should work "sudo apt install python3 python3-serial android-tools-adb android-tools-fastboot".
0. Disconnect the tablet and all other Android devices from the PC.
1. Back up whatever important data you have on the device and perform a complete factory reset of the tablet. When going through the initial setup, don't connect to a network (see below on how to do that).
2. Disable or uninstall ModemManager from your Linux installation
3. At this point you need to get your tablet into the bootrom download mode. There are two ways it can be achieved.
a) If your tablet works, you can use the software method (which doesn't require opening the tablet) or the hardware method. Note that if something goes horribly wrong, you might still be required to open up the tablet.
b) If your tablet doesn't boot (bricked), you can only use the hardware method
----------------------------------------------------------------------------------------------------
Software method:
This will get you into bootrom mode by obtaining temporary root and temporarily bricking the device.
1. Download mtk-su from https://forum.xda-developers.com/android/development/amazing-temp-root-mediatek-armv8-t3922213
2. Enable developer mode and USB debugging on the tablet
3. Unzip the mtk-su archive
4. Transfer the executable to your tablet: "adb push arm/mtk-su /data/local/tmp"
5. Run "adb shell"
6. Keep the screen on and run the following commands in the shell on the device:
Code:
cd /data/local/tmp
./mtk-su
getenforce # Just to confirm it says Permissive
echo 0 > /sys/block/mmcblk0boot0/force_ro
dd if=/dev/zero of=/dev/block/mmcblk0boot0 bs=512 count=8
This is the sort of output you should see for that step:
Code:
[email protected]:~/Downloads/mtk-su $ adb shell
mustang:/ $ cd /data/local/tmp
mustang:/data/local/tmp $ ./mtk-su
New UID/GID: 0/0
mustang:/data/local/tmp # getenforce
Permissive
mustang:/data/local/tmp # echo 0 > /sys/block/mmcblk0boot0/force_ro
mustang:/data/local/tmp # dd if=/dev/zero of=/dev/block/mmcblk0boot0 bs=512 count=8
8+0 records in
8+0 records out
4096 bytes transferred in 0.001 secs (4096000 bytes/sec)
mustang:/data/local/tmp #
Don't close the console just yet.
Hardware method:
This will get you into bootrom mode by opening up the tablet and shorting a point to the ground.
1. Shut your device down and disconnect it from USB
2. Use a pry tool to remove the back shell from the tablet. Start at the bottom and work your way up. There are no cables between the back shell and the motherboard.
3. You will need to get something conductive and temporarily connect a point to the ground. A point suggested by @ggow is: https://forum.xda-developers.com/showpost.php?p=79683131&postcount=22. You will need to pop up the metallic shield to access it. Alternatively, there are multiple points on the back of the PCB which also work (marked as CLK/CMD/DAT0).
----------------------------------------------------------------------------------------------------
4. At this point if you went with software method, you should have a root shell open, and if you went with the hardware method you should have a capacitor or a testpoint grounded to the shield.
5. Now, open another terminal on your PC, extract amonet-mustang.zip, navigate to it, and run `sudo ./bootrom-step.sh`. It should print "Waiting for the bootrom".
6.
a) For the software method, you should already have the USB cable plugged in. Type "reboot" in the first terminal (the one you that's running "adb shell"). [If you're trying this for the second time because it didn't work for the first time, you won't have an "adb shell" terminal. In that case, just plugging the USB cable in should be enough.]
b) For the hardware method, ensure the short is applied and then plug in the USB cable.
7. You should see the following device appear in your "dmesg" log:
Code:
[1141765.113884] usb 3-1.4.3.1: USB disconnect, device number 59
[1141783.057101] usb 3-1.4.3.1: new full-speed USB device number 60 using xhci_hcd
[1141783.226498] usb 3-1.4.3.1: New USB device found, idVendor=0e8d, idProduct=0003, bcdDevice= 1.00
[1141783.226502] usb 3-1.4.3.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[1141783.506877] cdc_acm 3-1.4.3.1:1.0: ttyACM0: USB ACM device
This *must* be the device you see. If you see a "preloader" device instead, your short probably didn't work (for the hw method), or your system inexinexplicably didn't brick (for the sw method). Unplug everything and try again. If the tablet doesn't shut down, you might need to open it up and disconnect the battery.
8. The script should now tell you to remove the short. If you went with hardware method, you do need to remove it first. Otherwise, just press Enter.
9. The script will now proceed to downgrade your device and flash some essential files. Just let it be, it will take about 4 minutes. You should see the following output:
Code:
[2019-06-30 02:48:59.334098] Waiting for bootrom
[2019-06-30 02:50:41.179571] Found port = /dev/ttyACM0
[2019-06-30 02:50:41.180204] Handshake
* * * If you have a short attached, remove it now * * *
* * * Press Enter to continue * * *
[2019-06-30 02:50:49.195782] Init crypto engine
[2019-06-30 02:50:49.214278] Disable caches
[2019-06-30 02:50:49.214801] Disable bootrom range checks
[2019-06-30 02:50:49.229877] Load payload from ../brom-payload/build/payload.bin = 0x46B8 bytes
[2019-06-30 02:50:49.233418] Send payload
[2019-06-30 02:50:49.958957] Let's rock
[2019-06-30 02:50:49.959812] Wait for the payload to come online...
[2019-06-30 02:50:50.904341] all good
[2019-06-30 02:50:50.904714] Check GPT
[2019-06-30 02:50:51.240034] gpt_parsed = {'proinfo': (1024, 6144), 'PMT': (7168, 9216), 'kb': (16384, 2048), 'dkb': (18432, 2048), 'lk': (20480, 2048), 'tee1': (22528, 10240), 'tee2': (32768, 10240), 'metadata': (43008, 80896), 'MISC': (123904, 1024), 'reserved': (124928, 16384), 'boot': (141312, 32768), 'recovery': (174080, 40960), 'system': (215040, 6354944), 'vendor': (6569984, 460800), 'cache': (7030784, 1024000), 'userdata': (8054784, 22722527)}
[2019-06-30 02:50:51.240157] Check boot0
[2019-06-30 02:50:51.485287] Check rpmb
[2019-06-30 02:50:51.695083] Downgrade rpmb
[2019-06-30 02:50:51.696759] Recheck rpmb
[2019-06-30 02:50:52.591407] rpmb downgrade ok
[2019-06-30 02:50:52.837668] Clear preloader 1
[1 / 1]
[2019-06-30 02:50:52.859908] Clear preloader 2
[1 / 1]
[2019-06-30 02:50:52.882059] Flash lk-payload
[4 / 4]
[2019-06-30 02:50:53.214382] Flash tz
[5547 / 5547]
[2019-06-30 02:52:51.150851] Flash lk
[651 / 651]
[2019-06-30 02:53:05.192112] Inject microloader
[4 / 4]
[2019-06-30 02:53:05.524154] Flash preloader
[271 / 271]
[2019-06-30 02:53:11.525329] Restore preloader
[8 / 8]
[2019-06-30 02:53:11.695348] Reboot to unlocked fastboot
If the script freezes at some point, you will have to restart it. Terminate the script, then immediately run `sudo ./bootrom-step.sh` again. The exploit it set up so that after about 40 seconds of inactivity it would reboot your device and drop you back into the bootrom mode, which the script is waiting for. If you cannot restart the process, you might have to open up the tablet and replug the battery to completely power off the device.
10. You should see a success message: "Reboot to unlocked fastboot". Only proceed if you see the message.
11. Once the device boots to fastboot (check with "fastboot devices"; you should also see amazon logo on the screen.), you can run "sudo ./fastboot-step.sh".
12. At this point the device should boot into recovery, however the screen will be off. Just press the power button twice and the screen should turn on.
13. Success! You now have a custom recovery installed that can be accessed by holding down power and volume down (the leftmost) buttons. At this point if you came here from a custom ROM thread you should probably follow the ROM installation instructions. Alternatively, the next steps will detail installing a stock firmware and rooting it with Magisk.
----------------------------------------------------------------------------------------------------
14. We'll now upload required files to the recovery. On your PC, do:
adb push update-kindle-NS6312_user_1827_0002517050244.bin /sdcard/fw.zip
adb push Magisk-v19.3.zip /sdcard
adb push finalize.zip /sdcard
15. In the recovery, go to "Install", navigate to "/sdcard" and flash fw.zip
16. Go to "Wipe" and do the default wipe, then reboot
17. At the Fire setup screen, select your language. On the next screen, Wifi setup, select any password-protected network, then instead of entering the password press "cancel". Now, back at the wifi setup screen, press "Skip setup" and "Skip" in the dialog pop-up again
18. Wait for the update to finish (wait until the updating fire notification disappears)
19. Hold down the power button, press Restart and hold volume down to boot into recovery.
20. In the recovery, go to "Install", navigate to "/sdcard" and flash Magisk-v19.3.zip
21. Press back, select finalize.zip and flash it
22. Once finalize.zip is flashed, press "Reboot System"
VERY IMPORTANT STUFF:
Only ever flash boot images from TWRP. Since nothing but TWRP is aware of the exploit, if you try to flash a boot image from Android, it won't have the exploit integrated into it! This includes Magisk as well, so do NOT install or uninstall it from Magisk Manager (However, installing modules should be fine; although it depends on the specific module).
Due to how the exploit works, it takes over the first 0x400 bytes of boot.img/recovery.img. When flashing zips from the recovery, it will transparently remove and then reinstall the exploit when needed. So long as you flash zips from the recovery, you should treat the boot image normally. However, this means that you cannot use any other apps (e.g. FlashFire) to flash the boot or recovery partitions.
To uninstall the hack and revert back to stock:
- Download an update package to your PC (the update-kindle-NS6312_user_1827_0002517050244.bin file)
- Flash revert-stock-mustang.zip from TWRP
- Perform the default wipe
- Reboot to recovery; you should see amazon recovery now
- Select "apply update from ADB" in the recovery menu
- Run "adb sideload update-kindle-NS6312_user_1827_0002517050244.bin" on your PC
Other misc information / troubleshooting:
- If you need to disconnect the battery, use a pair of tweezers to grab the wires and gently pull towards yourself. You can do bootrom-step.sh either with or without the battery connected, however fastboot-step.sh should be done with the battery connected.
- If your device is bricked (e.g. from a downgrade), just follow the steps as-is.
- If you're getting an error like "Serial protocol mismatch", or any other error in bootrom-step, try disabling or temporarily uninstalling ModemManager from your Linux
- To remount /system as rw use "mount -o rw,remount /system". ("mount -o remount,rw /system" will not work)
Thanks to: aftv2-tools contributors https://gitlab.com/zeroepoch/aftv2-tools: for an implementation of mtk download protocol, @diplomatic for mtk-su, @Michajin for testing the instructions.
Thanks for your work!
On a side note, I also had adaptive storage on during the process. I was having crashing issues after install. I re-installed the firmware-wiped and booted. I followed the steps to boot without setup. Then booted back into TWRP, flashed magisk, but did not flash finalize. I like access to some of the amazon apps. Once I rebooted (I stayed off wi-fi) I sideloaded a package disabler and disabled the OTA. I registered then disabled the amazon bloat I didn't want. I have installed my sd card as portable this time, just to be safe.
also, TWRP does not have backup and restore options, is this normal on this currently?
incredible, i will try that
Thanks. We will look if it's possible to compile LOS 14.1 since it has the same processor as the HD8 2018.
hello @xyz
Do you think i can try that throught a linux virtual machine on virtualbox ?
guizzzmo said:
hello @xyz
Do you think i can try that throught a linux virtual machine on virtualbox ?
Click to expand...
Click to collapse
I unlocked my 7th gen with virtualbox so yes.
Hi guys, Is there a chance there will be a Nexus ROM released for the Mustang version of the Fire? It's been my preferred ROM on my older Ford model so I'd like to keep using it if possible.
tangledweb said:
Hi guys, Is there a chance there will be a Nexus ROM released for the Mustang version of the Fire? It's been my preferred ROM on my older Ford model so I'd like to keep using it if possible.
Click to expand...
Click to collapse
Mustang uses a different kernel than Ford/Austin; custom ROMs will need to be spun up from different sources. Developer time is scarce; may or may not happen.
Finally bricked with software method.
I try to find a picture for where i can make my wire for hardware method.
SOLVED:
My battery was empty so i have just disconnect battery and plug usb with paperclip and i have got bootrom.
Great !!
much thanks for this, after some fiddling it works perfectly!!
i had some issues getting past the bootrom script part on both my galliumos & debian machines (serial error message, despite apt remove modemmanager) - until i tried an xubuntu liveusb, at which point everything went smoothly and as directed via the software method.
looking very forward to an aosp rom to replace stock and being able to make a twrp backup (i broke my install with magisk, but it was a simple recovery just reflashing fw.bin again). cheers!
Is it just me or is the hardware point picture coming up as a dead link? Can someone attach the correct point in another image?
rumblpak said:
Is it just me or is the hardware point picture coming up as a dead link? Can someone attach the correct point in another image?
Click to expand...
Click to collapse
The link (to the hardware shorting point) in the OP is indeed broken.
Try the following :
https://forum.xda-developers.com/showpost.php?p=79683131&postcount=22
Edit : The link in the OP is fixed now. (7/3/2019)
at the point where you issue 'reboot' for the software method. upon issuing that command, the device powers off, and is non responsive. cant get it to turn back on at all. Very strange. Any ideas?
wlewin said:
at the point where you issue 'reboot' for the software method. upon issuing that command, the device powers off, and is non responsive. cant get it to turn back on at all. Very strange. Any ideas?
Click to expand...
Click to collapse
Did the script run correctly? Did you get to the point where is says
* * * If you have a short attached, remove it now * * *
* * * Press Enter to continue * * *
Did you press enter and see the script run? Did it end;
[8 / 8]
[2019-06-30 02:53:11.695348] Reboot to unlocked fastboot
The reboot command puts your device into bootrom to inject the exploit. Upon completion TWRP is installed, i think you have to double click the power button. If all else fails, you might have to pry open and disconnect the battery. Were you in bootrom, because preloader can do this; run lsusb and you should see a phone connection or "dmesg" and you should see this device ;
[1141765.113884] usb 3-1.4.3.1: USB disconnect, device number 59
[1141783.057101] usb 3-1.4.3.1: new full-speed USB device number 60 using xhci_hcd
[1141783.226498] usb 3-1.4.3.1: New USB device found, idVendor=0e8d, idProduct=0003, bcdDevice= 1.00
[1141783.226502] usb 3-1.4.3.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[1141783.506877] cdc_acm 3-1.4.3.1:1.0: ttyACM0: USB ACM device
Michajin said:
Did the script run correctly? Did you get to the point where is says
* * * If you have a short attached, remove it now * * *
* * * Press Enter to continue * * *
Did you press enter and see the script run? Did it end;
[8 / 8]
[2019-06-30 02:53:11.695348] Reboot to unlocked fastboot
The reboot command puts your device into bootrom to inject the exploit. Upon completion TWRP is installed, i think you have to double click the power button. If all else fails, you might have to pry open and disconnect the battery. Were you in bootrom, because preloader can do this; run lsusb and you should see a phone connection or "dmesg" and you should see this device ;
[1141765.113884] usb 3-1.4.3.1: USB disconnect, device number 59
[1141783.057101] usb 3-1.4.3.1: new full-speed USB device number 60 using xhci_hcd
[1141783.226498] usb 3-1.4.3.1: New USB device found, idVendor=0e8d, idProduct=0003, bcdDevice= 1.00
[1141783.226502] usb 3-1.4.3.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[1141783.506877] cdc_acm 3-1.4.3.1:1.0: ttyACM0: USB ACM device
Click to expand...
Click to collapse
None of that seems clear in the steps.
the amonet script is in 'waiting for bootrom'. I then issued the reboot command, and the device blacked out, and nothing happened in terminal.
I have since disconnected the battery, and it still doesn't boot at all.
wlewin said:
None of that seems clear in the steps.
the amonet script is in 'waiting for bootrom'. I then issued the reboot command, and the device blacked out, and nothing happened in terminal.
I have since disconnected the battery, and it still doesn't boot at all.
Click to expand...
Click to collapse
My guess is you are bricked stuck in the preloader or something is wrong with your linux, and might have to do the shorting method now. Run lsusb and see if it sees your device, i believe it shows up as a phone. If you see preloader, you will have to short it. otherwise you might have to fix your linux. Make sure modemmanager is uninstalled ... I had issues trying to use ubuntu and ended up using Rasparian.
Michajin said:
My guess is you are bricked stuck in the preloader or something is wrong with your linux, and might have to do the shorting method now. Run lsusb and see if it sees your device, i believe it shows up as a phone. If you see preloader, you will have to short it. otherwise you might have to fix your linux. Make sure modemmanager is uninstalled ... I had issues trying to use ubuntu and ended up using Rasparian.
Click to expand...
Click to collapse
ah ha! Got it sorted. So, the screen going blank was very odd. turns out after sending reboot, that state is two things
1. blank screen with not indication of being powered on
2. persistent through cutting the power (disconnecting battery)
So, seemingly, the devices is totally non-functional. The issue was, in the linux VM I am using, I had to go manually select the USB devices because the identifier changed from the prior Amazon device to a mediatek device. So it was in the right state, I linux just didn't auto connect to the new USB device.
All good the in the hood. continued and worked just fine. Just PSA to others, that boot state seems like the device is just off!
2017 7" tablet too?
Will this work on my Kindle fire 7" 2017 Ed if I update to the latest software version?
Or do I have to buy a new tab to root and install custom roms on?
OP, i think you are linking to the magisk uninstaller in your original post btw. not the installer zip
PowerUser64 said:
Will this work on my Kindle fire 7" 2017 Ed if I update to the latest software version?
Or do I have to buy a new tab to root and install custom roms on?
Click to expand...
Click to collapse
WTF no. 7th gen can be unlocked and rooted. (Also there are ROMS for it: LOS 12.1, AOSP FIRE NEXUS, etc).
https://forum.xda-developers.com/amazon-fire/development/unlock-fire-t3899860
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Raven Boot v2.0 now includes persistent root. A huge thank you to @Functioner for getting it working! This package includes unrestricted U-Boot, fastboot & Amlogic burn mode commands, as well as TWRP and Magisk support. The Raven boot tool includes options to root your Cube, gain temporary root access without modifying your device, and a number of options for recovery and backup.
NOTE: FireOS < 7.2.7.3 required
A newer method is available that works up to PS7292, that doesn't use DFU or a DFU device, but has no DFU recovery options
NOTE: This process does not require you to open your Fire TV 2nd gen Cube
Changelog:
v2.2 April 7th, 2023
Minor update to Magisk 25.208
Hopping back on official signed Magisk app line
v2.0 and v2.1 use an unofficial Magisk build that will result in a signature mismatch when updating.
If you are using Raven root v2.0/2.1, delete the file /data/adb/magisk.db on your Cube,
before updating to Raven root v2.2.
Added USB booting for flash drives that use aml_autoscripts, for future development.
v2.1 February 18th, 2023
Updated TWRP v3.6.1-9-0 ---> v3.7.0-9.0
Fixed problem with TWRP not always displaying all the partitions under 'Mount/Backup'
Always mounts 'Internal Storage' to /sdcard now
Fixed bash menu to always use the included fastboot binary
Cube's physical buttons can be used on bootup
Volume Up ---> Fastboot
Volume Down ---> TWRP recovery
Action button ---> Amlogic Update
**Hold down button for ~5sec after power-on, and before the blue LEDs / 1st Amazon logov2.0 February 9th, 2023
Root is now persistent, does not require computer after every reboot
One click option to install root access, TWRP, Magisk & OTA blocker module
Magisk updates
Zygisk is working (July 1st, 2022)
Magisk can be installed from TWRP or direct installed from within Magisk Manager
Created module to block Amazon OTA updates via etc/hosts and hiding the OTA apk
updated quick access images to Magisk v25.2
TWRP updates
Bootloader flashing is blocked, so that full OTA firmware bins can be easily flashed (tested up to PS7624/3337)
Removed firmware downgrade checks & warnings
Added NTFS support for flash drives within TWRP
Added options to backup entire reserved partition, and mmcblk0boot0 & mmcblk0boot1 boot partitions in Amlogic update
Added emergency boot to Fastboot/Update modes
v1.0 May 15th, 2022
Temporary unrestricted fastboot, u-boot & update commands
Boot with root access or Magisk support
Boot to TWRP for backup & recovery
Backup Cube using Amlogic Update
What's needed:
linux installation or live-system (Ubuntu 20.04.x recommended)
micro-USB cable
device to put Cube into device firmware upgrade (DFU) mode [read below]
libusb is needed for your linux installation to detect the Cube over USB.
sudo apt-get install libusb-1.0-0
To automatically set the proper udev rules for Amlogic install Khadas utils:
sudo apt-get install libusb-dev git
sudo apt-get install git
git clone https://github.com/khadas/utils
cd utils
./INSTALL
***NOTE: If you previously installed Magisk on your Cube from raven_boot v1.0, first run adb shell rm /data/adb/magisk.db to prevent any conflicts with the new Magisk version.
Instructions
Download the latest raven_boot.zip and unzip it. Open a terminal window from the unzipped raven_boot directory
Power off the Cube and connect your DFU device to the Cube's HDMI port. Connect the USB cable (microUSB to USB-type A) to computer & Cube
Power on the Cube, type lsusb in the terminal to confirm ID 1b8e:c003 Amlogic, Inc. is present, indicating the Cube is in DFU mode
Unplug the DFU device from the HDMI port, reconnect the Cube to TV with HDMI cord. Keep the computer connected.
In the terminal type bash menu, and choose option 1) to automatically root the Cube.
To preserve the Cube's persistent root, be sure to confirm that both TWRP & Magisk are installed.
Quick Access
For options 2) and 3) to gain temporary root, download the images zip file that corresponds to your current FireOS version, and unzip the contents into raven_boot/images directory.For Cubes running FireOS 7242/2896 or later get ---> images_7242-2906_v2.0.zipFor FireOS versions 7201/942 to 7242/2216 get ---> images_7229-1853_v2.0.zip
Magisk v25.206 is included with Raven boot, it's recommened that you use this version or newer. For instructions on how to update your firmware and keep root access, read here
About the exploit
This exploit is based on a vulnerability in the Amlogic bootrom that allows for us to run unsigned code in the next boot stage (Bl2). To pause the automatic boot up process, before the Cube's saved Bl2 is loaded, we rely on Amlogic's device firmware upgrade mode (DFU). In DFU, only the boot code from the Amlogic s922x SOC (Bl1) has been loaded into memory. We then use the vulnerability to load our modified Bl2, breaking the 'chain of trust', and disabling secure boot so that we can make modifications to the bootloader downstream. The last stage of the bootloader is U-boot (Bl33) which hands off the startup process to the kernel (boot.img). U-boot is modified to unlock any restrictions on u-boot and fastboot commands, giving us full access to system features. We can then use fastboot boot to load our modified boot images (TWRP, magisk-patched boot.img), into memory without modifying the Cube's eMMC.
Visit GitHub for a more in depth write-up and resources used in this project
Contributors
@Functioner
@Zenofex
@npjohnson
@zeewox
@Pro-me3us
Additional thanks to
@tchebb - a bottomless encyclopedia of Amlogic knowledge, answering countless questions & troubleshooting
@roligov - providing photos, additional FireOS updates, and testing
@osm0sis, @canyie, @vvb2060 & @yujincheng08 - the Magisk team for being awesome, troubleshooting and making a number of code changes to get all features working on the Cube
@k4y0z - helping troubleshoot some TWRP and Magisk issues
Entering the Cube's DFU mode
To boot into device firmware upgrade (DFU) mode we need to pass a '[email protected]' command, to the Cube's Amlogic s922x SOC, through the I2C bus accessible via the HDMI port. This was first described in the FireFU exploit for the 1st gen Cube. Since then there are a few more options for devices to accomplish this:
DIY modified dummy HDMI dongle. Fully self-contained, and powered by the HDMI port. Simple to use, just plug-in and unplug, can be made for $5 or less and is what I recommend.
https://github.com/superna9999/linux/wiki/Amlogic-HDMI-Boot-Dongle
I2C emulator for ATmega boards (Arduino Duemilanove, ATmega48/88/168/328). Requires less skill, potentially little to no soldering. A Tiny88 ($2-3) wired to an HDMI breakout board ($2-3) can be programmed over USB with one command.
https://github.com/tchebb/amlogic-hdmiboot-avr
Arduino sketch to boot into DFU, compatible with ARM-based Arduino boards (Due, Teensy, Genuino). Costs more but a good alternative if you already have an Arduino board.
https://www.exploitee.rs/index.php/FireFU_Exploit#Preparing_HDMI_dongle
Flashing OTA Firmware with TWRP
To upgrade the firmware past PS7273+ and keep the Cube unlocked and rooted, we need to avoid flashing any bootloader version newer than PS7242/3516. The new build of TWRP included with Raven boot v2.0+ and Raven root shrinker automatically blocks any bootloader flashing. Be sure that you are using Raven boot v2.0 or newer! Firmware bin flashing is working and tested up to PS7633/3445.
The shrinker script only works up to PS7624/3337, upgrading past this version will still maintain root, but will lose the shrinker backdoor backup.
Update Procedure:
1) Download the full firmware bin (XDA or Github), change extention .bin to .zip
2) In ADB type reboot recovery to enter TWRP. You can also open Magisk Manager and choose the reboot to recovery option in the top right corner of the main screen.
3) Copy the firmware file to your Cube via USB connected computer, flash it, and re-flash Magisk
Code:
adb push <firmware-filename.zip> /sdcard/Download/
adb shell
twrp install /sdcard/Download/<firmware-filename.zip>
twrp install /sdcard/Download/magisk.apk
If you used the shrinker method, then the magisk apk is in /data/local/tmp/ instead
Code:
twrp install /data/local/tmp/magisk.apk
If you prefer to use a USB mouse and regular TWRP interface, rather than computer, download the firmware bin directly to the Cube in FireOS. Firmware updates don't require wiping data/dalvik. If downgrading firmware, wiping data/dalvik is advisable.
NOTE: It's IMPORTANT to not forget to flash magisk.apk after each firmware upgrade. Magisk & TWRP work together to preserve root access. Magisk prevents TWRP from being deleted, and TWRP helps to prevent accidental Amazon OTA updates. Without Magisk, OTA updates will no longer be blocked by the OTA blocker Magisk module.
Protected Packages
Amazon added package protection in +PS7273. To remove this, boot into FireOS with Magisk or root support, edit /data/system/PackageManagerDenyList, delete the list of applications, and save.
To prevent the protected applications list from being regenerated on reboot, disable:
Code:
adb shell pm disable-user com.fireos.arcus.proxy
All applications can now be disabled/enabled without root, including custom launchers.
reserved
Thanks for this! So far I've only confirmed old enough firmware (PS7229/1856) and installed a uart header. Seems I will have to wait a while to get a working hdmi plug for dfu access.
While looking at the uart log, I noticed that u-boot is interruptible prior to boot, which is a little unusual. But every u-boot command is disabled, even "help"!
I noticed some text about a one time override code of some sort. Did you find any additional information about this code while working on the bootloader?
Would it not be possible to just flash a patched bootloader, much like is described at the site you've referenced? Is the stock bootloader encrypted? If so, were the relevant keys extracted?
What about ≥ 7.2.7.3 kills this exploit? Is dfu access lost? If not, what else prevents it from working? I wouldn't think that dfu could be lost, since it is in rom, unless an efuse can disable it?
goapy said:
While looking at the uart log, I noticed that u-boot is interruptible prior to boot, which is a little unusual. But every u-boot command is disabled, even "help"!
I noticed some text about a one time override code of some sort. Did you find any additional information about this code while working on the bootloader?
Click to expand...
Click to collapse
On the stock bootloader Amazon has blacklisted all uboot commands. The bootloader code is available through Amazon's open source repository. The uboot console restrictions are in:
platform/bootable/bootloader/uboot-amlogic/s922x/bl33/common/amzn_lockdown.c
The unlock codes are generated by Amazon's servers in combination with the devices' serial number. This system is the same as other fire devices. There is a list of all the uboot commands in the documents folder of raven_boot.zip to give you an idea of what's available.
To work with the U-boot console, you can also send uboot console commands via Amlogic burn-mode for convenience.
Code:
./update bulkcmd "uboot command"
Unfortunately, i don't think there is a way to route the uboot console output over HDMI or USB, so TX is still necessary for visualization. Your soldering work and connector look a lot nicer than what I was working with, I'm jealous
goapy said:
Would it not be possible to just flash a patched bootloader? Is the stock bootloader encrypted? If so, were the relevant keys extracted?
Click to expand...
Click to collapse
The bootloader is signed, and verified by the bootrom. This is part of the 'chain of trust' that ensures the bootloader is not altered / tampered with. The reason the patched bootloader in the OP can be loaded is because we are using a tethered computer to run a bootrom exploit program (amlogic-usbdl) to inject our own next stage code (bl2.bin) that bypasses the bootrom verification process. The modified Bl2 code allows for the rest of the bootloader to load. Without a computer to run the exploit, our Bl2 code would fail verification, and the Cube would hang.
The bootloader is encrypted with several keys, and the keys change with major releases. I don't know what XDA's policy is on posting keys, so I don't want to chance a violation. A more detailed description of the whole process will be added to github relatively soon.
goapy said:
What about ≥ 7.2.7.3 kills this exploit? Is dfu access lost? If not, what else prevents it from working? I wouldn't think that dfu could be lost, since it is in rom, unless an efuse can disable it?
Click to expand...
Click to collapse
@roligov said he was not able to enter into DFU with USB after 7.2.7.3. There was an option added to the efuse file last year to disable DFU from USB, my guess is Amazon chose to burn the fuse(s) in 7.2.7.3.
EDIT: If you plan to be do a lot of probing, I'd recommend going with Superna9999's HDMI dongle design, it's a lot more convenient than the Arduino boards.
goapy said:
What about ≥ 7.2.7.3 kills this exploit? Is dfu access lost? If not, what else prevents it from working? I wouldn't think that dfu could be lost, since it is in rom, unless an efuse can disable it?
Click to expand...
Click to collapse
Pro-me3us said:
@roligov said he was not able to enter into DFU with USB after 7.2.7.3. There was an option added to the efuse file last year to disable DFU from USB, my guess is Amazon chose to burn the fuse(s) in 7.2.7.3.
Click to expand...
Click to collapse
Exactly that. I had a unit that worked fine, tested DFU mode before applying update Fire OS 7.2.7.3 (PS7273/2625). After updating to that firmware version, DFU mode no longer worked. Exact same setup worked 5 minutes before and still works on other cubes. If no one on here confirms it no longer works on the latest firmware, I may sacrifice another cube and update to the latest. I thought it wasn't possible either since it's a bootrom exploit, but guessing an efuse has been burnt.
It may be possible to probe the board and achieve DFU mode by someone who knows what they doing like the method used for the Fire Sticks (I tried with 1 cube which ended up in a bootloop, luckily Amazon replaced it).
Pro-me3us said:
The bootloader is signed, and verified by the bootrom. This is part of the 'chain of trust' that ensures the bootloader is not altered / tampered with.
The bootloader is encrypted with several keys, and the keys change with major releases.
Click to expand...
Click to collapse
Whatever bootloader keys are used for the chain of trust in order to ensure an internally consistent hand-off from stage to stage are distinct from the most external bootrom key that is used to encrypt the entire bootloader partition image from start to finish, right? That most "external layer" bootrom key, that is used to encrypt the entire bootloader partition image, must remain the same for the life of all instances of the hardware, at least if all similar devices are to be able to run firmware updates, right?
By the "most external layer" of encryption, I mean this layer;
If a device that is configured for secure boot, as distinguished from a device that is not configured for secure boot, like the khadas VIM3L (but still has a bootloader partition that is at least encrypted with the most external layer key), could it not run a different bootloader (that was internally consistent and unmodified), so long as that bootloader was encrypted with a matching most external layer key? Does secure boot prevent this?
For example, if an entire bootloader was taken intact from a generic 922 device, and that entire bootloader was not internally modified at all (but happened to have a functioning u-boot bl33 layer), and that entire bootloader (after itself being decrypted with its most external layer bootrom key, if necessary) was encrypted with the most external layer key matching the v2 cube, would that bootloader not boot all the way to bl33 and beyond on the v2 cube?
Perhaps an internally consistent alternative bootloader, even if if properly encrypted with the most external layer bootroom key, would still break the chain of trust because the portion of the bootloader that is in rom (bl1) is not just generic bootloader code common to many devices, but is customized specifically for that particular secure boot device (or references a root of trust elsewhere in the rom that is individualized), so the subsequent bootloader stages would fail trust because of that individualization that is in, or referenced by, bl1, even if they were entirely unmodified?
Perhaps this bootloader might boot but avb or vbmeta verification might fail in some other way, or whatever drm magic is in the bootloader might be absent, but would it not at least boot, or does secure boot prevent any internally consistent alternative bootloader from booting, even if it is encrypted with the correct most external layer key, matching the bootrom key?
I apologize if I'm missing something obvious because of my impoverished understanding of this process.
roligov said:
Exactly that. I had a unit that worked fine, tested DFU mode before applying update Fire OS 7.2.7.3 (PS7273/2625). After updating to that firmware version, DFU mode no longer worked. Exact same setup worked 5 minutes before and still works on other cubes. If no one on here confirms it no longer works on the latest firmware, I may sacrifice another cube and update to the latest. I thought it wasn't possible either since it's a bootrom exploit, but guessing an efuse has been burnt.
Click to expand...
Click to collapse
Do you have any guesses about how the efuse is burnt by the updated system? Might the new bootloader itself do it, or the running system, or is there anything obvious in updater-script (if amazon ota's use an updater-script)?
It seems that all of the quickly obtainable edid-spoofing hdmi plugs come with an eeprom in the sot23 package, lacking the a0, a1, and a2 pins needed for the addressing change. Does anyone know of a hdmi plug that uses an 8-lead eeprom that can be ordered for quick delivery?
Otherwise I'll modify the sot23 version that I have coming tomorrow, replacing the sot23 at24cs02 with an 8-lead version that I can pull from some waste board.
goapy said:
Do you have any guesses about how the efuse is burnt by the updated system? Might the new bootloader itself do it, or the running system, or is there anything obvious in updater-script (if amazon ota's use an updater-script)?
Click to expand...
Click to collapse
At power on Amlogic devices will print a string of SOC information that starts with G12B:BL....
in that string is F2FB39B0:432060. The 2 values report the security efuse status for the device. 32bit values:
CFG9: 0x00432060
CFG10: 0xF2FB39B0
Following 7273/2625 there is a 1 bit change in CFG10
CFG10: 0xF2FB39B0 (pre 7273) = 1111 0010 1111 1011 0011 1001 1011 0000
CFG10: 0xF2F339B0 (post 7273) = 1111 0010 1111 0011 0011 1001 1011 0000
Bits are read from right to left starting with bit 0, so Flag 19 flips from 1 to 0. The security efuse table shows that an efuse was buned to disable 'IS_FEAT_USB_BOOT_ENABLE', barring DFU entry via USB.
There is little documentation on how to burn efuses, more importantly I don't know of any public information on the efuse addresses that correspond to which features. Burning efuses would have to be done through uboot and the Bl31api which is how non-secure world talks to secure world. Amazon may handle it through cmd_efuse.c, since there was an addition to that code made to disable USB boot in 2021. The following can be found in the 2nd gen Cube package from Amazon's open source page
platform/bootable/bootloader/uboot-amlogic/s922x/bl33/common/cmd_efuse.c
goapy said:
Whatever bootloader keys are used for the chain of trust in order to ensure an internally consistent hand-off from BL stage to BL stage are distinct from the most external bootrom key that is used to encrypt the entire bootloader partition image from start to finish, right? That most "external layer" bootrom key, that is used to encrypt the entire bootloader partition image, must remain the same for the life of all instances of the hardware, at least if all similar devices are to be able to run firmware updates, right?
Click to expand...
Click to collapse
There are several layers of security, including encryption and signed code. The s922x contains an AES key which is static, and it can be used to decrypt the bootloader. The Cube has boot decrypt enabled, meaning that it is expecting Bl2 to be encrypted, and it will decrypt anything passed to it with the internal AES key. Amazon takes things a step further and encrypts the later bootloader stages with 3 more AES keys. So to fully decrypt the bootloader there are 4 total keys, one of which is static.
But in the case of the Cube, decryption is not an issue since we can dig to get all the keys. The keys just allow the SOC to unscramble the image. There is also signing which involves image hashes. By modifying the image, the hash changes, failing the signature check. The function of the amlogic-usbdl exploit is to bypass the code verification, not encryption.
The Bl2 signing tool is public but Bl2 is not open source. I don't know how functional the Bl2.bin is that is included in the firetv open source repository. There's likely also other security checks I'm overlooking.
goapy said:
For example, if an entire bootloader was taken intact from a generic 922 device, and that entire bootloader was not internally modified at all (but happened to have a functioning u-boot bl33 layer), and that entire bootloader (after itself being decrypted with its most external layer bootrom key, if necessary) was encrypted with the most external layer key matching the v2 cube, would that bootloader not boot all the way to bl33 and beyond on the v2 cube?
Click to expand...
Click to collapse
If it was from a generic device without any security features implemented in the bootloader maybe? The Cube has a root key burned to it that I assume is specific to the 2nd gen Cube. I believe this is used in verifying bl2.
There would be hardware/board differences that would lead to a host of issues as well. Uboot would be missing the FireOS layer, so I would be surprised if it could hand things off properly. Bl2 would still have to be encrypted using the AES key, since the Cube has boot encrypt enabled, which is doable.
That could be tested with Amlogic's update tool in DFU.
Code:
./update write bl2.bin 0xfffa0000 //loads bl2 into memory at the run address
./update run 0xfffa0000 //executes bl2 from memroy
./update bl2_boot bootloader.img //loads and runs the rest of the bootloader into and from memory
The closest thing to Khasdas' VIM3L for the s922x is the Odroid N2/+, in terms of a developer's board with little to no security features implemented. The unsigned Cube bootloader will load fairly far on the N2+, but I don't remember if it got as far as the kernel. I never tried the reverse, loading an N2+ bootloader on the Cube.
goapy said:
Otherwise I'll modify the sot23 version that I have coming tomorrow, replacing the sot23 at24cs02 with an 8-lead version that I can pull from some waste board.
Click to expand...
Click to collapse
I did ^this^ because the 8-lead version that I ordered still hasn't arrived yet. See before/after images below. It was a success and I was able to get the exploit running.
While swapping out the eeprom, I noticed that the ddc (display data channel) pair of lines was terminated in the plug, even though this edid emulator device supports passthrough. The ddc pair carries at least two kinds of data, edid and hdcp.
Presumably ddc is terminated because otherwise there would be a serial wire device conflict on the i2c bus at address 0x50, since both the edid emulator device and the sink would each have a eeprom (or prom) at that address.
But since for dfu usage the address is changed to 0x52, I figured the ddc lines could be reconnected and the 0x52 serial device could just ride on a passthrough i2c bus. So, I wired the sda and scl lines as passthrough lines.
I hoped that this would mean that I could repeatedly use the exploit over time without swapping hdmi connections for every reboot. And it does do that. But it also takes a power cycle in order boot to dfu mode from an actively running OS. Booting any of the other images, such as fastboot, twrp, etc., do not require a power cycle and reboot straight to dfu mode with the passthrough device installed.
So, it is still more convenient to just cycle power rather than swap hdmi plugs.
As far as testing the exploit itself, I've only spent an hour so far. The included magisk patched boot image does work, although when I tried to boot a magisk patched boot image that I patched myself (using the original image on the device as a source), it did not boot. All of the provided boot images do work, and are all very useful.
goapy said:
I hoped that this would mean that I could repeatedly use the exploit over time without swapping hdmi connections for every reboot. And it does do that. But it also takes a power cycle in order boot to dfu mode from an actively running OS. Booting any of the other images, such as fastboot, twrp, etc., do not require a power cycle and reboot straight to dfu mode with the passthrough device installed.
Click to expand...
Click to collapse
That's a very nice improvement over Superna9999's design, you should share this with him I did start to strip the plating on my HDMI cable from all the plugging/unplugging during testing. With this design, does the Cube end up powering two ICs, the one on the dongle and the one in the TV HDMI port? Are there any issues having the Cube power both?
Even with the original design, I think a power cycle is required to get into DFU, rather that just a reboot. I remember adb rebooting would cause the Cube to keep resetting until a power cycle or the dongle was removed. It may be that there is a bootrom level 'reboot reason' stored in volatile memory, that's not cleared until power cycling? If you send a reboot command from u-boot / burn mode are you put in DFU, or do you still need to power cycle? I briefly looked for a command to reboot into DFU (without I2C), but couldn't find anything.
goapy said:
The included magisk patched boot image does work, although when I tried to boot a magisk patched boot image that I patched myself (using the original image on the device as a source), it did not boot.
Click to expand...
Click to collapse
You'll need to use a canary build of Magisk to make your own patched boot.img. There is an Amlogic quirk that probably affects many slot A only devices. Amlogic uses the suffix 'normal' rather than '_a', which is not recognized by Magisk. A patch was added to ignore the suffix in canary build ~24.310.
When patching the boot.img with Magisk, choose recovery mode and leave vbmeta unchecked. Using the regular boot mode (not recovery mode), results in a mount/unmount loop during bootup. The cause of this will have to be worked out long-term for a persistent root. Right now SU works for Magisk but Zygisk doesn't. I'm not sure if that is a limitation of loading Magisk with fastboot boot, or because recovery mode is being used to create the patch.
You will also want to enable UART output from the kernel. This will be applied to your Cube automatically by choosing bash menu 1) boot to FireOS with ADB root / permissive. You can do it manually by booting to fastboot
Code:
fastboot oem flags fos: 0x4
The flags are stored in IDME and can also be changed directly there
Code:
fastboot oem IDME fos_flags 0x4
The IDME values will persist without the exploit, but values like
ADB root and DM-verity off will be ignored/rejected by the native bootloader when uboot determines the Cube is not an engineering device (defined as ARB=0). But the console enable value will be accepted, letting you see native FireOS uart output.
EDIT: I added the 31 IDME properties that can be edited
Pro-me3us said:
With this design, does the Cube end up powering two ICs, the one on the dongle and the one in the TV HDMI port? Are there any issues having the Cube power both?
Click to expand...
Click to collapse
I don't think current draw is a problem. A 24c02 eeprom draws 1 mA max when reading, and 5 μA max when in standby. Even if both eeproms on the bus were read at the same, that would not be a lot of current. There is only one read operation of each serial device per power cycle.
Consider another edid emulator with passthrough, the gofanco prophecy. The gofanco emulator has not only two onboard 24c02 eeproms, but also a 3AQ20 MCU and a hc4052 mux/demux IC, all powered by the hdmi port.
Pro-me3us said:
You'll need to use a canary build of Magisk to make your own patched boot.img. There is an Amlogic quirk that probably affects many slot A only devices. Amlogic uses the suffix 'normal' rather than '_a', which is not recognized by Magisk. A patch was added to ignore the suffix in canary build ~24.310.
Click to expand...
Click to collapse
Thanks. I didn't realize that 24.310 was used on the supplied image or that a recovery style patch was required. Now it all works.
Pro-me3us said:
The flags are stored in IDME and can also be changed directly there
Code:
fastboot oem IDME fos_flags 0x4
The IDME values will persist without the exploit, but values like
ADB root and DM-verity off will be ignored/rejected by the native bootloader when uboot determines the Cube is not an engineering device (defined as ARB=0). But the console enable value will be accepted, letting you see native FireOS uart output.
EDIT: I added the 31 IDME properties that can be edited
Click to expand...
Click to collapse
Thanks for the list of IDME properties. I'm getting up to speed now. It's quite different than the typical amlogic setup. No env or vbmeta partitions. There doesn't seem to be any vulnerabilities like the uboot/rsv exploit used for the gen 1 cube.
goapy said:
I don't think current draw is a problem. A 24c02 eeprom draws 1 mA max when reading, and 5 μA max when in standby. Even if both eeproms on the bus were read at the same, that would not be a lot of current. There is only one read operation of each serial device per power cycle.
Click to expand...
Click to collapse
Oh ok that's a minuscule amount. I think HDMI ports are rated for 50-300mA output. Are you able to passthrough 4k 30FPS, 60FPS (Youtube for example) with the one of those connected? Or DV/HDR? I'm curious if a dongle like that could be left in for regular use of the device.
goapy said:
Thanks for the list of IDME properties. I'm getting up to speed now. It's quite different than the typical amlogic setup. No env or vbmeta partitions. There doesn't seem to be any vulnerabilities like the uboot/rsv exploit used for the gen 1 cube.
Click to expand...
Click to collapse
Yeah an ENV partition would have made things a lot easier. Most Fire devices are MediaTek based, and the Cube is sort of alone in the use of U-Boot. There's also the 1st gen Cube and Pendant, but they are getting hard to come by. Frederic's exploit will probably work for any G12A/G12B/SM1 SOC from Amlogic, including the 1st gen Cube and Pendant, but I don't have one to test and make the necessary modifications. Amazon no longer sells these two models, and I'm assuming they also lost DFU access with the February/March update.
I think the uboot/rsv exploit got patched pretty soon after the FireFU release. I also checked aml_emmc_partition.c for the 2nd gen Cube and it was patched by the release version 7.2.0.4.
There is the u-boot vulnerability database. I don't know if any of these are present or useful on the Cube, testing them is above my skill level. I was only able to apply Frederic's exploit to the Cube because he documented everything very well.
I've posted a draft of the raven exploit on github with a little more information. I still need to edit it a bit, but the outline is there.
Pro-me3us said:
Are you able to passthrough 4k 30FPS, 60FPS (Youtube for example) with the one of those connected? Or DV/HDR? I'm curious if a dongle like that could be left in for regular use of the device.
Click to expand...
Click to collapse
It all seems to work so far. All 19 lines are wired as passthrough. The passthrough hdmi ddc link doesn't seem to be bothered by having a non-standard i2c address eeprom on the bus.
Pro-me3us said:
I've posted a draft of the raven exploit on github with a little more information. I still need to edit it a bit, but the outline is there.
Click to expand...
Click to collapse
That's a very illuminating writeup. It instantly filled in a lot of holes in my understanding.
That also seems to have been quite a lot of work, thanks again for sharing it all.
Isn't that most projects, more work than initially anticipated
I did all my testing with the ribbon cable to the physical buttons disconnected. Can you check something for me since you have UART access with the buttons active?
When in FireOS, holding down the Cube action button (button with dot) for 15sec kills all processes and appears shut the device down. But the device is not powered off, the mute button still turns on/off. If you boot into FireOS with the adb root/permissive option, what does the UART output say when doing this?
In this mode, if I press the action button again the Cube reboots, but if I press any of the other buttons, and then action, the Cube does not reboot. So I'm wondering if the Cube is being dropped into some sort of diagnostic that may be accessible from UART.
I'd be interested in seeing any of the UART output including the reboot string
Code:
G12B:BL:6e7c85:2a3b91;FEAT:F2FB39B0:432060;POC:7;RCY:1;USB:3;
I don't know if there are any hidden button combinations when powering the device on that do anything. I'm not sure where that would be defined in the source code. Holding the vol - button during bootup puts the Cube in safe mode. I don't think there are any other known power up button functions yet.
Pro-me3us said:
When in FireOS, holding down the Cube action button (button with dot) for 15sec kills all processes and appears shut the device down. But the device is not powered off, the mute button still turns on/off. If you boot into FireOS with the adb root/permissive option, what does the UART output say when doing this?
Click to expand...
Click to collapse
I'm pretty sure that I executed the sequence described above. Advise If the following is not the correct sequence;
1. boot into FireOS with the adb root/permissive option
2. after fully booted, hold the action button for 15sec
3. after shutdown, try alternatively pressing buttons other than the action button
4. compare the results (of initially pressing buttons other than the action button after shutdown) to pressing the action button without first pressing other buttons.
Code:
=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2022.06.08 16:45:42 =~=~=~=~=~=~=~=~=~=~=~=
idme_platform_write block_offset=3e7000, capacity=400000
fos_flags set to 87
idme_platform_write block_offset=3e7000, capacity=400000
dev_flags set to 64
cmd cb_download is download:008f2800
Starting download of 9381888 bytes
.......................................................................
downloading of 9381888 bytes finished
Booting kernel...success
boot_addr_start bootm 0x1080000
kernel_size 0x8af0af, page_size 0x800, totalSz 0x8b0000
ramdisk_size 0x0, totalSz 0x0
dtbSz 0x42000, Total actualBootImgSz 0x8f2000
amzn_verify_onetime_unlock_code: Verify one time unlock cert fail, ret = -5
ee_gate_off ...
## Booting Android Image at 0x01080000 ...
reloc_addr =73d75610
copy done
Kernel command line: rootfstype=ext4 ro rootwait skip_initramfs OTG_mode=DEVICE androidboot.selinux=permissive
load bootimage dtb from 0x74625610 ......
.
.
.
[ [email protected]] input input0: key 138 down.
.
.
.
[ [email protected]] vendor_write_shutdown_reason: shutdown_reason 0x0
[ [email protected]] hdmitx: hw: avmute set to 2
[ [email protected]] ISSI: resetting device before reboot!
[ [email protected]] meson-mmc: meson_mmc_clk_set_rate_v3 269
[ [email protected]] meson-mmc: actual_clock :0, HHI_nand: 0x80
[ [email protected]] meson-mmc: [meson_mmc_clk_set_rate_v3] after clock: 0x10100002
[ [email protected]] amvecm: shutdown module
[ [email protected]] di pre hrtimer canel 1.
[ [email protected]] [DI] shutdown done.
[ [email protected]] vout: vout2: aml_vout2_shutdown
[ [email protected]] vout: aml_vout_shutdown
[ [email protected]] fb: osd_shutdown
[ [email protected]] amvdac_drv_shutdown: shutdown module
[ [email protected]] reboot: Power down
bl31 reboot reason: 0x108
bl31 reboot reason: 0x108
system cmd 0.
bl30 get wakeup sources!
process command 00000006
bl30 enter suspend!
Little core clk suspend rate 1908000000
Big core clk suspend rate -2086967296
store restore gp0 pll
suspend_counter: 1
Enter ddr suspend
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
The above log happened both when the action button was pressed and also when any other button was pressed instead (after shutdown). New lines containing "DMC_DRAM_STAT11: 0x24" are repeated endlessly, or at least for the 10 minutes that I let it run.
Pro-me3us said:
if I press the action button again the Cube reboots, but if I press any of the other buttons, and then action, the Cube does not reboot
Click to expand...
Click to collapse
I could not get the Cube to reboot if I pressed the action button again after shutdown. Perhaps I wasn't supposed to wait to press it until the shutdown was complete?
A reboot string never appeared, just ""DMC_DRAM_STAT11: 0x24"" endlessly until the power was cycled.
I'm still running PS7229/1856. I don't have an ota for an android 9 version of fireos that is not the current version.
If this is some sort of standby mode, I can't seem to wake out of it.
Do you happen to know why a uart command prompt console can't be started? If;
start console
is executed in a shell with root access, it appears to execute successfully, but no console command prompt appears over the uart connection.
Edit: resolved, disregard.
goapy said:
The above log happened both when the action button was pressed and also when any other button was pressed instead (after shutdown). New lines containing "DMC_DRAM_STAT11: 0x24" are repeated endlessly, or at least for the 10 minutes that I let it run.
Click to expand...
Click to collapse
Ah ok, maybe it is only a shutdown command in that case. The reboot reason 0x108 might be SHUTDOWN_LONG_PWR_KEY_PRESS according to sign_of_life_vendor.c. This looks similar to adb reboot -p which is a software shutdown (0x109?). After a software shutdown the Cube can also be rebooted with the action button. There may be no way to completely shutdown Cube without a real power button. I don't know why in this state pressing the action button doesn't consistently reboot.
Pressing the power button on the remote might also put the Cube in a similar suspension state that does allow waking.
goapy said:
Do you happen to know why a uart command prompt console can't be started? If;
start console
is executed in a shell with root access, it appears to execute successfully, but no console command prompt appears over the uart connection.
Edit: resolved, disregard.
Click to expand...
Click to collapse
I only ever used UART for logs while the kernel was loaded. I never tried to bring up a command prompt. Did you manage to get input working through UART?
For fos_flags the default is 0x0. If you are using the bash menu script it is setting the fos_flags to 0x87 each time FireOS with ADB root is booted. You will have to fastboot boot the image manually to avoid that. You can also set the Flag values with ADB root using the command 'idme fos_flags value'.
The focus was pretty narrow while working on getting the exploit working. I didn't spend much time with the bootrom. Frederic gave me most of the addresses I needed once the bootrom was extracted. I haven't heard of anyone finding extra I2C commands. Both the FireFU and Superna9999 page mention [email protected], but I don't know if that actually works.
You can take a look to see if there is anything interesting. To dump the Cube bootrom run the following command with the zipped files:
Code:
sudo ./amlogic-usbdl memdump_over_usb_s922x.bin cube_bootrom
There is also the question of what that missing 20pin connector is on the Cube PCB.