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

[Q] XT890's Medfield SoC architecture

(I know this thread maybe should belong to Development forum, but I'm posting here since I don't have enough posts to discuss there yet)
I'm in the second year of Computer Science, being a dynamic/interpreted languages programmer for over 6 years now, C/C++ for 2 years.
I have a solid understanding on the x86 PC architecture: interrupts, buses, etc. I'm pretty good at basic x86 assembly... Been studying UEFI for over a month... Whatever.
I've lost the past couple hours searching but didn't find anything on the architecture of our device. Is the "Bootloader" here compared to a BIOS? Or is it like any PC bootloader (MS-DOS, Windows, Linux bootloaders). Is there anything like a BIOS at all or does the OS, once booted, manages all the hardware interrupts by itself? Can I use INT 10H on XT890? Is it ANYTHING close to the PC architecture?
PCI, ISA, (parallel and serial) "ports" managed by a chipset between the peripherals and the x86 core itself?
Ok, it's x86. Once the system has booted, we can call x86 instructions, ok... But what is under that? Is there any reference on this? How can I boot my own code, if it's not Linux?
I really got nowhere trying to learn about the architecture underneath Android and Motorola's Bootloader on Medfield. Found nothing on Intel nor Motorola websites. What am I doing wrong?
Thanks in advance!

I'm studying this myself but there is a lot that i need to learn. Check those to see if helps.
http://bootloader.wikidot.com/android
http://elinux.org/Android_Booting
http://www.ibm.com/developerworks/linux/library/l-linuxboot/

I would like more info about the RAZR I as well, considering it's the only mainstream phone with a x86 processor I'd expect more documentation about it, I am receiving a RAZR I soon.
For what I know, it's boot process is similar to other Android devices, it loads and decompresses a boot.img file that includes a ramdisk and the kernel, you should be able to load another non-linux OS by chainloading a secondary bootloader there, I honestly would like to see more development on the Razr i, specifically to get native Gnu-linux with x11 running

Using @thiagomtl's links, I was able to understand a little more about the Boot process. XT890 seems to have basically the same mechanics of the ARM ones, but x86 tuned.
However I'm yet to understand the differences between "normal" Linux bootstrapping and the Android Bootloader's one.
On a average legacy Linux box we have GRUB/LILO on the MBR. Making a hell of a simplification here: The user turns the PC on, BIOS does the POST and then loads whatever code is on the MBR. GRUB is a very small program there, which simply loads a driver for the storage device, loads vmlinuz and the f*ing ramdisk on the memory and executes it (effectively by simply pointing the IP to the address where the kernel is on the memory).

Samuelgames said:
I would like more info about the RAZR I as well, considering it's the only mainstream phone with a x86 processor I'd expect more documentation about it, I am receiving a RAZR I soon.
For what I know, it's boot process is similar to other Android devices, it loads and decompresses a boot.img file that includes a ramdisk and the kernel, you should be able to load another non-linux OS by chainloading a secondary bootloader there, I honestly would like to see more development on the Razr i, specifically to get native Gnu-linux with x11 running
Click to expand...
Click to collapse
But the Boot process is just a part of my original question. Ok, a important one, but a part.
What about the structure of the device? How it's all implemented? Is the display using plain old VESA VBE? Are the input devices PS/2? USB? Is the power implemented using ACPI standards? lol

As far as I'm concerned Atom SoC doesn't respect many industry standards for the architecture, even for those who run Windows 8, buttons on the Razr I should be naturally be defined as GPIO as the notification LED, I don't think the display respects VESA standards (SGX 540 can't even do scaling) but it should fallback to them at some extent depending on how you initialize the framebuffer.
All of this should be in the Motorola kernel, I haven't taken a look at it but I'll surely will once I get my phone

@Hazou, @YaPeL, @Omar-Avelar
you guys know anything about this?

Ok this is all i know about it by searching through the code and internet and by finding out myself (no sources included, just my memory). It's all linux, nothing like Windows.
Kernel:
We indeed are making a x86 kernel, but not for normal PC's. We use the mid-x86 implementation within the x86 code of the kernel. (arch/x86/platform/mid-x86) MID is the intel word for all the socs for mobile platforms intel is using. The normal upstream linux doesn't provide all the necessary code. And is has changed with the new android version 4.4.2 for our device.
Boot sequence:
The android devices use some sort of bootloader. Droidboot. Droidboot includes the fastboot commands and starts the bringup of the android system. You can read about it on the internet. In most devices (ARM) it is the first thing thats get called for.
Our intel device is a little different. Before the droidboot gets loaded the firmware of the device loads another OS. Also called POS (i think preprocessor OS, or something). Those gets updated with the dix and efwi(wrong name) files we got. The POS can be accessed by booting in the medfield download through the camera button, if i am correct. The POS then loads the droidboot which will in turn load the rest, like a linux device which loads from the bootloader.
The partition layout can be found in the gpt.bin. It can be flashed through fastboot and can change every partition afaik.
So the boot order is:
1. POS/RADIO
2. DROIDBOOT
3. BOOT.IMG is like linux. First the kernel then the ramdisk with the kernel modules.
4. ANDROID
To comment about the JB implementation.
We can build our own kernel and we can, if we want and take the time, upgrade the kernel to the newest version (for android is that 3.10, but we should be able to manage to go fully upstream 3.17). But that takes a lot of time.
I also noticed that, from what i heard, some kernel modules specific for our device has changed and now the kernel that we have can't load the new firmware files in 4.4. So we will need the next kernel from Moto to compile our own when 4.4.2 is released. Those changed are not upstream.

Hazou said:
The POS then loads the droidboot which will in turn load the rest, like a linux device which loads from the bootloader.
The partition layout can be found in the gpt.bin. It can be flashed through fastboot and can change every partition afaik.
So the boot order is:
1. POS/RADIO
2. DROIDBOOT
3. BOOT.IMG is like linux. First the kernel then the ramdisk with the kernel modules.
4. ANDROID
Click to expand...
Click to collapse
This is the most interesting part for hundreds of us. Is there a way we can find what sectors are used for the pos so we can possibly repair code corrupt?
I have a feeling the gpt is messed up so any amount of writing to the dnx or ifwi will be in the wrong location.
I can't find any information on this phone at all.
I think it's time I bought a spare mobo and dumped everything to compare a broken to working

Flacid Monkey said:
This is the most interesting part for hundreds of us. Is there a way we can find what sectors are used for the pos so we can possibly repair code corrupt?
I have a feeling the gpt is messed up so any amount of writing to the dnx or ifwi will be in the wrong location.
I can't find any information on this phone at all.
I think it's time I bought a spare mobo and dumped everything to compare a broken to working
Click to expand...
Click to collapse
If i am correct they are present on the partition layout of the phone. I just don't know wish ones are the right ones. Never looked good enough at that.
Also to repair the gpt and write the dnx or ofwi to the right location u need a dd command or flash command with the right parameters. The flash command most likely won't work because of the gpt partition and the DD command wont either because most of the time u don't have access to a recovery anymore.
But my knowledge about this is limited, so if u dare to put your phone on the line and have maybe the knowledge and skills to do what some people need, please do I can't and need my phone working

Hazou said:
If i am correct they are present on the partition layout of the phone. I just don't know wish ones are the right ones. Never looked good enough at that.
Also to repair the gpt and write the dnx or ofwi to the right location u need a dd command or flash command with the right parameters. The flash command most likely won't work because of the gpt partition and the DD command wont either because most of the time u don't have access to a recovery anymore.
But my knowledge about this is limited, so if u dare to put your phone on the line and have maybe the knowledge and skills to do what some people need, please do I can't and need my phone working
Click to expand...
Click to collapse
Skills/knowledge = limited. I'm no programmer but I take information in like a 100 petabyte SSD.
My phones knackered, I'm trying to fix it but it's not easy! If it's fixed, I'll break it again to make sure the fix works :good:
It's going to be a long road, there is zero success since the first report of code corrupt.
As you say, I need the right param. There's almost no information about it anywhere and what information is about is very fragmented.
I'll keep you updated

