Database Develop

UART and bootloader strap pinouts for recovery

I started looking into bootloader-level recovery tonight before messing with the file system too much and potentially getting into a bad state. I couldn't find this information anywhere else.
UART pinout
J3 - 4 pin unpopulated header on the front of the board near the LED
Pin 1: 3.3v
Pin 2: TX
Pin 3: RX
Pin 4: GND
Bootloader and kernel console output comes out this port, but android doesn't start a shell.
Bootloader strap
On the back of the board in the center, there is an unpopulated button (U33). When jumped while the power button is pressed, this appears to put the bootloader into USB recovery mode. It enumerates with an nvidia vendor id. Presumably nvflash or tegrarcm could be used to unbrick the device.
I haven't done anything with the bootloader recovery since I haven't yet made a backup. I'm not sure how much of the functionality is allowed given the state of the production fuse, but I would think we could use this to at least get back to a stock state.

I had posted pretty much the same thing a few hours earlier over on the ouya forums - https://forums.ouya.tv/discussion/comment/11742/#Comment_11742
The good news about the bootloader is that none of the android partitions have any sort of signature, which means that the bootloader is effectively "unlocked", you can even do a "fastboot boot". The bad news is that there doesn't seem to be any sort of hotkey to enter the bootloader or recovery mode, although I did find that you could usually get into recovery with the sysrq, just press alt-sysrq-i a few times at bootup to crash the processes spawned by init and eventually it will reboot into recovery -- obviously this won't work if your ouya doesn't even boot that far, so be careful.
The button at u33 does get you into nvflash mode, but from what I can tell it's entirely useless since every command will return a 0x4; we'll need the secure boot key to actually get this working.
As far as backups, the OTA download contains an entire copy of the system and boot partitions, this can be flashed from recovery using adb sideload; rayman has posted a link to all the known OTA downloads over on this thread - http://forum.xda-developers.com/showthread.php?t=2266629

tylerwhall said:
I started looking into bootloader-level recovery tonight before messing with the file system too much and potentially getting into a bad state. I couldn't find this information anywhere else.
UART pinout
J3 - 4 pin unpopulated header on the front of the board near the LED
Pin 1: 3.3v
Pin 2: TX
Pin 3: RX
Pin 4: GND
Bootloader and kernel console output comes out this port, but android doesn't start a shell.
Bootloader strap
On the back of the board in the center, there is an unpopulated button (U33). When jumped while the power button is pressed, this appears to put the bootloader into USB recovery mode. It enumerates with an nvidia vendor id. Presumably nvflash or tegrarcm could be used to unbrick the device.
I haven't done anything with the bootloader recovery since I haven't yet made a backup. I'm not sure how much of the functionality is allowed given the state of the production fuse, but I would think we could use this to at least get back to a stock state.
Click to expand...
Click to collapse
Sadly, no. The way nvidia does security means that you need to know the Secure Boot key (if set - but it is set on ouya) to even be able to communicate with the device through APX/nvflash.
As embeem mentions, it will return 0x4, which essentially means "go away, i don't know you" after which it goes into an almost turned off state where it refuses to do anything but restart. The SBK is an AES-128 key so it's essentially impossible (inpractical) to bruteforce it.

rayman said:
Sadly, no. The way nvidia does security means that you need to know the Secure Boot key (if set - but it is set on ouya) to even be able to communicate with the device through APX/nvflash.
As embeem mentions, it will return 0x4, which essentially means "go away, i don't know you" after which it goes into an almost turned off state where it refuses to do anything but restart. The SBK is an AES-128 key so it's essentially impossible (inpractical) to bruteforce it.
Click to expand...
Click to collapse
So what was the trick that you used/developed to bypass the encryption on TF101 B80+ / TF201 / TF701 ? As far as I know their bootloaders also required SBK, nevertheless you published tool that works with them even though SBK remain unknown, or am I wrong and misread something?
Cheers

wolf849 said:
So what was the trick that you used/developed to bypass the encryption on TF101 B80+ / TF201 / TF701 ? As far as I know their bootloaders also required SBK, nevertheless you published tool that works with them even though SBK remain unknown, or am I wrong and misread something?
Cheers
Click to expand...
Click to collapse
Black magic.