Flacid Monkey said:
Skills/knowledge = limited. I'm no programmer but I take information in like a 100 petabyte SSD.
My phones knackered, I'm trying to fix it but it's not easy! If it's fixed, I'll break it again to make sure the fix works :good:
It's going to be a long road, there is zero success since the first report of code corrupt.
As you say, I need the right param. There's almost no information about it anywhere and what information is about is very fragmented.
I'll keep you updated
Click to expand...
Click to collapse
I am almost certain it can be fixed as long as it is a software failure (some maybe have a hardware failure). As this seems one of them it should be fixable as long as your BL is unlocked. With a locked bootloader u don't stand any chance (nah, maybe with medfield flasher, but that one is also limited).
Take a look at the acer padphone or something. Dunno how it is called exactly. Is also uses the intel SOC and makes use of the medfield flasher.
I never had a phone thats corrupt so can't say much about it, but i can help with thinking my way through. If u have that problem can u boot in fastboot or is that even impossible? I know we can flash the POS and fastboot through xfstk. So with the right combination it should work. And if not we can try flash the modem as extra if that is possible. But do know it can hard-brick the device (modem, lowest thing of the device) of-course, aldo u don't have much choice now
Another thing, because fastboot (and even recovery) can flash the dix, ifwi and bootloader files. I 'assume' xfstk (that can also flash the ifwi, dix and bootloader) can flash the whole emmc with indeed the right parameters. We have the source code of the fastboot/recovery ifwi, dix and bootloader flasher. Also called update_osip.
So think it out, i will wait and see.

uart console
Has somebody tried to access a uart console on our razr-i? would be nice for debugging.
Intels datasheet says the board has 3 uart ports. http://ark.intel.com/products/70097
I hope one uart port can be accessed via usb or audio jack. Like on this device: http://forum.xda-developers.com/showthread.php?t=1081743
Or is it only possible with opening the phone and looking for jtag pins?

[Q] Installing Linux Mint 17 on tf701t?

Hello, recently purchased a asus tf701t laptop/tablet hyrbid and the device itself is perfect. Powerful cpu, good storage and an insane 2k resolution for a 10' inch screen which I don't think has been done before.
However I absolutely hate android (no offense to android developers) and decided to try installing Linux Mint 17 which can be installed on any regular laptop easily. Essentially, I want to get rid of both android bootloader and the OS itself and replace that with Grub bootloader and Linux Mint 17 OS. But android is fighting me every step of the way trying to prevent me from doing just that I unlocked the bootloader so my warrenty is void now.
But beyond that I can't install linux iso because the android bootloader isn't registering the usb stick (with linux iso on it) so I can't launch the linux live iso at all. I tried using cdrom iso using disk to launch through usb and still doesn't come up in the bootloader options. I know its possible to use linux on these devices because I've seen people have done it before on the internet.
I am now at this point starting to consider android itself as malware as the very definition of the word, ....lets start with the fact that they locked the bootloader, prompting me to give ip address just to enable me to unlock the bootloader (malicious and very dodgy). No root access therefore, third party programs are required to enable root which further my belief that android os is more malware than it is a legitimate operating system. Lastly, either possibly no usb driver for bootloader or usb port is locked out by design at bootloader (either way, might explain why I can't use usb linux iso).
What I can't understand is, why google can lock down a device tighter than fort knox on a Asus brand device. This is like buying a brand new car and not being able to open your own car even though you purchased it. What google has done is borderline illegal and I'm abit astonished how they can get away with it...
Sorry for the rant guys I'm abit fustrated atm. Can anyone please help me? I really love linux mint and if its possible to format android and install linux mint on this device I would be eternally grateful

Update: I attempted to flash the device with the command: fastboot -i 0x0B05 flash recovery recovery.img which works...but when I reboot and push power and down volume into bootloader...and try to get into recovery...the screen looks like its about to load into it but then resumes boot of android.
I'm really puzzled by this. So cannot flash a custom recovery for some strange reason

Its not so simple I dont think. You might want to watch whats happening on this thread for now.
http://forum.xda-developers.com/transformer-tf701/general/native-linux-asus-tf701t-t2973119
I would think you would have to completely replace the bootloader with something like uboot maybe if you wanted to wipe the tablet. But I dont think anyone knows. Then you could end up with some permanent brick. There would be no recovery or fastboot option if you were somehow able to get some kind of boot loader on this thing. I have no idea.
Edit: Also there is no arm based Linux Mint afiak.

YayYouFixedIt said:
Its not so simple I dont think. You might want to watch whats happening on this thread for now.
I would think you would have to completely replace the bootloader with something like uboot maybe if you wanted to wipe the tablet. But I dont think anyone knows. Then you could end up with some permanent brick. There would be no recovery or fastboot option if you were somehow able to get some kind of boot loader on this thing. I have no idea.
Edit: Also there is no arm based Linux Mint afiak.
Click to expand...
Click to collapse
Thanks I appreciate the reply. I understand this won't be easy but I'm stubborn that way
Can you give me some advice on where I can start learning how to place a native linux os on the device? Would grub bootloader work with tf701t?

have you considered returning your tf701 and replacing it with the tf700 infinity? you can replace the OS with ubuntu.. theres much more support for that model than the tf701

tf701mega said:
have you considered returning your tf701 and replacing it with the tf700 infinity? you can replace the OS with ubuntu.. theres much more support for that model than the tf701
Click to expand...
Click to collapse
Out of curiosity, have you used the tf700t? it is good for development, but it could run pretty slow at times. It might of been because of the tegra 3 processor, because the tf300t also had this performance issue. I was barely able to type up documents on a CM Rom because the tablet would lag when typing out and would then force close and corrupt my document.
atleast for me, that was the reason why I went with this one rather than the tf700t. This is just my 2 cents about getting the tf700t. I would suggest trying it out before getting it.
Sent from my K00C using Tapatalk 2

Just how stubborn are you?
How much work do you want to put into this? There are two options, the easy route that you probably will consider imperfect, and the much more complicated route that I'm not certain will work. I'll do my best to explain both.
The method I use is to install a linux distro (in my case, ubuntu) inside a chroot. There are several apps on the android market to help you set this up. The one I used sets up an Xvnc server, so you can view your linux desktop by using an android VNC viewer -- but it's just connecting locally, not going over the network.
This works nicely out of the box, but it's slow, partly because it's using the VNC protocol and partly because there's no 2d hardware acceleration. I tinkered with my setup and installed XSDL, a native android X server with hardware acceleration. I had to modify the linux startup script to skip starting Xvnc and instead connect to XSDL (which is on :0.0 like a normal X server).
This works great and is fairly fast. For me, this is a good compromise between a full-fledged linux laptop and the convenience of android apps written specifically for a multitouch screen. I generally do most of my stuff in Android, but I can drop into my Ubuntu desktop whenever I need more power.
The really big downside is that it's hard to prevent Android's low-memory killer from sacrificing XSDL when I haven't used it for awhile. I've mucked about with various solutions involving oom_score_adj and such, and that helps, but android still ends up killing my X server sometimes.
So, that's the easy method. For the more complicated method, I'm just theorizing, and this stuff may not work. You're going to need to either already have somewhat deep linux knowledge or be willing to learn Here goes.
In this post, I described how I managed to boot my tf701t after the internal memory card died a horrible death. The important bit here is that I learned how to boot any initrd/kernel combination using fastboot, and how to roll that combination into a boot.img so that the tablet always boots it. This is what you'll need to do both for the installation and for future boots into your Linux install.
First off, choose your Linux distro. I don't think you'll be able to use Mint, since, as someone pointed out above, there's no ARM build of Mint. However, there is an ARM build of Debian and Mint has the "debian edition", so maybe there is an ARM version. It may be, though, that the Mint folks only built their special stuff (Cinnamon/mate/whatever) for x86 platforms. I'd recommend Ubuntu as a compromise since I know it runs on the tf701t.
For the initial installation, put the contents of the install ISO onto an SD card -- just copying your bootable USB drive over should work. Now for the tricky bit: you'll need to pull the kernel and initrd ("ramdisk", "initial ramdisk" -- usually initrd-<something>.gz) off of the usb drive and into a working directory on a Linux laptop or desktop (let's call it the "host"). You might get away with just fastbooting this kernel/ramdisk directly. Install the fastboot package for your distro (Ubuntu has one, anyway). Connect up your tablet, put it in fastboot mode (I think that's done by booting with volume up and down held) and do 'fastboot boot <your kernel> <your ramdisk>'.
This will boot the kernel and load up the initrd, which is a tiny little linux filesystem stored in memory. The kernel runs a program called init inside the ramdisk and init takes over and boots into the actual installer. The question in my mind is how it goes about finding the ISO contents. If it searches by filesystem UUID, and there's a good chance that it does, then it will find your the ISO contents on the SD card just fine and the installer will start up.
If not, well, things will get a lot more complicated. Normally what one would do in a case like this would be to pass kernel command-line arguments (you do this in the SYSLINUX bootloader for distros like Ubuntu) telling it where to find the installation media. We can't do that because fastboot doesn't let you pass command-line arguments. Instead, you'd need to extract the initrd on the Host machine, modify the init script in some way to tell it where to find the installation media (probably /dev/block/mmcblk1p1), and then repackage it. I went into somewhat shallow detail on how to do the extract/repackage parts of this, but this is where either prior linux knowledge or a willingness to do some research comes in. Hints: gunzip the initrd, then use the cpio tool to extract it.
Okay, so let's say that you get the installer booting. The next big question is whether it's going to work at all. In theory the graphics chip inside the tf701t is supported by linux, but in practice, maybe it's only supported by a kernel module that Samsung built. Maybe you'd need to substitute the stock kernel. The next question is whether X has a module that will work with the graphics chip. But maybe even if it doesn't you can use a text-mode installer. That would at least let you get a system installed that you could then hack on to try to get X running.
So, let's say you do get linux installed (probably onto the internal SD card, /dev/block/mmcblk0). Now you want to boot it. You'll need to look into the installed system and steal its kernel and ramdisk, and get them onto the Host machine. Or maybe you could just extract them from the debian packages, since I'm not sure how you'd get things off of that internal SD at this stage. As a hint, these may well NOT be the same kernel/initrd as in the installer.
Once you've got the kernel/ramdisk, you can try to boot into them with fastboot. If that works (big if), then you'll want to be able to boot them without fastboot. That's where the 'fastboot flash:raw' command comes in. It takes a kernel/ramdisk, builds an android boot.img out of them, and flashes it to the device. From then on, the device will boot that kernel and ramdisk by default.
So, in theory this could work. The biggest potential stumbling block is whether X is going to natively support the graphics chip. If it doesn't, you may be stuck using the basic framebuffer driver, or maybe that won't even work at all. ...or you could just settle for the chroot method and be done with it
Good luck. I'm very interested to hear whether this works. I'm probably not going to try it myself since I like Android enough that I want to keep it around. I also can't walk you through this in finer detail because of external limits on my time, but I'd be happy to answer theoretical questions and specific technical questions, so long as you're willing to do the legwork of reading manpages and such I hope this works out for you!
Oh, one thing just occurred to me: skip the part in the installer about installing grub. It's not going to work on this device and may cause problems. You'll take care of the bootloader part yourself with the fastboot flash:raw command.

Oh, I see there's already some decent progress in this thread. Also it looks like I totally missed the -c option in fastboot that lets you pass kernel command-line arguments... that'll definitely be a time-saver. Given what I see over in that thread, it looks like we may actually get a reasonable native linux on our TF701t. Not sure how far the OP has gotten on things like mouse/keyboard input, though.
I have to say, I'm pretty excited! It'd be super cool to be able to dual-boot native linux and android on this tablet. Best of both worlds.

lexelby said:
How much work do you want to put into this? There are two options, the easy route that you probably will consider imperfect, and the much more complicated route that I'm not certain will work. I'll do my best to explain both.
The method I use is to install a linux distro (in my case, ubuntu) inside a chroot. There are several apps on the android market to help you set this up. The one I used sets up an Xvnc server, so you can view your linux desktop by using an android VNC viewer -- but it's just connecting locally, not going over the network.
This works nicely out of the box, but it's slow, partly because it's using the VNC protocol and partly because there's no 2d hardware acceleration. I tinkered with my setup and installed XSDL, a native android X server with hardware acceleration. I had to modify the linux startup script to skip starting Xvnc and instead connect to XSDL (which is on :0.0 like a normal X server).
This works great and is fairly fast. For me, this is a good compromise between a full-fledged linux laptop and the convenience of android apps written specifically for a multitouch screen. I generally do most of my stuff in Android, but I can drop into my Ubuntu desktop whenever I need more power.
The really big downside is that it's hard to prevent Android's low-memory killer from sacrificing XSDL when I haven't used it for awhile. I've mucked about with various solutions involving oom_score_adj and such, and that helps, but android still ends up killing my X server sometimes.
So, that's the easy method. For the more complicated method, I'm just theorizing, and this stuff may not work. You're going to need to either already have somewhat deep linux knowledge or be willing to learn Here goes.
In this post, I described how I managed to boot my tf701t after the internal memory card died a horrible death. The important bit here is that I learned how to boot any initrd/kernel combination using fastboot, and how to roll that combination into a boot.img so that the tablet always boots it. This is what you'll need to do both for the installation and for future boots into your Linux install.
First off, choose your Linux distro. I don't think you'll be able to use Mint, since, as someone pointed out above, there's no ARM build of Mint. However, there is an ARM build of Debian and Mint has the "debian edition", so maybe there is an ARM version. It may be, though, that the Mint folks only built their special stuff (Cinnamon/mate/whatever) for x86 platforms. I'd recommend Ubuntu as a compromise since I know it runs on the tf701t.
For the initial installation, put the contents of the install ISO onto an SD card -- just copying your bootable USB drive over should work. Now for the tricky bit: you'll need to pull the kernel and initrd ("ramdisk", "initial ramdisk" -- usually initrd-<something>.gz) off of the usb drive and into a working directory on a Linux laptop or desktop (let's call it the "host"). You might get away with just fastbooting this kernel/ramdisk directly. Install the fastboot package for your distro (Ubuntu has one, anyway). Connect up your tablet, put it in fastboot mode (I think that's done by booting with volume up and down held) and do 'fastboot boot <your kernel> <your ramdisk>'.
This will boot the kernel and load up the initrd, which is a tiny little linux filesystem stored in memory. The kernel runs a program called init inside the ramdisk and init takes over and boots into the actual installer. The question in my mind is how it goes about finding the ISO contents. If it searches by filesystem UUID, and there's a good chance that it does, then it will find your the ISO contents on the SD card just fine and the installer will start up.
If not, well, things will get a lot more complicated. Normally what one would do in a case like this would be to pass kernel command-line arguments (you do this in the SYSLINUX bootloader for distros like Ubuntu) telling it where to find the installation media. We can't do that because fastboot doesn't let you pass command-line arguments. Instead, you'd need to extract the initrd on the Host machine, modify the init script in some way to tell it where to find the installation media (probably /dev/block/mmcblk1p1), and then repackage it. I went into somewhat shallow detail on how to do the extract/repackage parts of this, but this is where either prior linux knowledge or a willingness to do some research comes in. Hints: gunzip the initrd, then use the cpio tool to extract it.
Okay, so let's say that you get the installer booting. The next big question is whether it's going to work at all. In theory the graphics chip inside the tf701t is supported by linux, but in practice, maybe it's only supported by a kernel module that Samsung built. Maybe you'd need to substitute the stock kernel. The next question is whether X has a module that will work with the graphics chip. But maybe even if it doesn't you can use a text-mode installer. That would at least let you get a system installed that you could then hack on to try to get X running.
So, let's say you do get linux installed (probably onto the internal SD card, /dev/block/mmcblk0). Now you want to boot it. You'll need to look into the installed system and steal its kernel and ramdisk, and get them onto the Host machine. Or maybe you could just extract them from the debian packages, since I'm not sure how you'd get things off of that internal SD at this stage. As a hint, these may well NOT be the same kernel/initrd as in the installer.
Once you've got the kernel/ramdisk, you can try to boot into them with fastboot. If that works (big if), then you'll want to be able to boot them without fastboot. That's where the 'fastboot flash:raw' command comes in. It takes a kernel/ramdisk, builds an android boot.img out of them, and flashes it to the device. From then on, the device will boot that kernel and ramdisk by default.
So, in theory this could work. The biggest potential stumbling block is whether X is going to natively support the graphics chip. If it doesn't, you may be stuck using the basic framebuffer driver, or maybe that won't even work at all. ...or you could just settle for the chroot method and be done with it
Good luck. I'm very interested to hear whether this works. I'm probably not going to try it myself since I like Android enough that I want to keep it around. I also can't walk you through this in finer detail because of external limits on my time, but I'd be happy to answer theoretical questions and specific technical questions, so long as you're willing to do the legwork of reading manpages and such I hope this works out for you!
Oh, one thing just occurred to me: skip the part in the installer about installing grub. It's not going to work on this device and may cause problems. You'll take care of the bootloader part yourself with the fastboot flash:raw command.
Click to expand...
Click to collapse
Very stubborn
Sorry I didn't respond sooner as I was away with family for Christmas.
Thank you for the guide, it was extremely helpful. I am still working on getting the device ready so I'll update as I progress.
Thanks again

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..

[UNLOCK][ROOT][TWRP][UNBRICK][...] FireTV 2nd gen Cube (raven) > PS7242

{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Raven Boot v2.0 now includes persistent root. A huge thank you to @Functioner for getting it working! This package includes unrestricted U-Boot, fastboot & Amlogic burn mode commands, as well as TWRP and Magisk support. The Raven boot tool includes options to root your Cube, gain temporary root access without modifying your device, and a number of options for recovery and backup.
NOTE: FireOS < 7.2.7.3 required
A newer method is available that works up to PS7292, that doesn't use DFU or a DFU device, but has no DFU recovery options
NOTE: This process does not require you to open your Fire TV 2nd gen Cube
Changelog:
v2.2 April 7th, 2023​
Minor update to Magisk 25.208
Hopping back on official signed Magisk app line
v2.0 and v2.1 use an unofficial Magisk build that will result in a signature mismatch when updating.
If you are using Raven root v2.0/2.1, delete the file /data/adb/magisk.db on your Cube,
before updating to Raven root v2.2.
Added USB booting for flash drives that use aml_autoscripts, for future development.
​v2.1 February 18th, 2023​
Updated TWRP v3.6.1-9-0 ---> v3.7.0-9.0
Fixed problem with TWRP not always displaying all the partitions under 'Mount/Backup'
Always mounts 'Internal Storage' to /sdcard now
Fixed bash menu to always use the included fastboot binary
Cube's physical buttons can be used on bootup
Volume Up ---> Fastboot
Volume Down ---> TWRP recovery
Action button ---> Amlogic Update
**Hold down button for ~5sec after power-on, and before the blue LEDs / 1st Amazon logo​​v2.0 February 9th, 2023​
Root is now persistent, does not require computer after every reboot
One click option to install root access, TWRP, Magisk & OTA blocker module
Magisk updates
Zygisk is working (July 1st, 2022)
Magisk can be installed from TWRP or direct installed from within Magisk Manager
Created module to block Amazon OTA updates via etc/hosts and hiding the OTA apk
updated quick access images to Magisk v25.2
TWRP updates
Bootloader flashing is blocked, so that full OTA firmware bins can be easily flashed (tested up to PS7624/3337)
Removed firmware downgrade checks & warnings
Added NTFS support for flash drives within TWRP
Added options to backup entire reserved partition, and mmcblk0boot0 & mmcblk0boot1 boot partitions in Amlogic update
Added emergency boot to Fastboot/Update modes
v1.0 May 15th, 2022​
Temporary unrestricted fastboot, u-boot & update commands
Boot with root access or Magisk support
Boot to TWRP for backup & recovery
Backup Cube using Amlogic Update
What's needed:
linux installation or live-system (Ubuntu 20.04.x recommended)
micro-USB cable
device to put Cube into device firmware upgrade (DFU) mode [read below]
libusb is needed for your linux installation to detect the Cube over USB.
sudo apt-get install libusb-1.0-0
To automatically set the proper udev rules for Amlogic install Khadas utils:
sudo apt-get install libusb-dev git
sudo apt-get install git
git clone https://github.com/khadas/utils
cd utils
./INSTALL
***NOTE: If you previously installed Magisk on your Cube from raven_boot v1.0, first run adb shell rm /data/adb/magisk.db to prevent any conflicts with the new Magisk version.
Instructions
Download the latest raven_boot.zip and unzip it. Open a terminal window from the unzipped raven_boot directory
Power off the Cube and connect your DFU device to the Cube's HDMI port. Connect the USB cable (microUSB to USB-type A) to computer & Cube
Power on the Cube, type lsusb in the terminal to confirm ID 1b8e:c003 Amlogic, Inc. is present, indicating the Cube is in DFU mode
Unplug the DFU device from the HDMI port, reconnect the Cube to TV with HDMI cord. Keep the computer connected.
In the terminal type bash menu, and choose option 1) to automatically root the Cube.
To preserve the Cube's persistent root, be sure to confirm that both TWRP & Magisk are installed.
Quick Access
For options 2) and 3) to gain temporary root, download the images zip file that corresponds to your current FireOS version, and unzip the contents into raven_boot/images directory.​For Cubes running FireOS 7242/2896 or later get ---> images_7242-2906_v2.0.zip​For FireOS versions 7201/942 to 7242/2216 get ---> images_7229-1853_v2.0.zip​
Magisk v25.206 is included with Raven boot, it's recommened that you use this version or newer. For instructions on how to update your firmware and keep root access, read here
About the exploit
This exploit is based on a vulnerability in the Amlogic bootrom that allows for us to run unsigned code in the next boot stage (Bl2). To pause the automatic boot up process, before the Cube's saved Bl2 is loaded, we rely on Amlogic's device firmware upgrade mode (DFU). In DFU, only the boot code from the Amlogic s922x SOC (Bl1) has been loaded into memory. We then use the vulnerability to load our modified Bl2, breaking the 'chain of trust', and disabling secure boot so that we can make modifications to the bootloader downstream. The last stage of the bootloader is U-boot (Bl33) which hands off the startup process to the kernel (boot.img). U-boot is modified to unlock any restrictions on u-boot and fastboot commands, giving us full access to system features. We can then use fastboot boot to load our modified boot images (TWRP, magisk-patched boot.img), into memory without modifying the Cube's eMMC.
Visit GitHub for a more in depth write-up and resources used in this project
Contributors
@Functioner
@Zenofex
@npjohnson
@zeewox
@Pro-me3us
Additional thanks to
@tchebb - a bottomless encyclopedia of Amlogic knowledge, answering countless questions & troubleshooting
@roligov - providing photos, additional FireOS updates, and testing
@osm0sis, @canyie, @vvb2060 & @yujincheng08 - the Magisk team for being awesome, troubleshooting and making a number of code changes to get all features working on the Cube
@k4y0z - helping troubleshoot some TWRP and Magisk issues