Well, not much capable in nvflash mode, can't get anything to work properly.
UART lets me see it boot up, and fail miserably. Sadly, nothing doing there either. Nothing I send to it seems to affect it.
Back story: I broke init. The sysrq trick doesn't work unless you're getting to init.
Boot log via UART:
http://pastebin.com/ENQYQbTS
It still responds to sysrq, but nothing I'm doing seems to do much. I can dump the memory, crash the system, reboot it, shut it down, all kinds of things. Here's the HELP for sysrq:
Code:
[ 66.672046] SysRq : HELP : loglevel(0-9) reBoot Crash terminate-all-tasks(E) memory-full-oom-kill(F) kill-all-tasks(I) thaw-filesystems(J) show-backtrace-all-active-cpus(L) show-memory-usage(M) nice-all-RT-tasks(N) powerOff show-registers(P) show-all-timers(Q) Sync show-task-states(T) Unmount show-blocked-tasks(W) dump-ftrace-buffer(Z)
an easier list of sysrq commands:
Code:
alt + sysrq + [0-9] - set log level (doesn't seem to work)
alt + sysrq + B - reboot
alt + sysrq + C - crash
alt + sysrq + E - terminate-all-tasks
alt + sysrq + F - memory-full-oom
alt + sysrq + I - kill-all-tasks
alt + sysrq + J - thaw-filesystems
alt + sysrq + L - show-backtrace-all-active-cpus
alt + sysrq + M - show-memory-usage
alt + sysrq + N - nice-all-RT-tasks
alt + sysrq + O - poweroff
alt + sysrq + P - show-registers
alt + sysrq + Q - show-all-timers
alt + sysrq + S - sync
alt + sysrq + T - show-task-states
alt + sysrq + U - unmount
alt + sysrq + W - show-blocked-tasks
alt + sysrq + Z - dump-ftrace-buffer
Some more detailed information on what these are: http://en.wikipedia.org/wiki/Magic_SysRq_key
Open to ideas!

This reminds me of the old Droid X I had years back, which had a locked bootloader.
Because of this, there had to be a special "boot to recovery" boot strapper installed onto the system.
We have full RW access to the Ouya's filesystem and software, so it would seem like the first thing the community should do is develop some sort of "successfully booted" flagging to make the system try to automatically drop into CWM in the event that it looks like the OS is broken.
Couldn't such a thing live in the boot.img, and thus be available even if some silly person formats their /system partition? (This has happened already, and so the guy pretty much bricked his Ouya)

DivinityCycle said:
This reminds me of the old Droid X I had years back, which had a locked bootloader.
Because of this, there had to be a special "boot to recovery" boot strapper installed onto the system.
We have full RW access to the Ouya's filesystem and software, so it would seem like the first thing the community should do is develop some sort of "successfully booted" flagging to make the system try to automatically drop into CWM in the event that it looks like the OS is broken.
Couldn't such a thing live in the boot.img, and thus be available even if some silly person formats their /system partition? (This has happened already, and so the guy pretty much bricked his Ouya)
Click to expand...
Click to collapse
My plan is to develop a sysrq key to write the appropriate bit(s) to SCRATCH0 and reboot. This would allow us to get into recovery via a simple keystroke. I've actually got it written but need to test it. Testing it would not be dangerous as it would normally boot the stock kernel/init.
Next week when I'm home I'll try to find a tester since I cannot test it (can't write anything to my mmcblk0)
This shouldn't be dangerous to test.
Sent from my SCH-I545 using Tapatalk 4 Beta

Any news on uart? I guess I bricked my ouya.
I was testing my custom kernel, did forget to use fastboot boot instead of flash and now have nothing but a black screen. My linux machine doesn't recognize my ouya and I can't go to recovery. So at least knowing what is causing the issue would be helpful.
Do you mind giving me a short intro on uart?
I guess I need a usb/uart adapter? If yes, which one should I get?
Thanks in advance
Gesendet von meinem HTC One X+ mit Tapatalk 2

anyone already saw this: http://forum.xda-developers.com/showthread.php?t=2071626
did only have time to skimm it but might be useful to people with still working devices
aim is to get the sbk which should be - if i have understood it the right way - unique for each device as long as the company didn't burn in a fix sbk.
so maybe this will help us to save people from further bricks...as long as nvflash is usable via usb

Has anyone tested in on ouya ?
Sent from my iPad using Tapatalk - now Free

Not yet i think...i know i won't be testing it on my OUYA no time soon, i don't feel like having my box BRICKED like nchantmnt does, screw this, it's too early to test this , i wont even risk it, i dont feel like buying another OUYA for testing this...

Hey... no pain no gain
Gesendet von meinem HTC One X+ mit Tapatalk 2

I have an idea for a small usb device that could force the ouya into recovery mode using the keyboard combination mentioned below:
http://ouyabrew.com/how-to-put-ouya-in-recovery-mode/
Essentially my idea is to have a little usb circuit board with a micro controller that is smart enough to simulate a keyboard periodically sending the specified keypresses. When the ouya goes into recovery you would just yank out the dongle. I don't have any background technical knowledge in this stuff but this sounds like something Ben Heck could whip up (he is a legend).
Update: Looks like these are already a thing! this looks promising:
http://www.irongeek.com/i.php?page=...ke-dongle#So,_why_would_a_pen-tester_want_one

zondajag said:
I have an idea for a small usb device that could force the ouya into recovery mode using the keyboard combination mentioned below:
http://ouyabrew.com/how-to-put-ouya-in-recovery-mode/
Essentially my idea is to have a little usb circuit board with a micro controller that is smart enough to simulate a keyboard periodically sending the specified keypresses. When the ouya goes into recovery you would just yank out the dongle. I don't have any background technical knowledge in this stuff but this sounds like something Ben Heck could whip up (he is a legend).
Update: Looks like these are already a thing! this looks promising:
http://www.irongeek.com/i.php?page=...ke-dongle#So,_why_would_a_pen-tester_want_one
Click to expand...
Click to collapse
this is a sweet idea, i wasn't aware of a programmable HID USB keystroke dongle...This would make things easier...i hope someone makes something out of this, this will solve the booting into recovery bigtime!!!

zondajag said:
I have an idea for a small usb device that could force the ouya into recovery mode using the keyboard combination mentioned below:
http://ouyabrew.com/how-to-put-ouya-in-recovery-mode/
Essentially my idea is to have a little usb circuit board with a micro controller that is smart enough to simulate a keyboard periodically sending the specified keypresses. When the ouya goes into recovery you would just yank out the dongle. I don't have any background technical knowledge in this stuff but this sounds like something Ben Heck could whip up (he is a legend).
Update: Looks like these are already a thing! this looks promising:
http://www.irongeek.com/i.php?page=...ke-dongle#So,_why_would_a_pen-tester_want_one
Click to expand...
Click to collapse
This would only work if the stock kernal is installed and the recovery partition is intact. If you lose you recovery partition you won't be able to boot recovery and get adb working, and if the kernel isn't the stock kernel the keyboard combo won't work.

Also no use for broken init
Gesendet von meinem HTC One X+ mit Tapatalk 2

cronikman84 said:
Not yet i think...i know i won't be testing it on my OUYA no time soon, i don't feel like having my box BRICKED like nchantmnt does, screw this, it's too early to test this , i wont even risk it, i dont feel like buying another OUYA for testing this...
Click to expand...
Click to collapse
I don't think that this necessarily means bricking your device.
You could always try fastboot boot patched kernel and then try reading fuse values.
I was playing with this method to run Debian:
http://tuomas.kulve.fi/blog/2013/09/12/debian-on-ouya-all-systems-go/
It is an easy procedure and I've got it running. Unfortunately my USB hub is not working correctly with ouya (it's passive so voltage on USB can be low), so I didnt login into it, but you could use this method to try to extract sbk keys.
Sent from my iPad using Tapatalk - now Free

nvflash
How About this : http://forum.xda-developers.com/showthread.php?t=2455927 ????

we first need to know if we do have a "masker sbk" or a device specific sbk.
for device-specific sbk this methode should work but only with a wheelie-enabled recovery for our device
don't try to flash any other recovery to your device or you're in danger of bricking it.
if you have access to the source and can add the required option for generating blob files to a working recovery image, then this should work for device specific sbks.
then you can use any uart-adapter/raspberry pi/etc. to connect to your device and make backup and flash partitions.
(NOTE: DO NOT USE YOUR PCS SERIAL OUTPUT - IT MIGHT DAMAGE YOUR DEVICE AND YOUR PC AS WELL... OH AND IT WILL NOT WORK)
if we do have any kind of masker-sbk i can only talk in theory:
you normally should be able to read out sbk from running system but this is of course prevented (in most cases by some kerner config).
i don't know exactly by what methode and what files exactly to change but I have read somewhere that you could make a custom kernel which doens't prevent read out of sbk. then fastboot boot boot.img, read out sbk and sould be good to go.
but praxis might be a good bit harde
... or maybe blob mehtode might work.
got important exams tomorrow but if anyone could send me link to wheelie-enabled n7 recovery i might take a look the next days.
maybe recovery-devs could make something out of it even earlier

[Workshop] Unbrick fully bricked I9070

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Reset or re-flash uefi after wrong modifications

Hi all!
I have an asus memo pad me176cx. I did some stuff with it and now it seems bricked, but not fully (as I hope...).
But I am not very experienced user with android, so I have a few adjacent questions to define myself in root concepts.
On general - I tried to install debian linux on my tablet. Looking ahead - i managed to run installer. But in order...
My actions before i got brick.
I got an issue similar to this one after updates. There i saw that tablet has a kind of uefi. And i decided to run debian. Prepared usb-installer, connected that one and keyboard via OTG by hub(i have one with led indicator). I pressed F2 and power button on tablet, and saw uefi. There did boot override -> UEFI jet flash. And debian installer ran succesfully.
But after about a minute on-hub led becomes dark, as did flash led. Kbd was not working. At that moment i was on network config step and decided to reboot tablet. Power button about 10sec - and all over again. But after a while - same issue. It would not be nice if flash comes down while packages copying - I thought. And... Of cause boot into uefi to search some otg-power-options (btw i got same behaviour with otg in uefi and was forced to make changes quickly or reboot).
I don`t remember what option exactly i changed, but i have only hw buttons on tablet working. No otg at all (led is always dark now, no flash none kbd works), no touchscreen (i have twrp installed and checked there).
Finally, what works.
I can press vol+ - vol- - pwr, then see "Fastboot startnig... #1 #2 #3" on display - and get into some mode, called DNX (as i googled).
Code:
fastboot devices
shows my tablet. But i can flash only osloader partition. Other way - error, unsupported operation. Also i can command
Code:
fastboot boot droidboot.img
and get into bootloader. This case at the bottom of screen shown "Waiting for fastboot cmd...". But
Code:
fastboot devices
shows notheng. Any other fastboot commands stuck on "wating for any device...". But with vol-buttons i can choose recovery mode, then press power and get into twrp and look on "Swipe to allow filesystem modification". But as far as touchscreen dows not work (as otg-keyboard) - i can`t do anything else. adbd seems not started yet, as
Code:
adb devices
shows nothing (or micro-usb plug simply disabled with uefi). And that is all, i can`t do anything else...
In fine, my questions are:
Mode started by "vol+ - vol- - pwr" - does it DNX or fastboot? How to find out what commnds i can run there? (At the moment I know 2 only: flash osloader and boot). Why flash ESP, erase, even get [some_var] does not work here? Is there a way to re-flash or reset uefi settings from this mode?
Or any other ways to reset uefi? (as possible without microwave...)
Also, what difference between osloader and bootloader? I suggest that osloader is a partition and bootloader is a program placed in that partition. But what exactly i do with command "fastboot flash osloader efilinux.efi"?
Sorry for lot of text, but I actualy don`t know how this modes called and got confused. Any help would be appriciated.
Anyway, thanks a lot!

mk3pq28 said:
I don`t remember what option exactly i changed, but i have only hw buttons on tablet working. No otg at all (led is always dark now, no flash none kbd works), no touchscreen (i have twrp installed and checked there).
Click to expand...
Click to collapse
I think I've seen some option that changes the way USB OTG is set up. By changing it you have probably disabled USB OTG entirely now... :/
mk3pq28 said:
Mode started by "vol+ - vol- - pwr" - does it DNX or fastboot?
Click to expand...
Click to collapse
DNX
mk3pq28 said:
How to find out what commnds i can run there? (At the moment I know 2 only: flash osloader and boot). Why flash ESP, erase, even get [some_var] does not work here?
Click to expand...
Click to collapse
DNX is not a full fastboot implementation. It runs in the firmware, somewhere during early UEFI initialization. It's mostly designed for recovery when the (Android) bootloader is no longer working. The two commands you know are the only ones I'm aware of, sorry :/
mk3pq28 said:
Is there a way to re-flash or reset uefi settings from this mode?
Or any other ways to reset uefi? (as possible without microwave...)
Click to expand...
Click to collapse
I can imagine that it is possible but I have to admit that I don't know how. For example there is Intel® Platform Flash Tool Lite that allows re-flashing pretty much all of the device, but I'm not sure where you'd get the factory files. At the moment, I don't have any suggestions how to solve your problem... :/
mk3pq28 said:
Also, what difference between osloader and bootloader? I suggest that osloader is a partition and bootloader is a program placed in that partition. But what exactly i do with command "fastboot flash osloader efilinux.efi"?
Click to expand...
Click to collapse
osloader refers to the EFI application that is started. efilinux.efi is an Android bootloader for UEFI. In this case it's not actually written persistently somewhere, it is just loaded into RAM and then executed.

lambdadroid,
first of all - thanks a lot for your participating!
So, after your clarification I made a few suggestions.
lambdadroid said:
I can imagine that it is possible but I have to admit that I don't know how. For example there is Intel® Platform Flash Tool Lite that allows re-flashing pretty much all of the device, but I'm not sure where you'd get the factory files.
Click to expand...
Click to collapse
First one. I installed it and downloaded service firmware. Flash tool found my tablet and showed some info:
Plaform: Intel Corporation
Hardware: Intel Android AD
Status: DNX_OS
Connected on port: 0/1 (number of usb port, i think)
DnX SN: Baytrail<some>
Then i selected service firmware and flash tool showed me flash.xml in "flash file" field. Everything looks normal at the moment, until i pressed flash)
The only one record appeared in log below: "Failed to reboot the device. Flash failed". And i don`t know someshing else i can make here.
I am new here and can`t post links to outside, but i googled some more meaningful examples of log by my error. And as i understood chain of commands - flash tool does exactly same as i did. I.e. flashes osloader in dnx mode, then boots in fastboot and flashes another partitions there. Correct me if i`m wrong but it does not seems for my case, unfortunately
And the second one, more complex.
I had googled a lot about uefi and it`s settings location. I found out that "settings" made in uefi are stored in memory called NVRAM. It is non-volatile and can not be reset by battery disconnected (yes, i tried that, ofc). But there should be a flag called NVRAM_IS_VALID. And once it gets disabled - uefi is forced to reset all the settings to defaults next boot time. I`m not sure, but looks like my solution!
And I can suggest two ways of setting this flag.
lambdadroid said:
osloader refers to the EFI application that is started. efilinux.efi is an Android bootloader for UEFI.
Click to expand...
Click to collapse
First one - uefi shell. If i can replace bootloader, may it be a shell? I downloaded one from github (a link should be here ) but have no success yet. It`s size about 930kb, but my working one bootloader - is 2mb. And when i make flash - nothing happens:
Code:
# fastboot flash osloader Shell.efi
target didn't report max-download-size
sending 'osloader' (929 KB)...
Nothing more. Maybe there should be some special kind of uefi-shell for android? Or I can`t flash nothing but bootloder into osloader partition at all? But even if i`m succeed - i`m not sure that uefi would not disable otg before shell get running.
So my second and the last sugesstion. It`s fully theoretical, but... I need to write a custom efi app (.efi files are kind of applications for uefi, written in c, right?) that would be flashed into osloader and should disable NVRAM_IS_VALID flag (ohh, does that flag exists at all?...). Does it possible?
Anyway, thanks a lot for any help!

mk3pq28 said:
I installed it and downloaded service firmware. Flash tool found my tablet and showed some info:
Plaform: Intel Corporation
Hardware: Intel Android AD
Status: DNX_OS
Connected on port: 0/1 (number of usb port, i think)
DnX SN: Baytrail<some>
Then i selected service firmware and flash tool showed me flash.xml in "flash file" field. Everything looks normal at the moment, until i pressed flash)
The only one record appeared in log below: "Failed to reboot the device. Flash failed". And i don`t know someshing else i can make here.
I am new here and can`t post links to outside, but i googled some more meaningful examples of log by my error. And as i understood chain of commands - flash tool does exactly same as i did. I.e. flashes osloader in dnx mode, then boots in fastboot and flashes another partitions there. Correct me if i`m wrong but it does not seems for my case, unfortunately
Click to expand...
Click to collapse
Okay, yeah, that's very well possible. I've never used that tool and don't know what it does.
mk3pq28 said:
I had googled a lot about uefi and it`s settings location. I found out that "settings" made in uefi are stored in memory called NVRAM. It is non-volatile and can not be reset by battery disconnected (yes, i tried that, ofc). But there should be a flag called NVRAM_IS_VALID. And once it gets disabled - uefi is forced to reset all the settings to defaults next boot time. I`m not sure, but looks like my solution!
Click to expand...
Click to collapse
It makes sense that the settings are stored in the NVRAM. But that's about all I can comment on; I'm not sure if that flag exists on this tablet or even if it will reset to the correct results.
mk3pq28 said:
uefi shell. If i can replace bootloader, may it be a shell? I downloaded one from github (a link should be here ) but have no success yet. It`s size about 930kb, but my working one bootloader - is 2mb. And when i make flash - nothing happens:
Code:
# fastboot flash osloader Shell.efi
target didn't report max-download-size
sending 'osloader' (929 KB)...
Nothing more. Maybe there should be some special kind of uefi-shell for android? Or I can`t flash nothing but bootloder into osloader partition at all? But even if i`m succeed - i`m not sure that uefi would not disable otg before shell get running.
Click to expand...
Click to collapse
You may need to run "fastboot boot droidboot.img" (or any other image) too to have Fastboot run the EFI application. The Shell application will then likely ignore the additional boot image. However, as you mention, I believe that OTG will get disabled before the shell is running. The UEFI shell application is no different from the UEFI Setup as far as OTG is concerned. So if you are unable to enter the setup with F2 then the UEFI shell will probably not work either. So even if the Shell starts, I doubt that you will be able to run commands.
And no, there is no special kind of UEFI Shell for Android. This is all unrelated to Android actually.
mk3pq28 said:
It`s fully theoretical, but... I need to write a custom efi app (.efi files are kind of applications for uefi, written in c, right?) that would be flashed into osloader and should disable NVRAM_IS_VALID flag (ohh, does that flag exists at all?...). Does it possible?
Click to expand...
Click to collapse
That's actually something I considered suggesting yesterday. I decided against it because it's obviously not trivial and I'm not sure if EFI applications can actually access that flag or BIOS settings in general... However, I can assist you with how to write EFI applications in general. They are usually written in C and then compiled using some funky compiler flags and tools to .efi.
An example for a very simple EFI application is "bootstrap.efi" that is used in me176c-boot. The source for it is available at https://github.com/me176c-dev/me176c-boot/tree/master/bootstrap
In me176c-boot it runs as first EFI application and checks if the tablet was booted due to charger insertion; if yes then it sets an EFI variable. I'm not sure if the flag you mention is exposed as an EFI variable. However, persistent EFI variables are also stored in the NVRAM, so that might be something to look at. It's built using Meson (see meson.build). The build script might be of help to you.

lambdadroid said:
That's actually something I considered suggesting yesterday. I decided against it because it's obviously not trivial and I'm not sure if EFI applications can actually access that flag or BIOS settings in general...
Click to expand...
Click to collapse
But I don`t see any other kind of solution.
lambdadroid said:
It makes sense that the settings are stored in the NVRAM. But that's about all I can comment on; I'm not sure if that flag exists on this tablet or even if it will reset to the correct results.
Click to expand...
Click to collapse
I think it won`t get worse anyway, so...
Thanks a lot for your general information about efi. I took that and was able to get started. I did some experiments and had interesting results. Little notice - i`m on debian.
At first
I had installed gnu-efi and mason. Also googled "Hello world" in efi-style. I still cant post links to outside but the code is below. Looking ahead - had no result with one Print because it was closed very fast so i added a loop.
Code:
#include <efi.h>
#include <efilib.h>
EFI_STATUS
EFIAPI
efi_main (EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
{
InitializeLib(ImageHandle, SystemTable);
for (int i = 0; i < 5000; ++i)
{
Print(L"B It works!!!\r\n");
}
return EFI_SUCCESS;
}
Looks simple.
Also i took your meson.build and replaced file names with mine. But i got a few conpilation errors so i had removed some keys from target. Here it is:
Code:
project('tutorial', 'c')
arch = host_machine.cpu_family()
efi_include_dir = '/usr/include/efi'
efi_include = include_directories(
efi_include_dir,
join_paths(efi_include_dir, arch),
is_system: true
)
efi_lds = '/usr/lib/elf_' + arch + '_efi.lds'
efi_crt = '/usr/lib/crt0-efi-' + arch + '.o'
bootstrap_lib = shared_library('bootstrap',
'hello_efi.c',
include_directories: [efi_include],
objects: [efi_crt],
link_args: [
'-T', efi_lds,
'-nostdlib',
'-z', 'nocombreloc',
'-Wl,-Bsymbolic',
'-lefi', '-lgnuefi'
]
)
objcopy = find_program('objcopy')
custom_target('bootstrap.efi',
output: 'bootstrap.efi',
input: bootstrap_lib,
command: [objcopy,
'--target=efi-app-' + arch,
'-j', '.text',
'-j', '.sdata',
'-j', '.data',
'-j', '.dynamic',
'-j', '.dynsym',
'-j', '.rel',
'-j', '.rela',
'-j', '.reloc',
'@[email protected]', '@[email protected]'
],
install: true,
install_dir: ''
)
hello_efi.c contains source code from above.
This is my first meson build so if yoy see some obvious mistakes or excess options - i would be much appreciated if you point on them.
At second
I created builddir, commanded "meson" and "ninja" and got such output:
Code:
[1/3] Compiling c object '[email protected]/hello_efi.c.o'
../hello_efi.c: In function ‘efi_main’:
../hello_efi.c:13:9: warning: passing argument 1 of ‘Print’ from incompatible pointer type [-Wincompatible-pointer-types]
Print(L"B It works!!!\r\n");
^~~~~~~~~~~~~~~~~~~~
In file included from ../hello_efi.c:2:0:
/usr/include/efi/efilib.h:404:1: note: expected ‘CHAR16 * {aka short unsigned int *}’ but argument is of type ‘int *’
Print (
^~~~~
[3/3] 'Generating bootstrap.efi with a custom command.'
I am not very familiar with C and can`t get rid of warning to print my message properly. As far as Print requires CHAR16 pointer only first symbol is printed. How to properly get and array of CHAR16 from "a string"?
Anyway, it`s a bite of success.
And at third, final
I was very happy and connected tab (in DNX, ofc) with pc and commaned: "fastboot flash osloader bootstrap.efi".
Code:
target didn't report max-download-size
sending 'osloader' (44 KB)...
And nothing more. Command is still running untill tablet reboot. But!
I have another ont efilinux.efi was downloaded from somewhere. And it flashes correctly! The only difference is on size: 44KB vs 2MB.
I did some research with dd-util and found one interesting thing. It is allowed to flash osloader partition in dnx mode with completely any binary data within (nearly) 1MB .. 20MB. In this case "fastboot flash osloader ..." says OK twice and finishes properly.
So, my flow after compilation have a such look (2057216 - is a size of my working example efilinux.efi)
Code:
$ dd if=/dev/zero of=container.efi count=2057216 iflag=count_bytes
$ dd if=bootstrap.efi of=container.efi conv=nocreat,notrunc
# fastboot flash osloader container.efi
# fastboot boot droidboot.img
... and i have a char 'B' on screen printed 5000 times. I think it`s another one bite of success
But i can`t find any docs for efi.h (efilib.h). Which capabilities they provides? What is set of functinos?
There is another example with
Code:
uefi_call_wrapper(ST->ConOut->OutputString, 2, ST->ConOut, L"Hello World!\n");"
but it is not obvious how to work with uefi services in this way.
I googled that most of uefi settings are stored in "Setup" variable. I think it may be useful at least to print them. But don`t know how, yet.
I will google it further but in general i don`t know what is the next step should be.

Also i have an idea to use such trick to flash efi-shell. But didn`t tried yet.

mk3pq28 said:
At first
I had installed gnu-efi and mason. Also googled "Hello world" in efi-style. I still cant post links to outside but the code is below. Looking ahead - had no result with one Print because it was closed very fast so i added a loop.
Code:
#include <efi.h>
#include <efilib.h>
EFI_STATUS
EFIAPI
efi_main (EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
{
InitializeLib(ImageHandle, SystemTable);
for (int i = 0; i < 5000; ++i)
{
Print(L"B It works!!!\r\n");
}
return EFI_SUCCESS;
}
Looks simple.
Also i took your meson.build and replaced file names with mine. But i got a few conpilation errors so i had removed some keys from target. Here it is:
Code:
project('tutorial', 'c')
arch = host_machine.cpu_family()
efi_include_dir = '/usr/include/efi'
efi_include = include_directories(
efi_include_dir,
join_paths(efi_include_dir, arch),
is_system: true
)
efi_lds = '/usr/lib/elf_' + arch + '_efi.lds'
efi_crt = '/usr/lib/crt0-efi-' + arch + '.o'
bootstrap_lib = shared_library('bootstrap',
'hello_efi.c',
include_directories: [efi_include],
objects: [efi_crt],
link_args: [
'-T', efi_lds,
'-nostdlib',
'-z', 'nocombreloc',
'-Wl,-Bsymbolic',
'-lefi', '-lgnuefi'
]
)
objcopy = find_program('objcopy')
custom_target('bootstrap.efi',
output: 'bootstrap.efi',
input: bootstrap_lib,
command: [objcopy,
'--target=efi-app-' + arch,
'-j', '.text',
'-j', '.sdata',
'-j', '.data',
'-j', '.dynamic',
'-j', '.dynsym',
'-j', '.rel',
'-j', '.rela',
'-j', '.reloc',
'@[email protected]', '@[email protected]'
],
install: true,
install_dir: ''
)
hello_efi.c contains source code from above.
This is my first meson build so if yoy see some obvious mistakes or excess options - i would be much appreciated if you point on them.
At second
I created builddir, commanded "meson" and "ninja" and got such output:
Code:
[1/3] Compiling c object '[email protected]/hello_efi.c.o'
../hello_efi.c: In function ‘efi_main’:
../hello_efi.c:13:9: warning: passing argument 1 of ‘Print’ from incompatible pointer type [-Wincompatible-pointer-types]
Print(L"B It works!!!\r\n");
^~~~~~~~~~~~~~~~~~~~
In file included from ../hello_efi.c:2:0:
/usr/include/efi/efilib.h:404:1: note: expected ‘CHAR16 * {aka short unsigned int *}’ but argument is of type ‘int *’
Print (
^~~~~
[3/3] 'Generating bootstrap.efi with a custom command.'
I am not very familiar with C and can`t get rid of warning to print my message properly. As far as Print requires CHAR16 pointer only first symbol is printed. How to properly get and array of CHAR16 from "a string"?
Anyway, it`s a bite of success.
Click to expand...
Click to collapse
I believe the compiler argument that avoids this error is -fshort-wchar, but you seem to have removed all c_args: https://github.com/me176c-dev/me176c-boot/blob/master/bootstrap/meson.build#L33 All of these compiler arguments have a purpose, can you check which one is causing errors exactly and post the error here?
mk3pq28 said:
And at third, final
I was very happy and connected tab (in DNX, ofc) with pc and commaned: "fastboot flash osloader bootstrap.efi".
Code:
target didn't report max-download-size
sending 'osloader' (44 KB)...
And nothing more. Command is still running untill tablet reboot. But!
I have another ont efilinux.efi was downloaded from somewhere. And it flashes correctly! The only difference is on size: 44KB vs 2MB.
I did some research with dd-util and found one interesting thing. It is allowed to flash osloader partition in dnx mode with completely any binary data within (nearly) 1MB .. 20MB. In this case "fastboot flash osloader ..." says OK twice and finishes properly.
So, my flow after compilation have a such look (2057216 - is a size of my working example efilinux.efi)
Code:
$ dd if=/dev/zero of=container.efi count=2057216 iflag=count_bytes
$ dd if=bootstrap.efi of=container.efi conv=nocreat,notrunc
# fastboot flash osloader container.efi
# fastboot boot droidboot.img
Click to expand...
Click to collapse
That's weird, the size shouldn't matter at all. But it doesn't really matter, as long as it works.
mk3pq28 said:
But i can`t find any docs for efi.h (efilib.h). Which capabilities they provides? What is set of functinos?
There is another example with
Code:
uefi_call_wrapper(ST->ConOut->OutputString, 2, ST->ConOut, L"Hello World!\n");"
but it is not obvious how to work with uefi services in this way.
I googled that most of uefi settings are stored in "Setup" variable. I think it may be useful at least to print them. But don`t know how, yet.
I will google it further but in general i don`t know what is the next step should be.
Click to expand...
Click to collapse
Generally, the interface exposed by gnu-efi is according to the UEFI specification: http://www.uefi.org/sites/default/files/resources/UEFI Spec 2_7_A Sept 6.pdf
In there you can find a list of protocols you can use, e.g. search for the "OutputString" method used above.
uefi_call_wrapper is an implementation detail of gnu-efi, but basically it's uefi_call_wrapper(<method>, <number of parameters>, <parameters...>).
The main remaining question, and the one I can't really help you with is how you can reset your BIOS settings using the UEFI application API. Maybe something to look at first would be the "Variable Services" (see UEFI specification). Maybe you can change one of the EFI variables to restore the default BIOS settings.

lambdadroid said:
I believe the compiler argument that avoids this error is -fshort-wchar, but you seem to have removed all c_args: https://github.com/me176c-dev/me176c-boot/blob/master/bootstrap/meson.build#L33 All of these compiler arguments have a purpose, can you check which one is causing errors exactly and post the error here?
Click to expand...
Click to collapse
Yes, this key removed warning. Thanks.
lambdadroid said:
Generally, the interface exposed by gnu-efi is according to the UEFI specification: http://www.uefi.org/sites/default/files/resources/UEFI Spec 2_7_A Sept 6.pdf
In there you can find a list of protocols you can use, e.g. search for the "OutputString" method used above.
Click to expand...
Click to collapse
Exactly one i`m looking for. Thanks again!
Unfortunately there is nothing about NVRAM_IS_VALID there.
But there is a function called "ResetSystem()" (p.269). It should reset the entire platform as written in doc.
My code:
Code:
#include <efi.h>
#include <efilib.h>
EFI_STATUS
EFIAPI
#define SLEEP 100
efi_main (EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
{
InitializeLib(ImageHandle, SystemTable);
for (int i = 0; i < SLEEP; ++i)
{
Print(L"It works!!! #%d", i);
uefi_call_wrapper(ST->ConOut->OutputString, 2, ST->ConOut, L"\r\n");
}
int res = uefi_call_wrapper(RT->ResetSystem, 4, EfiResetCold, EFI_SUCCESS, 0, NULL);
for (int i = 0; i < SLEEP; ++i) Print(L"%d\r\n", res);
return EFI_SUCCESS;
}
}
Yes, i`d noticed that "The ResetSystem() function does not return".
But i`m not sure that i call it properly.
When i run the code above - it prints the message 100 times, then screen blinks and the next message appears: "EFILINUX ERROR [start_boot_logic:498] No valid target found.
Fallbacking to MOS" in about 3 sec. Looks like there no reboot in this case because of the intel logo is not shown. I have no system on my tablet, but it`s another story.
The main point is there is no black screen with intel logo for about 15-20 sec as in case of normal boot.
In addition i tried to change call with:
Code:
uefi_call_wrapper(RT->ResetSystem, 4, L"Wrong_argument", EFI_SUCCESS, 0, NULL)
and it prints "968832152" return code. Does it fail somewhere before ResetSystem() or exactly inside?
So am i calling this function correctly?

mk3pq28 said:
Yes, this key removed warning. Thanks.
Exactly one i`m looking for. Thanks again!
Unfortunately there is nothing about NVRAM_IS_VALID there.
But there is a function called "ResetSystem()" (p.269). It should reset the entire platform as written in doc.
My code:
Code:
#include <efi.h>
#include <efilib.h>
EFI_STATUS
EFIAPI
#define SLEEP 100
efi_main (EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
{
InitializeLib(ImageHandle, SystemTable);
for (int i = 0; i < SLEEP; ++i)
{
Print(L"It works!!! #%d", i);
uefi_call_wrapper(ST->ConOut->OutputString, 2, ST->ConOut, L"\r\n");
}
int res = uefi_call_wrapper(RT->ResetSystem, 4, EfiResetCold, EFI_SUCCESS, 0, NULL);
for (int i = 0; i < SLEEP; ++i) Print(L"%d\r\n", res);
return EFI_SUCCESS;
}
}
Yes, i`d noticed that "The ResetSystem() function does not return".
But i`m not sure that i call it properly.
When i run the code above - it prints the message 100 times, then screen blinks and the next message appears: "EFILINUX ERROR [start_boot_logic:498] No valid target found.
Fallbacking to MOS" in about 3 sec. Looks like there no reboot in this case because of the intel logo is not shown. I have no system on my tablet, but it`s another story.
The main point is there is no black screen with intel logo for about 15-20 sec as in case of normal boot.
In addition i tried to change call with:
Code:
uefi_call_wrapper(RT->ResetSystem, 4, L"Wrong_argument", EFI_SUCCESS, 0, NULL)
and it prints "968832152" return code. Does it fail somewhere before ResetSystem() or exactly inside?
So am i calling this function correctly?
Click to expand...
Click to collapse
I'm afraid ResetSystem() is not what you are looking for: ResetSystem() is only used to reboot the system, it does not "reset" any settings. So the screen flashes and you see that message because the tablet is restarted normally. (The bootloader you are using displays an error if you reboot without setting a "reboot target").
So you need to find some other method, or entirely different solution unfortunately. I just did a bit of research myself, but unfortunately didn't find anything of help..

Fire 7 (2019, mustang) unbrick, downgrade, unlock & root

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

[UNLOCK][ROOT][TWRP][UNBRICK] Fire TV Stick 4K (mantis)

NOTE: There have been multiple reports of devices with serial numbers containing VM190 or higher being shipped with DL-Mode disabled in BROM.
These devices cannot be unlocked using kamakiri.
These devices do not show up at all on USB when shorted.
After the old bootrom-exploit (amonet) we've been using for unlocking all these Fire-gadgets is closed in more recent Mediatek SOCs like the one used in the FireTV Stick 4K, @xyz` has done it again and found another bootrom-exploit.
Together we proudly present kamakiri for the FireTV Stick 4K.
Before proceeding make sure to read and understand this entire post.
Running this exploit requires a patched linux-kernel on the PC you are using.
We have put together a Live-ISO that already contains all prerequisites required for running kamakiri.
You can find the current version of the ISO at:
https://github.com/amonet-kamakiri/fireiso/releases
It can be burned to a CD or to a USB-flashdrive.
Current Version: kamakiri-mantis-v2.0.1.zip
You will need to open the device and remove the heatshield on the side without the antennas (2 square bricks).
NOTE: It is not required to desolder or force the shield off, it is just clipped onto a frame. (The attached picture may be a bit misleading, since it also has the frame removed)
You will need something for shorting (wire, aluminum foil etc.)
Boot the ISO
Download and extract the exploit package.
Open a terminal in the kamakiri directory
Run
Code:
./bootrom-step.sh
Short one of the points in the attached photo to ground (the cage of the shielding).
Ideally you want to use DAT0, since that is tiny it might be easier to short the point marked CLK instead.
It is very important that you use a piece of soft wire or aluminum foil or something similar for shorting. Don't use tweezers as that makes it incredibly easy to knock of the capacitor off the PCB and kill the board!
Connect the stick to your computer (while keeping it shorted)
The script should tell you to release the short and hit enter
Once finished run
Code:
./fastboot-step.sh
Your device will now reboot into TWRP
Important information
Don't flash boot/recovery images from FireOS (FlashFire, MagiskManager etc.)
TWRP will prevent updates from overwriting LK/Preloader/TZ, so generally installing an update should work without issues (only full updates, incremental updates won't work).
For ROM developers there is still an option to overwrite these, which should only be done after thorough testing and if needed (LK should never be updated).
It is still advised to disable OTA.
thanks to @hwmod for the picture
thanks to @Sus_i for providing an update.bin
thanks to @zeroepoch for developing aftv2-tools
Contributors
k4y0z, xyz`
Source Code: https://github.com/amonet-kamakiri/

There are three options for interacting with TWRP:
A mouse via USB-OTG
TWRP commandline via adb: https://twrp.me/faq/openrecoveryscript.html
Via /cache/recovery/command
Example for /cache/recovery/command:
Code:
echo "--update_package=/path/to/zipfile" > /cache/recovery/command
echo "--wipe_cache" >> /cache/recovery/command
reboot recovery
Should you somehow end in a bootloop, TWRP contains a special boot menu that will be displayed when you boot the stick with an OTG-cable connected.
It will give you 5 seconds to hit cancel and stay in TWRP or reboot into the OS otherwise.
NOTE:This will only work if the boot-exploit is still there.

Changelog:
Version 2.0.1 (04.03.2022)
Fix Boot Menu on TWRP-Install
Version 2.0 (02.03.2022)
Update PL and TZ
Update TWRP to 3.6.1_9-0
Add support for boot-recovery and boot-fastboot
Add support for fused devices with FireOS < 6.2.8.7
Version 1.2 (20.10.2019)
Update TZ from 6.2.6.6
Add support for updating via TWRP
Version 1.1 (17.10.2019)
Add delay to properly flush data to EMMC

Yesss!!! Thanks.

Mother of GOD.
Can't believe.
And can't wait for a clean Android TV Rom.
It will be amazing since I need to use an American account to use this fire stick 4k in my country.

Complete, no issues... Great job! Thanks for the live USB, could not have made this easier!

@k4y0z I wonder why this cannot be done in Ubuntu?
I'm able to install pyusb with:
Code:
sudo apt-get install python-usb python3-usb
And then the scripts start. Is due the kernel patch?
BTW: good work I still looking at the exploit in github and looks awesome lol.

Rortiz2 said:
@k4y0z I wonder why this cannot be done in Ubuntu?
Click to expand...
Click to collapse
k4y0z said:
Running this exploit requires a patched linux-kernel on the PC you are using.
Click to expand...
Click to collapse
If you patch your kernel, there is no reason it wouldn't work on ubuntu.

I love the option to go into TWRP on boot with an OTG.... Fantastic!

Thanks to everyone involved. So happy to get some control over the 4k!

Can someone explain how to get the shield off?

rbox said:
Can someone explain how to get the shield off?
Click to expand...
Click to collapse
The heatsink and shield come off together, they are clipped on.
Start levering it up from the narrow side.

@k4y0z
Excellent work as always!!! :highfive::highfive::highfive::highfive::highfive:
Now, any chance that you can create a fastboot exploit such that there'd be no need to open the case? Same story with Fire TV2 (tank), fastboot exploit?
Keep the good stuff coming!!!

Is this something that Amazon can fix with future updates? I am holding off until we have a more refined rom..

rootuser11 said:
Is this something that Amazon can fix with future updates? I am holding off until we have a more refined rom..
Click to expand...
Click to collapse
No, the only way they can fix it is with a new hardware revision.

Does this permanently install anything? If I reboot after getting into TWRP the first time with fastboot the hacked fastboot splashscreen doesn't come back, it just boots FireOS normally with no options to boot TWRP.

Getting off the heatsink was a bit daunting especially because I didn't know there was also a sticky pad holding it on. Also spent ages trying to short the DAT0 point, got fed up and got it first time with CLK. Now I just need a rom to install!

iLLNiSS said:
Does this permanently install anything? If I reboot after getting into TWRP the first time with fastboot the hacked fastboot splashscreen doesn't come back, it just boots FireOS normally with no options to boot TWRP.
Click to expand...
Click to collapse
Everytime i boot from power off with a OTG it gives the option for TWRP. It installed TWRP recovery. From there you can install root.
Try
ADB reboot recovery

bibikalka said:
@k4y0z
Excellent work as always!!! :highfive::highfive::highfive::highfive::highfive:
Now, any chance that you can create a fastboot exploit such that there'd be no need to open the case? Same story with Fire TV2 (tank), fastboot exploit?
Keep the good stuff coming!!!
Click to expand...
Click to collapse
Unfortunately the fastboot bug cannot be used like that on the 4K or we probably would have done so from the start
I will look into the FireStick 2 when I get the time, but given the fastboot-bug is LK-Version specific and can be easily patched, I am unsure if it's worth the effort.

Michajin said:
Everytime i boot from power off with a OTG it gives the option for TWRP. It installed TWRP recovery. From there you can install root.
Try
ADB reboot recovery
Click to expand...
Click to collapse
I’m guessing I have to actually install TWRP once inside TWRP the first time? I don’t have an OTG cable so never did anything once inside the first time.