Entering the Cube's DFU mode
To boot into device firmware upgrade (DFU) mode we need to pass a '[email protected]' command, to the Cube's Amlogic s922x SOC, through the I2C bus accessible via the HDMI port. This was first described in the FireFU exploit for the 1st gen Cube. Since then there are a few more options for devices to accomplish this:
DIY modified dummy HDMI dongle. Fully self-contained, and powered by the HDMI port. Simple to use, just plug-in and unplug, can be made for $5 or less and is what I recommend.
https://github.com/superna9999/linux/wiki/Amlogic-HDMI-Boot-Dongle
I2C emulator for ATmega boards (Arduino Duemilanove, ATmega48/88/168/328). Requires less skill, potentially little to no soldering. A Tiny88 ($2-3) wired to an HDMI breakout board ($2-3) can be programmed over USB with one command.
https://github.com/tchebb/amlogic-hdmiboot-avr
Arduino sketch to boot into DFU, compatible with ARM-based Arduino boards (Due, Teensy, Genuino). Costs more but a good alternative if you already have an Arduino board.
https://www.exploitee.rs/index.php/FireFU_Exploit#Preparing_HDMI_dongle

Flashing OTA Firmware with TWRP
To upgrade the firmware past PS7273+ and keep the Cube unlocked and rooted, we need to avoid flashing any bootloader version newer than PS7242/3516. The new build of TWRP included with Raven boot v2.0+ and Raven root shrinker automatically blocks any bootloader flashing. Be sure that you are using Raven boot v2.0 or newer! Firmware bin flashing is working and tested up to PS7633/3445.
The shrinker script only works up to PS7624/3337, upgrading past this version will still maintain root, but will lose the shrinker backdoor backup.
Update Procedure:
1) Download the full firmware bin (XDA or Github), change extention .bin to .zip
2) In ADB type reboot recovery to enter TWRP. You can also open Magisk Manager and choose the reboot to recovery option in the top right corner of the main screen.
3) Copy the firmware file to your Cube via USB connected computer, flash it, and re-flash Magisk
Code:
adb push <firmware-filename.zip> /sdcard/Download/
adb shell
twrp install /sdcard/Download/<firmware-filename.zip>
twrp install /sdcard/Download/magisk.apk
If you used the shrinker method, then the magisk apk is in /data/local/tmp/ instead
Code:
twrp install /data/local/tmp/magisk.apk
If you prefer to use a USB mouse and regular TWRP interface, rather than computer, download the firmware bin directly to the Cube in FireOS. Firmware updates don't require wiping data/dalvik. If downgrading firmware, wiping data/dalvik is advisable.
NOTE: It's IMPORTANT to not forget to flash magisk.apk after each firmware upgrade. Magisk & TWRP work together to preserve root access. Magisk prevents TWRP from being deleted, and TWRP helps to prevent accidental Amazon OTA updates. Without Magisk, OTA updates will no longer be blocked by the OTA blocker Magisk module.
Protected Packages
Amazon added package protection in +PS7273. To remove this, boot into FireOS with Magisk or root support, edit /data/system/PackageManagerDenyList, delete the list of applications, and save.
To prevent the protected applications list from being regenerated on reboot, disable:
Code:
adb shell pm disable-user com.fireos.arcus.proxy
All applications can now be disabled/enabled without root, including custom launchers.

reserved

Thanks for this! So far I've only confirmed old enough firmware (PS7229/1856) and installed a uart header. Seems I will have to wait a while to get a working hdmi plug for dfu access.
While looking at the uart log, I noticed that u-boot is interruptible prior to boot, which is a little unusual. But every u-boot command is disabled, even "help"!
I noticed some text about a one time override code of some sort. Did you find any additional information about this code while working on the bootloader?
Would it not be possible to just flash a patched bootloader, much like is described at the site you've referenced? Is the stock bootloader encrypted? If so, were the relevant keys extracted?
What about ≥ 7.2.7.3 kills this exploit? Is dfu access lost? If not, what else prevents it from working? I wouldn't think that dfu could be lost, since it is in rom, unless an efuse can disable it?

goapy said:
While looking at the uart log, I noticed that u-boot is interruptible prior to boot, which is a little unusual. But every u-boot command is disabled, even "help"!
I noticed some text about a one time override code of some sort. Did you find any additional information about this code while working on the bootloader?
Click to expand...
Click to collapse
On the stock bootloader Amazon has blacklisted all uboot commands. The bootloader code is available through Amazon's open source repository. The uboot console restrictions are in:
platform/bootable/bootloader/uboot-amlogic/s922x/bl33/common/amzn_lockdown.c
The unlock codes are generated by Amazon's servers in combination with the devices' serial number. This system is the same as other fire devices. There is a list of all the uboot commands in the documents folder of raven_boot.zip to give you an idea of what's available.
To work with the U-boot console, you can also send uboot console commands via Amlogic burn-mode for convenience.
Code:
./update bulkcmd "uboot command"
Unfortunately, i don't think there is a way to route the uboot console output over HDMI or USB, so TX is still necessary for visualization. Your soldering work and connector look a lot nicer than what I was working with, I'm jealous
goapy said:
Would it not be possible to just flash a patched bootloader? Is the stock bootloader encrypted? If so, were the relevant keys extracted?
Click to expand...
Click to collapse
The bootloader is signed, and verified by the bootrom. This is part of the 'chain of trust' that ensures the bootloader is not altered / tampered with. The reason the patched bootloader in the OP can be loaded is because we are using a tethered computer to run a bootrom exploit program (amlogic-usbdl) to inject our own next stage code (bl2.bin) that bypasses the bootrom verification process. The modified Bl2 code allows for the rest of the bootloader to load. Without a computer to run the exploit, our Bl2 code would fail verification, and the Cube would hang.
The bootloader is encrypted with several keys, and the keys change with major releases. I don't know what XDA's policy is on posting keys, so I don't want to chance a violation. A more detailed description of the whole process will be added to github relatively soon.
goapy said:
What about ≥ 7.2.7.3 kills this exploit? Is dfu access lost? If not, what else prevents it from working? I wouldn't think that dfu could be lost, since it is in rom, unless an efuse can disable it?
Click to expand...
Click to collapse
@roligov said he was not able to enter into DFU with USB after 7.2.7.3. There was an option added to the efuse file last year to disable DFU from USB, my guess is Amazon chose to burn the fuse(s) in 7.2.7.3.
EDIT: If you plan to be do a lot of probing, I'd recommend going with Superna9999's HDMI dongle design, it's a lot more convenient than the Arduino boards.

goapy said:
What about ≥ 7.2.7.3 kills this exploit? Is dfu access lost? If not, what else prevents it from working? I wouldn't think that dfu could be lost, since it is in rom, unless an efuse can disable it?
Click to expand...
Click to collapse
Pro-me3us said:
@roligov said he was not able to enter into DFU with USB after 7.2.7.3. There was an option added to the efuse file last year to disable DFU from USB, my guess is Amazon chose to burn the fuse(s) in 7.2.7.3.
Click to expand...
Click to collapse
Exactly that. I had a unit that worked fine, tested DFU mode before applying update Fire OS 7.2.7.3 (PS7273/2625). After updating to that firmware version, DFU mode no longer worked. Exact same setup worked 5 minutes before and still works on other cubes. If no one on here confirms it no longer works on the latest firmware, I may sacrifice another cube and update to the latest. I thought it wasn't possible either since it's a bootrom exploit, but guessing an efuse has been burnt.
It may be possible to probe the board and achieve DFU mode by someone who knows what they doing like the method used for the Fire Sticks (I tried with 1 cube which ended up in a bootloop, luckily Amazon replaced it).

Pro-me3us said:
The bootloader is signed, and verified by the bootrom. This is part of the 'chain of trust' that ensures the bootloader is not altered / tampered with.
The bootloader is encrypted with several keys, and the keys change with major releases.
Click to expand...
Click to collapse
Whatever bootloader keys are used for the chain of trust in order to ensure an internally consistent hand-off from stage to stage are distinct from the most external bootrom key that is used to encrypt the entire bootloader partition image from start to finish, right? That most "external layer" bootrom key, that is used to encrypt the entire bootloader partition image, must remain the same for the life of all instances of the hardware, at least if all similar devices are to be able to run firmware updates, right?
By the "most external layer" of encryption, I mean this layer;
If a device that is configured for secure boot, as distinguished from a device that is not configured for secure boot, like the khadas VIM3L (but still has a bootloader partition that is at least encrypted with the most external layer key), could it not run a different bootloader (that was internally consistent and unmodified), so long as that bootloader was encrypted with a matching most external layer key? Does secure boot prevent this?
For example, if an entire bootloader was taken intact from a generic 922 device, and that entire bootloader was not internally modified at all (but happened to have a functioning u-boot bl33 layer), and that entire bootloader (after itself being decrypted with its most external layer bootrom key, if necessary) was encrypted with the most external layer key matching the v2 cube, would that bootloader not boot all the way to bl33 and beyond on the v2 cube?
Perhaps an internally consistent alternative bootloader, even if if properly encrypted with the most external layer bootroom key, would still break the chain of trust because the portion of the bootloader that is in rom (bl1) is not just generic bootloader code common to many devices, but is customized specifically for that particular secure boot device (or references a root of trust elsewhere in the rom that is individualized), so the subsequent bootloader stages would fail trust because of that individualization that is in, or referenced by, bl1, even if they were entirely unmodified?
Perhaps this bootloader might boot but avb or vbmeta verification might fail in some other way, or whatever drm magic is in the bootloader might be absent, but would it not at least boot, or does secure boot prevent any internally consistent alternative bootloader from booting, even if it is encrypted with the correct most external layer key, matching the bootrom key?
I apologize if I'm missing something obvious because of my impoverished understanding of this process.

roligov said:
Exactly that. I had a unit that worked fine, tested DFU mode before applying update Fire OS 7.2.7.3 (PS7273/2625). After updating to that firmware version, DFU mode no longer worked. Exact same setup worked 5 minutes before and still works on other cubes. If no one on here confirms it no longer works on the latest firmware, I may sacrifice another cube and update to the latest. I thought it wasn't possible either since it's a bootrom exploit, but guessing an efuse has been burnt.
Click to expand...
Click to collapse
Do you have any guesses about how the efuse is burnt by the updated system? Might the new bootloader itself do it, or the running system, or is there anything obvious in updater-script (if amazon ota's use an updater-script)?

It seems that all of the quickly obtainable edid-spoofing hdmi plugs come with an eeprom in the sot23 package, lacking the a0, a1, and a2 pins needed for the addressing change. Does anyone know of a hdmi plug that uses an 8-lead eeprom that can be ordered for quick delivery?
Otherwise I'll modify the sot23 version that I have coming tomorrow, replacing the sot23 at24cs02 with an 8-lead version that I can pull from some waste board.

goapy said:
Do you have any guesses about how the efuse is burnt by the updated system? Might the new bootloader itself do it, or the running system, or is there anything obvious in updater-script (if amazon ota's use an updater-script)?
Click to expand...
Click to collapse
At power on Amlogic devices will print a string of SOC information that starts with G12B:BL....
in that string is F2FB39B0:432060. The 2 values report the security efuse status for the device. 32bit values:
CFG9: 0x00432060
CFG10: 0xF2FB39B0
Following 7273/2625 there is a 1 bit change in CFG10
CFG10: 0xF2FB39B0 (pre 7273) = 1111 0010 1111 1011 0011 1001 1011 0000
CFG10: 0xF2F339B0 (post 7273) = 1111 0010 1111 0011 0011 1001 1011 0000
Bits are read from right to left starting with bit 0, so Flag 19 flips from 1 to 0. The security efuse table shows that an efuse was buned to disable 'IS_FEAT_USB_BOOT_ENABLE', barring DFU entry via USB.
There is little documentation on how to burn efuses, more importantly I don't know of any public information on the efuse addresses that correspond to which features. Burning efuses would have to be done through uboot and the Bl31api which is how non-secure world talks to secure world. Amazon may handle it through cmd_efuse.c, since there was an addition to that code made to disable USB boot in 2021. The following can be found in the 2nd gen Cube package from Amazon's open source page
platform/bootable/bootloader/uboot-amlogic/s922x/bl33/common/cmd_efuse.c
goapy said:
Whatever bootloader keys are used for the chain of trust in order to ensure an internally consistent hand-off from BL stage to BL stage are distinct from the most external bootrom key that is used to encrypt the entire bootloader partition image from start to finish, right? That most "external layer" bootrom key, that is used to encrypt the entire bootloader partition image, must remain the same for the life of all instances of the hardware, at least if all similar devices are to be able to run firmware updates, right?
Click to expand...
Click to collapse
There are several layers of security, including encryption and signed code. The s922x contains an AES key which is static, and it can be used to decrypt the bootloader. The Cube has boot decrypt enabled, meaning that it is expecting Bl2 to be encrypted, and it will decrypt anything passed to it with the internal AES key. Amazon takes things a step further and encrypts the later bootloader stages with 3 more AES keys. So to fully decrypt the bootloader there are 4 total keys, one of which is static.
But in the case of the Cube, decryption is not an issue since we can dig to get all the keys. The keys just allow the SOC to unscramble the image. There is also signing which involves image hashes. By modifying the image, the hash changes, failing the signature check. The function of the amlogic-usbdl exploit is to bypass the code verification, not encryption.
The Bl2 signing tool is public but Bl2 is not open source. I don't know how functional the Bl2.bin is that is included in the firetv open source repository. There's likely also other security checks I'm overlooking.
goapy said:
For example, if an entire bootloader was taken intact from a generic 922 device, and that entire bootloader was not internally modified at all (but happened to have a functioning u-boot bl33 layer), and that entire bootloader (after itself being decrypted with its most external layer bootrom key, if necessary) was encrypted with the most external layer key matching the v2 cube, would that bootloader not boot all the way to bl33 and beyond on the v2 cube?
Click to expand...
Click to collapse
If it was from a generic device without any security features implemented in the bootloader maybe? The Cube has a root key burned to it that I assume is specific to the 2nd gen Cube. I believe this is used in verifying bl2.
There would be hardware/board differences that would lead to a host of issues as well. Uboot would be missing the FireOS layer, so I would be surprised if it could hand things off properly. Bl2 would still have to be encrypted using the AES key, since the Cube has boot encrypt enabled, which is doable.
That could be tested with Amlogic's update tool in DFU.
Code:
./update write bl2.bin 0xfffa0000 //loads bl2 into memory at the run address
./update run 0xfffa0000 //executes bl2 from memroy
./update bl2_boot bootloader.img //loads and runs the rest of the bootloader into and from memory
The closest thing to Khasdas' VIM3L for the s922x is the Odroid N2/+, in terms of a developer's board with little to no security features implemented. The unsigned Cube bootloader will load fairly far on the N2+, but I don't remember if it got as far as the kernel. I never tried the reverse, loading an N2+ bootloader on the Cube.

goapy said:
Otherwise I'll modify the sot23 version that I have coming tomorrow, replacing the sot23 at24cs02 with an 8-lead version that I can pull from some waste board.
Click to expand...
Click to collapse
I did ^this^ because the 8-lead version that I ordered still hasn't arrived yet. See before/after images below. It was a success and I was able to get the exploit running.
While swapping out the eeprom, I noticed that the ddc (display data channel) pair of lines was terminated in the plug, even though this edid emulator device supports passthrough. The ddc pair carries at least two kinds of data, edid and hdcp.
Presumably ddc is terminated because otherwise there would be a serial wire device conflict on the i2c bus at address 0x50, since both the edid emulator device and the sink would each have a eeprom (or prom) at that address.
But since for dfu usage the address is changed to 0x52, I figured the ddc lines could be reconnected and the 0x52 serial device could just ride on a passthrough i2c bus. So, I wired the sda and scl lines as passthrough lines.
I hoped that this would mean that I could repeatedly use the exploit over time without swapping hdmi connections for every reboot. And it does do that. But it also takes a power cycle in order boot to dfu mode from an actively running OS. Booting any of the other images, such as fastboot, twrp, etc., do not require a power cycle and reboot straight to dfu mode with the passthrough device installed.
So, it is still more convenient to just cycle power rather than swap hdmi plugs.
As far as testing the exploit itself, I've only spent an hour so far. The included magisk patched boot image does work, although when I tried to boot a magisk patched boot image that I patched myself (using the original image on the device as a source), it did not boot. All of the provided boot images do work, and are all very useful.

goapy said:
I hoped that this would mean that I could repeatedly use the exploit over time without swapping hdmi connections for every reboot. And it does do that. But it also takes a power cycle in order boot to dfu mode from an actively running OS. Booting any of the other images, such as fastboot, twrp, etc., do not require a power cycle and reboot straight to dfu mode with the passthrough device installed.
Click to expand...
Click to collapse
That's a very nice improvement over Superna9999's design, you should share this with him I did start to strip the plating on my HDMI cable from all the plugging/unplugging during testing. With this design, does the Cube end up powering two ICs, the one on the dongle and the one in the TV HDMI port? Are there any issues having the Cube power both?
Even with the original design, I think a power cycle is required to get into DFU, rather that just a reboot. I remember adb rebooting would cause the Cube to keep resetting until a power cycle or the dongle was removed. It may be that there is a bootrom level 'reboot reason' stored in volatile memory, that's not cleared until power cycling? If you send a reboot command from u-boot / burn mode are you put in DFU, or do you still need to power cycle? I briefly looked for a command to reboot into DFU (without I2C), but couldn't find anything.
goapy said:
The included magisk patched boot image does work, although when I tried to boot a magisk patched boot image that I patched myself (using the original image on the device as a source), it did not boot.
Click to expand...
Click to collapse
You'll need to use a canary build of Magisk to make your own patched boot.img. There is an Amlogic quirk that probably affects many slot A only devices. Amlogic uses the suffix 'normal' rather than '_a', which is not recognized by Magisk. A patch was added to ignore the suffix in canary build ~24.310.
When patching the boot.img with Magisk, choose recovery mode and leave vbmeta unchecked. Using the regular boot mode (not recovery mode), results in a mount/unmount loop during bootup. The cause of this will have to be worked out long-term for a persistent root. Right now SU works for Magisk but Zygisk doesn't. I'm not sure if that is a limitation of loading Magisk with fastboot boot, or because recovery mode is being used to create the patch.
You will also want to enable UART output from the kernel. This will be applied to your Cube automatically by choosing bash menu 1) boot to FireOS with ADB root / permissive. You can do it manually by booting to fastboot
Code:
fastboot oem flags fos: 0x4
The flags are stored in IDME and can also be changed directly there
Code:
fastboot oem IDME fos_flags 0x4
The IDME values will persist without the exploit, but values like
ADB root and DM-verity off will be ignored/rejected by the native bootloader when uboot determines the Cube is not an engineering device (defined as ARB=0). But the console enable value will be accepted, letting you see native FireOS uart output.
EDIT: I added the 31 IDME properties that can be edited

Pro-me3us said:
With this design, does the Cube end up powering two ICs, the one on the dongle and the one in the TV HDMI port? Are there any issues having the Cube power both?
Click to expand...
Click to collapse
I don't think current draw is a problem. A 24c02 eeprom draws 1 mA max when reading, and 5 μA max when in standby. Even if both eeproms on the bus were read at the same, that would not be a lot of current. There is only one read operation of each serial device per power cycle.
Consider another edid emulator with passthrough, the gofanco prophecy. The gofanco emulator has not only two onboard 24c02 eeproms, but also a 3AQ20 MCU and a hc4052 mux/demux IC, all powered by the hdmi port.
Pro-me3us said:
You'll need to use a canary build of Magisk to make your own patched boot.img. There is an Amlogic quirk that probably affects many slot A only devices. Amlogic uses the suffix 'normal' rather than '_a', which is not recognized by Magisk. A patch was added to ignore the suffix in canary build ~24.310.
Click to expand...
Click to collapse
Thanks. I didn't realize that 24.310 was used on the supplied image or that a recovery style patch was required. Now it all works.
Pro-me3us said:
The flags are stored in IDME and can also be changed directly there
Code:
fastboot oem IDME fos_flags 0x4
The IDME values will persist without the exploit, but values like
ADB root and DM-verity off will be ignored/rejected by the native bootloader when uboot determines the Cube is not an engineering device (defined as ARB=0). But the console enable value will be accepted, letting you see native FireOS uart output.
EDIT: I added the 31 IDME properties that can be edited
Click to expand...
Click to collapse
Thanks for the list of IDME properties. I'm getting up to speed now. It's quite different than the typical amlogic setup. No env or vbmeta partitions. There doesn't seem to be any vulnerabilities like the uboot/rsv exploit used for the gen 1 cube.

goapy said:
I don't think current draw is a problem. A 24c02 eeprom draws 1 mA max when reading, and 5 μA max when in standby. Even if both eeproms on the bus were read at the same, that would not be a lot of current. There is only one read operation of each serial device per power cycle.
Click to expand...
Click to collapse
Oh ok that's a minuscule amount. I think HDMI ports are rated for 50-300mA output. Are you able to passthrough 4k 30FPS, 60FPS (Youtube for example) with the one of those connected? Or DV/HDR? I'm curious if a dongle like that could be left in for regular use of the device.
goapy said:
Thanks for the list of IDME properties. I'm getting up to speed now. It's quite different than the typical amlogic setup. No env or vbmeta partitions. There doesn't seem to be any vulnerabilities like the uboot/rsv exploit used for the gen 1 cube.
Click to expand...
Click to collapse
Yeah an ENV partition would have made things a lot easier. Most Fire devices are MediaTek based, and the Cube is sort of alone in the use of U-Boot. There's also the 1st gen Cube and Pendant, but they are getting hard to come by. Frederic's exploit will probably work for any G12A/G12B/SM1 SOC from Amlogic, including the 1st gen Cube and Pendant, but I don't have one to test and make the necessary modifications. Amazon no longer sells these two models, and I'm assuming they also lost DFU access with the February/March update.
I think the uboot/rsv exploit got patched pretty soon after the FireFU release. I also checked aml_emmc_partition.c for the 2nd gen Cube and it was patched by the release version 7.2.0.4.
There is the u-boot vulnerability database. I don't know if any of these are present or useful on the Cube, testing them is above my skill level. I was only able to apply Frederic's exploit to the Cube because he documented everything very well.
I've posted a draft of the raven exploit on github with a little more information. I still need to edit it a bit, but the outline is there.

Pro-me3us said:
Are you able to passthrough 4k 30FPS, 60FPS (Youtube for example) with the one of those connected? Or DV/HDR? I'm curious if a dongle like that could be left in for regular use of the device.
Click to expand...
Click to collapse
It all seems to work so far. All 19 lines are wired as passthrough. The passthrough hdmi ddc link doesn't seem to be bothered by having a non-standard i2c address eeprom on the bus.
Pro-me3us said:
I've posted a draft of the raven exploit on github with a little more information. I still need to edit it a bit, but the outline is there.
Click to expand...
Click to collapse
That's a very illuminating writeup. It instantly filled in a lot of holes in my understanding.
That also seems to have been quite a lot of work, thanks again for sharing it all.

Isn't that most projects, more work than initially anticipated
I did all my testing with the ribbon cable to the physical buttons disconnected. Can you check something for me since you have UART access with the buttons active?
When in FireOS, holding down the Cube action button (button with dot) for 15sec kills all processes and appears shut the device down. But the device is not powered off, the mute button still turns on/off. If you boot into FireOS with the adb root/permissive option, what does the UART output say when doing this?
In this mode, if I press the action button again the Cube reboots, but if I press any of the other buttons, and then action, the Cube does not reboot. So I'm wondering if the Cube is being dropped into some sort of diagnostic that may be accessible from UART.
I'd be interested in seeing any of the UART output including the reboot string
Code:
G12B:BL:6e7c85:2a3b91;FEAT:F2FB39B0:432060;POC:7;RCY:1;USB:3;
I don't know if there are any hidden button combinations when powering the device on that do anything. I'm not sure where that would be defined in the source code. Holding the vol - button during bootup puts the Cube in safe mode. I don't think there are any other known power up button functions yet.

Pro-me3us said:
When in FireOS, holding down the Cube action button (button with dot) for 15sec kills all processes and appears shut the device down. But the device is not powered off, the mute button still turns on/off. If you boot into FireOS with the adb root/permissive option, what does the UART output say when doing this?
Click to expand...
Click to collapse
I'm pretty sure that I executed the sequence described above. Advise If the following is not the correct sequence;
1. boot into FireOS with the adb root/permissive option
2. after fully booted, hold the action button for 15sec
3. after shutdown, try alternatively pressing buttons other than the action button
4. compare the results (of initially pressing buttons other than the action button after shutdown) to pressing the action button without first pressing other buttons.
Code:
=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2022.06.08 16:45:42 =~=~=~=~=~=~=~=~=~=~=~=
idme_platform_write block_offset=3e7000, capacity=400000
fos_flags set to 87
idme_platform_write block_offset=3e7000, capacity=400000
dev_flags set to 64
cmd cb_download is download:008f2800
Starting download of 9381888 bytes
.......................................................................
downloading of 9381888 bytes finished
Booting kernel...success
boot_addr_start bootm 0x1080000
kernel_size 0x8af0af, page_size 0x800, totalSz 0x8b0000
ramdisk_size 0x0, totalSz 0x0
dtbSz 0x42000, Total actualBootImgSz 0x8f2000
amzn_verify_onetime_unlock_code: Verify one time unlock cert fail, ret = -5
ee_gate_off ...
## Booting Android Image at 0x01080000 ...
reloc_addr =73d75610
copy done
Kernel command line: rootfstype=ext4 ro rootwait skip_initramfs OTG_mode=DEVICE androidboot.selinux=permissive
load bootimage dtb from 0x74625610 ......
.
.
.
[ [email protected]] input input0: key 138 down.
.
.
.
[ [email protected]] vendor_write_shutdown_reason: shutdown_reason 0x0
[ [email protected]] hdmitx: hw: avmute set to 2
[ [email protected]] ISSI: resetting device before reboot!
[ [email protected]] meson-mmc: meson_mmc_clk_set_rate_v3 269
[ [email protected]] meson-mmc: actual_clock :0, HHI_nand: 0x80
[ [email protected]] meson-mmc: [meson_mmc_clk_set_rate_v3] after clock: 0x10100002
[ [email protected]] amvecm: shutdown module
[ [email protected]] di pre hrtimer canel 1.
[ [email protected]] [DI] shutdown done.
[ [email protected]] vout: vout2: aml_vout2_shutdown
[ [email protected]] vout: aml_vout_shutdown
[ [email protected]] fb: osd_shutdown
[ [email protected]] amvdac_drv_shutdown: shutdown module
[ [email protected]] reboot: Power down
bl31 reboot reason: 0x108
bl31 reboot reason: 0x108
system cmd 0.
bl30 get wakeup sources!
process command 00000006
bl30 enter suspend!
Little core clk suspend rate 1908000000
Big core clk suspend rate -2086967296
store restore gp0 pll
suspend_counter: 1
Enter ddr suspend
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
The above log happened both when the action button was pressed and also when any other button was pressed instead (after shutdown). New lines containing "DMC_DRAM_STAT11: 0x24" are repeated endlessly, or at least for the 10 minutes that I let it run.
Pro-me3us said:
if I press the action button again the Cube reboots, but if I press any of the other buttons, and then action, the Cube does not reboot
Click to expand...
Click to collapse
I could not get the Cube to reboot if I pressed the action button again after shutdown. Perhaps I wasn't supposed to wait to press it until the shutdown was complete?
A reboot string never appeared, just ""DMC_DRAM_STAT11: 0x24"" endlessly until the power was cycled.
I'm still running PS7229/1856. I don't have an ota for an android 9 version of fireos that is not the current version.
If this is some sort of standby mode, I can't seem to wake out of it.

Do you happen to know why a uart command prompt console can't be started? If;
start console
is executed in a shell with root access, it appears to execute successfully, but no console command prompt appears over the uart connection.
Edit: resolved, disregard.

goapy said:
The above log happened both when the action button was pressed and also when any other button was pressed instead (after shutdown). New lines containing "DMC_DRAM_STAT11: 0x24" are repeated endlessly, or at least for the 10 minutes that I let it run.
Click to expand...
Click to collapse
Ah ok, maybe it is only a shutdown command in that case. The reboot reason 0x108 might be SHUTDOWN_LONG_PWR_KEY_PRESS according to sign_of_life_vendor.c. This looks similar to adb reboot -p which is a software shutdown (0x109?). After a software shutdown the Cube can also be rebooted with the action button. There may be no way to completely shutdown Cube without a real power button. I don't know why in this state pressing the action button doesn't consistently reboot.
Pressing the power button on the remote might also put the Cube in a similar suspension state that does allow waking.
goapy said:
Do you happen to know why a uart command prompt console can't be started? If;
start console
is executed in a shell with root access, it appears to execute successfully, but no console command prompt appears over the uart connection.
Edit: resolved, disregard.
Click to expand...
Click to collapse
I only ever used UART for logs while the kernel was loaded. I never tried to bring up a command prompt. Did you manage to get input working through UART?
For fos_flags the default is 0x0. If you are using the bash menu script it is setting the fos_flags to 0x87 each time FireOS with ADB root is booted. You will have to fastboot boot the image manually to avoid that. You can also set the Flag values with ADB root using the command 'idme fos_flags value'.
The focus was pretty narrow while working on getting the exploit working. I didn't spend much time with the bootrom. Frederic gave me most of the addresses I needed once the bootrom was extracted. I haven't heard of anyone finding extra I2C commands. Both the FireFU and Superna9999 page mention [email protected], but I don't know if that actually works.
You can take a look to see if there is anything interesting. To dump the Cube bootrom run the following command with the zipped files:
Code:
sudo ./amlogic-usbdl memdump_over_usb_s922x.bin cube_bootrom
There is also the question of what that missing 20pin connector is on the Cube PCB.