Related
I've spent some (much) time this week with trying to get ubuntu running on the optimus 2x. I have succeeded to boot and get the wifi, X11 and the touch screen sort-of working.
The ramdisk is completely replaced with a busybox executable, some symlinks to it and a shell script that mounts the necessary stuff (/dev/block/mmcblk1p2 as ext3), changes root directory and calls /sbin/init.
USING THE FOLLOWING WILL VOID ANY WARRANTY YOU MIGHT HAVE LEFT AND MIGHT ALSO BRICK YOUR PHONE!
Seriously, don't do this if you don't wish to risk the data on your phone.
I will be providing some demo images for people who don't have a build environment up and running. These images will not work particularly well, don't get your hopes up .
If you want to have a big linux installation (more than 3 GB) you can flash the images to the second partition on your external sd (obviously you have to create this yourself first). You can use the following boot image (which assumes that linux is on /dev/block/mmcblk1p2 with ext3:
https://ha.xxor.net/o2x/boot-20110813.img
I have also targzipped the modifications to the file system that were required to get stuff going here:
https://ha.xxor.net/o2x/o2x-20110813.tar.gz
This should be extracted directly to the root file system.
The kernel source code is up at https://github.com/ergoen/LG-Optimus-2x-linux-kernel
Things that have been done to get this to "work":
1. Boot partition
Apart from grabbing the busybox stuff from some nexus one boot image (I'm sorry whoever fixed it, I don't remember where I got it from ) the boot command line had to be modified a bit, changing stuff from the default usually ends up in a phone that won't boot, but I discovered that it's possible to append new arguments to the default ones. So the following have been appended:
console=tty0 root=/dev/mmcblk1p2 init=/sbin/init
The console=tty0 makes sure that you see stuff on the screen while ubuntu get's running. The last two are not necessary to boot, but ubuntu seem to like (need?) them (or at least the init=/sbin/init), since otherwise you never get to the login prompt on the screen.
2. The Ubuntu installation
To make it possible to communicate with the phone at all adbd was put into the /sbin/ folder and a symlink was created /system/ -> /. Also the "/sbin/adbd recovery &" command was added to rc.local to make it autostart.
2.1. Modules and wifi
We need the /lib/modules/2.6.32.9 directory. Most files inside that were generated using the "depmod" command, the exception is wireless.ko which was taken from android, the firmware and nvram files needed for the wifi chip to work were placed in the /lib/firmware/wl/ folder. To make the wifi module autoload with the proper firmware "wireless" was added to /etc/modules and the file /etc/modprobe.d/wireless.conf was created with the contents describing the location of the firmware and nvram.
To make the wifi autoconnect on boot the /etc/network/interfaces file was modified with the following contents:
auto wlan0
iface wlan0 inet dhcp
wpa-driver wext
wpa-conf /etc/wpa_supplicant.conf
(To make the wifi autoconnect to your wireless you need to run the command "wpa_passphrase networkname networkpassword > /etc/wpa_supplicant.conf using adb or chroot)
2.2. X11
Getting X up by running xinit produces a simple black screen on the phone. At first I thought the problem was that the refresh rate was set to 106 Hz, indeed changing it with xrandr and pushing a new mode got me a visible xterm on Kubuntu 11.04:
https://ha.xxor.net/o2x/xterm.jpg.
On Ubuntu 10.10 it even gave me a nice colored gdm screen:
https://ha.xxor.net/o2x/gdm.jpg
But the image I got there was static and wasn't being updated. Turns out the reason the screen was black earlier with the 106 Hz rate and the reason why the screen is now just showing an image is that the framebuffer device doesn't update the screen like it should..
By modifying the kernel source to redraw the screen every 50 ms (~20 Hz) it's possible to get a scren that works. This is an ugly hack in the tegra-fb driver though, so I'm open for suggestions on how to solve it in a better way!
2.3. Touchscreen
By default the only thing the touchscreen does is force the mouse up in the left corner, I think this is due to some multitouch thing. Some more kernel hacking (basically half-disabling multitouch) makes the touchscreen work.
Pictures:
https://ha.xxor.net/o2x/SAM_0671.jpg
https://ha.xxor.net/o2x/SAM_0672.jpg
Video:
http://vimeo.com/27662093
Thans to RaYmAn and lilstevie on #tegralinux for all their help this far!
3. Misc
(K)Ubuntu 11.04 uses a new version of libc which crashes with the current nvidia kernel (2.6.32.9) on this hardware (http://developer.nvidia.com/tegra/forum/errata-657451-tls-bit-20-cp15-c13-3), so I'm going back to Ubuntu 10.10 until someone ports a newer kernel to the Optimus 2x or this problem can be solved in another way.
edit 1: Ubuntu 10.10 with much more working X11 noted in section 2.2.1.
edit 2: X11 working even more, touchscreen works aswell!
edit 3: Landscape mode works with both X11 and the touchscreen now, getting ready for alpha 1!
Current status:
Working:
- adb (best way of controlling device currently)
- X11 (only framebuffer with hardcoded refresh rate of ~20Hz)
- landscape mode fixed! =D
- touchscreen (probably only single touch)
- wifi (only when running things from console, ubuntus network manager does not recognize it)
Not working:
- Basically everything else
Alpha 1:
EDIT: Seems that multiupload has screwed up and this link was going to some crap, anyway this is not relevant anymore
Username 'ubuntu', password 'ubuntuxda'. Don't use this if you don't know how to restore the boot partition! (Or else you won't be able to boot back into android!)
Experiments:
Tried disabling the CONFIG_TEGRA_ERRATA_657451 switch in the kernel to make newer linux versions boot. This might be a bad idea in the long run, but this far things are working better than with the switch enabled..
I tried Ubuntu via chroot method posted in other thread, but I'm a noob.. Can you please explain what is different about your ubuntu?? Does it boot without Android and doesn't need VNC stuff?
Yes, it boots instead of android when turning on the phone, but it doesn't work completely, so I mostly put it up here so that people could help test and fix/hack things.
You rock! Unfortunately I'm no dev, so can't help but hopefully others will, so we'll get a fully working linux on our phone, and maybe later even meego. Is there btw drivers for the gpu? Because hdmi, with usb host ofc, would be really useful!
Anyway, good job, really!
This looks great ergoen! I'm no dev either but I can't wait until it's available to everyone, I would love to have Ubuntu running on my O2x.
Best of luck!
gpu drivers are closed source, and the ones released by nvidia require a newer kernel (2.6.38), so thats not really possible yet.
Newer kernel will be necessary anyway though, since the crashes I'm getting seems to be due to a bug in tegra which gets worked around in 2.6.36. I'm not skilled enough to perform that port though. I will of course give it a try, but most likely I'll go for some older version of ubuntu and/or perhaps meego instead.
Håller med tidigare poster. Would be awesome with native Ubuntu and Meego on the phone... keep up the good work, can't wait to follow this development.
Sent from my Optimus 2X using XDA Premium App
ergoen said:
... I realized that it tried to run the screen at [email protected], which is hmm, wrong . So setting up a script at /etc/xprofile, which makes sure the refresh rate is 60Hz...
Click to expand...
Click to collapse
What would happen if you changed this to 72Hz instead? I saw that info when I was browsing System Information in some app. Im not a dev At. All. But tell me what you think it's probably a stupid question
Sent from my Optimus 2X using XDA Premium App
I can give it a try later, not that it would make any difference .
edit: 72 Hz also seems to work, cool, that's higher refresh rate than my computer screen...
ergoen said:
I've spent some (much) time this week with trying to get ubuntu running on the optimus 2x. I have succeeded to boot and get the wifi working, also X sort-of works (software fb). I have only slightly modified the kernel (built with CONFIG_SIGNALFD=y so that Meego wont complain in a related attempt to get that os booting). The ramdisk is completely replaced with a busybox executable, some symlinks to it and a shell script that mounts the necessary stuff (/dev/block/mmcblk1p2 as ext3), changes root directory and calls /sbin/init.
USING THE FOLLOWING WILL VOID ANY WARRANTY YOU MIGHT HAVE LEFT AND MIGHT ALSO BRICK YOUR PHONE!
Seriously, don't do this if you don't wish to risk the data on your phone.
I will not provide a complete root file system for two reasons:
1. It's pretty easy to make yourself, grab the omap3 kubuntu mobile image from the kubuntu site, or use rootstock from an ubuntu installation to build one yourself.
2. My upload sucks, and putting several hundred MB onto the interwebz would hurt me.
However, I have placed an image of my boot partition here (assumes you've got ubuntu on the second partition of the external memory card formatted with ext3):
https://ha.xxor.net/o2x/boot.img
I have also targzipeed the modifications to the file system that were required to get stuff going here:
https://ha.xxor.net/o2x/o2x.tar.gz
This should be extracted directly to the root file system you aquired earlier.
Things that have been done to get this to "work":
1. Boot partition
Apart from grabbing the busybox stuff from some nexus one boot image (I'm sorry whoever fixed it, I don't remember where I got it from ) the boot command line had to be modified a bit, changing stuff from the default usually ends up in a phone that won't boot, but I discovered that it's possible to append new arguments to the default ones. So the following have been appended:
console=tty0 root=/dev/mmcblk1p2 init=/sbin/init
The console=tty0 makes sure that you see stuff on the screen while ubuntu get's running. The last two are not necessary to boot, but ubuntu seem to like (need?) them (or at least the init=/sbin/init), since otherwise you never get to the login prompt on the screen.
2. The Ubuntu installation
To make it possible to communicate with the phone at all adbd was put into the /sbin/ folder and a symlink was created /system/ -> /. Also the "/sbin/adbdb recovery &" command was added to rc.local to make it autostart.
2.1. Modules and wifi
We need the /lib/modules/2.6.32.9 directory. Most files inside that were generated using the "depmod" command, the exception is wireless.ko which was taken from android, the firmware and nvram files needed for the wifi chip to work were placed in the /lib/firmware/wl/ folder. To make the wifi module autoload with the proper firmware "wireless" was added to /etc/modules and the file /etc/modprobe.d/wireless.conf was created with the contents describing the location of the firmware and nvram.
To make the wifi autoconnect on boot the /etc/network/interfaces file was modified with the following contents:
auto wlan0
iface wlan0 inet dhcp
wpa-driver wext
wpa-conf /etc/wpa_supplicant.conf
(To make the wifi autoconnect to your wireless you need to run the command "wpa_passphrase networkname networkpassword > /etc/wpa_supplicant.conf using adb or chroot)
2.2. X11
Getting X up by running xinit produces a simple black screen on the phone. After some troubleshooting and voodoo magic I realized that it tried to run the screen at [email protected], which is hmm, wrong . So setting up a script at /etc/xprofile, which makes sure the refresh rate is 60Hz, and running it after xinit gets you a xterm!!!
https://ha.xxor.net/o2x/xterm.jpg
Telling /etc/X11/xinit/xinitrc to run it makes sure that it gets set up properly by the startx script, unfortunately startx doesn't go through for me on kubuntu because of some weird error caused by a hardware problem in tegra: (http://developer.nvidia.com/tegra/forum/errata-657451-tls-bit-20-cp15-c13-3).
Unfortunately this (probably) means that either we'll have to stay with old versions of libc or get a newer kernel (2.6.36 contains fix). Old libc seems backwards, but porting a new kernel requires a bit more skill than I possess.
2.2.1. Ubuntu 10.10
Grabbed the image ubuntu-netbook-10.10-preinstalled-netbook-armel+omap.img.gz from http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/maverick/release/ . After first unpacking the tgz, then unpacking the raw disk image to partition images (with 7zip on windows) and then flashing the 1.img file to the second partition on my sdcard I managed to run a much more bug free ubuntu than before.
Ubuntu 10.10 (Maverick) uses an older version of som libraries that don't crash with the old o2x kernel.
This has lead to the following:
https://ha.xxor.net/o2x/gdm.jpg
Obviously touch screen isn't working properly (pressing it puts the pointer into the upper left corner :S) so can't get further than this currently.
3. Misc
avahi-daemon and cups seems to be crashing all the time and restarting, so removing them (apt-get purge if ubuntu/kubuntu) will make the boot much cleaner. Also I get lots of alignment trap kind of errors that shouldn't be there for different kinds of services, (due to tegra bug mentioned earlier).
edit 1: Ubuntu 10.10 with much more working X11 noted in section 2.2.1
Click to expand...
Click to collapse
Its good you got it to work.Saves me some work.I was gonna begin this project my self after the 19th when my exams end.Maybe i could help you.
ergoen said:
I can give it a try later, not that it would make any difference .
edit: 72 Hz also seems to work, cool, that's higher refresh rate than my computer screen...
Click to expand...
Click to collapse
Most computer screens usually support atleast 72hz also, it's just that it only works with d-sub, and sometimes only at a lower resolution.. It's possible to make special drivers to some screens to enable higher refresh rate through dvi also.
Anyway, it's good the screen on the phone refreshes at 72hz instead of 60 for android, but in linux I really don't see the benefit.. Doesn't hurt to have though. Btw, if we would stay on this kernel, can we use the drivers from android then? Shouldn't gpu also work? Or are the drivers limited and don't allow xorg for example? Sorry if it's stupid question, don't have that much knowledge how android works yet.
Update: X11 and touchscreen work on Ubuntu 10.10 Maverick with new kernel (just a few hacks )!
manasgirdhar: sure! Lot's of things to do new kernel is needed for anything newer than ubuntu 10.10, and even here things like sound etc (cpu scaling maybe too) don't work.
kruppin: actually i removed the xorg.conf now, the phone thinks its running at 106 Hz and it works. Unfortunately in practice it goes at more like 20 Hz because of the hack I made to enable the fbdev output in the kernel. Android doesn't use X11, so those drivers wont be of any use. (I will post the kernel modifications to github soon)
edit: kernel source up on https://github.com/ergoen/LG-Optimus-2x-linux-kernel
A List of Things working at 2nd Post would be nice.
So anybody could fast see Updates,...
Edit:
Have you tried some "cleaner" Linux like Debian?
Alpha 1 is up in the second post for anyone who wants to test it (don't ^^).
I have not tried debian no, I thought ubuntu would be the easiest to google errors and bugs for .
You are great! i was hopin' for this since I have mine. You should try to make usb(otg) work to get some devices going i will try to test it soon
That's amazing We have to test USB OTG function. If it works by default, I'll try this right now
It is possible to make a dual-boot: ubuntu and android?
I don't think usb otg works since I am basically using the android version of the kernel, I also won't be able to try since I don't have a cable... (will buy one sooner or later).
Dual boot probably works if you flash the boot.img onto the recovery partition instead of the boot partition (/dev/block/mmcblk0p7 instead of /dev/block/mmcblk0p5). I have not tried this though. That way regular booting would give android and booting while holding volume down would give ubuntu, only problem with this is that cwm will be gone and the only way to fix broken things would be to flash with nvflash.
well it is not a major deal if have cifs avail needs kernel support as well. Benee mentioned (might) some otg support, mayb u could ask.
also, you might give E17 a try, it is butter-fast, and has a touch module for keyboard (letter zooming.!..) LINK
this can be compiled on a lot of hw, and gives good response with fbdev non-accel drivers also.
and most linux apps work on it fine. ofc until we have 2d/3d accel and might try compiz/fusion as well
LINK
Great job ergoen!
I've worked on exactly the same some weeks ago but i never accomplished it. because i stuck creating a working ramdisk. Which toolchain do you use?
MfG
Hi,
I'm launching this thread to work on an unbrick procedure for fully bricked I9070/P without JTAG or Riffbox (same as Adam Outler, TheBeano, Odia etc... 's project "let's save some bricks")
Reminder : fully bricked = no download/recovery mode, no display, not charging, not going to recovery with a 301k Ohm jig.
I have a fully bricked I9070P and a fully functionnal I8090 (same processor).
Based on the sources and tools for the U8500 that were disclosed in january, I've managed to make my dead phone and my PC talk "a bit" together (under Windows with the VSIW tool, and under linux with recompiling the "flashkit" tools): when plugged in and inserting the battery, the tool sees the terminal, gets its serial number and various data and fails while trying to send and execute a boot file because the terminal closes the USB port.
I've managed to get a certain degree of communication with the "riff" tool (open source) of the Snowball project too (the dev board based on a U9500).
Based on this half successes, I'm pretty sure we are close to a clean solution to revive a fully bricked terminal without soldering JTAG.
Here are the main docs I've read so far :
* most posts from the threads "let's save some bricks" and "fun with resistors"
* the reference documents of the I9070 (Samsung_GT-I9070_Galaxy_S_Advance_Galaxy_S_II_Lite_service_manual.rar)
* the reference manual of the U9500 (http://www.calao-systems.com/reposi...X/DATASHEETS/AP9500_reference_manual_rev1.pdf)
* TSU6111 datasheet from TI (the USB/UART switch the 9070 is using, cf the service manual -> Lite Schematics -> u-USB SW IC part)
* lots of docs from the "flashkit" sources
My setup :
* a fully bricked I9070P
* a fully working I8190P
* an 8GB SDCard
* a Windows/Linux workstation (Ubuntu 12.04LTS + Android compiling environment + disclosed sources)
* terminal emulators
* a Prolific cable (PL2303) (any USB to TTL adapter would do it, you can buy one for 3$ as Arduino accessory, or reuse a Nokia DKU 5 -see hackaday website for a link). Take care with Prolifics : they don't work under Windows 8 with the last driver, you have to use the version before, Google is your friend)
* a set of resistors
* a multimeter
* libusb win32 drivers setup, see sourceforge (use the tool included in the drivers package to generate the right .inf file for the U8500 (or use 04CC and 8500)
Here are my conclusions so far :
* based on the Snowball docs and the U9500 spec, we don't seem to have any need to modify anything (resistors) on the mainboard to change boot sequence. The dev board does not have any switch for that and my dead I9070 and working I8190 exibit the same behaviour at bootup : the appear as a "U8500 USB ROM" for a seconds and disconnect when going on farther in the boot sequence.
Moreover, the fact that I managed to have my dead phone talk with the flashtool confort me in the fact that we are almost done.
* I have *not* managed to get any output on my terminal with my Prolific cable plugged in with a 630kOhm resistor on the pins 4 and 5. My resistor setup might be good because it make my working I8190 boot when I plug it in.
But I'm not sure of my RX/TX setup, I have crossed the RX/TX of the phone and the ones of the Prolific but I might have been wrong identifying the pins of my modified USB plug (D+ and D-).
But I'm sure the RX and TX wires of my Prolific are the right ones : when I connect them together (nullmodem configuration), the characters typed on my terminal are displayed.
So the main issue is : how can we have the dead phone keep the USB port open and not close it after 2 seconds?
My assumption is that it is always probing different boot methods (UART, USB, MMC etc) and then attempts to boot normaly from eMMC.
I don't know which part of the bootchain sequence I've garbaged on my I9070: IBL, PBL, SBL, PARAM? Managing to get any debug output on my console would greatly help me.
Has any of you tried to achieve something similar? If yes, could you post your setup and results?
Let's save some bricks another time!
any progress
flentus said:
Hi,
I'm launching this thread to work on an unbrick procedure for fully bricked I9070/P without JTAG or Riffbox (same as Adam Outler, TheBeano, Odia etc... 's project "let's save some bricks")
Reminder : fully bricked = no download/recovery mode, no display, not charging, not going to recovery with a 301k Ohm jig.
I have a fully bricked I9070P and a fully functionnal I8090 (same processor).
Based on the sources and tools for the U8500 that were disclosed in january, I've managed to make my dead phone and my PC talk "a bit" together (under Windows with the VSIW tool, and under linux with recompiling the "flashkit" tools): when plugged in and inserting the battery, the tool sees the terminal, gets its serial number and various data and fails while trying to send and execute a boot file because the terminal closes the USB port.
I've managed to get a certain degree of communication with the "riff" tool (open source) of the Snowball project too (the dev board based on a U9500).
Based on this half successes, I'm pretty sure we are close to a clean solution to revive a fully bricked terminal without soldering JTAG.
Here are the main docs I've read so far :
* most posts from the threads "let's save some bricks" and "fun with resistors"
* the reference documents of the I9070 (Samsung_GT-I9070_Galaxy_S_Advance_Galaxy_S_II_Lite_service_manual.rar)
* the reference manual of the U9500 (http://www.calao-systems.com/reposi...X/DATASHEETS/AP9500_reference_manual_rev1.pdf)
* TSU6111 datasheet from TI (the USB/UART switch the 9070 is using, cf the service manual -> Lite Schematics -> u-USB SW IC part)
* lots of docs from the "flashkit" sources
My setup :
* a fully bricked I9070P
* a fully working I8190P
* an 8GB SDCard
* a Windows/Linux workstation (Ubuntu 12.04LTS + Android compiling environment + disclosed sources)
* terminal emulators
* a Prolific cable (PL2303) (any USB to TTL adapter would do it, you can buy one for 3$ as Arduino accessory, or reuse a Nokia DKU 5 -see hackaday website for a link). Take care with Prolifics : they don't work under Windows 8 with the last driver, you have to use the version before, Google is your friend)
* a set of resistors
* a multimeter
* libusb win32 drivers setup, see sourceforge (use the tool included in the drivers package to generate the right .inf file for the U8500 (or use 04CC and 8500)
Here are my conclusions so far :
* based on the Snowball docs and the U9500 spec, we don't seem to have any need to modify anything (resistors) on the mainboard to change boot sequence. The dev board does not have any switch for that and my dead I9070 and working I8190 exibit the same behaviour at bootup : the appear as a "U8500 USB ROM" for a seconds and disconnect when going on farther in the boot sequence.
Moreover, the fact that I managed to have my dead phone talk with the flashtool confort me in the fact that we are almost done.
* I have *not* managed to get any output on my terminal with my Prolific cable plugged in with a 630kOhm resistor on the pins 4 and 5. My resistor setup might be good because it make my working I8190 boot when I plug it in.
But I'm not sure of my RX/TX setup, I have crossed the RX/TX of the phone and the ones of the Prolific but I might have been wrong identifying the pins of my modified USB plug (D+ and D-).
But I'm sure the RX and TX wires of my Prolific are the right ones : when I connect them together (nullmodem configuration), the characters typed on my terminal are displayed.
So the main issue is : how can we have the dead phone keep the USB port open and not close it after 2 seconds?
My assumption is that it is always probing different boot methods (UART, USB, MMC etc) and then attempts to boot normaly from eMMC.
I don't know which part of the bootchain sequence I've garbaged on my I9070: IBL, PBL, SBL, PARAM? Managing to get any debug output on my console would greatly help me.
Has any of you tried to achieve something similar? If yes, could you post your setup and results?
Let's save some bricks another time!
Click to expand...
Click to collapse
dude did you find any solution??same problem here
up up this thread.... i'm also experiencing with my s3 mini i8190 continuously disconnecting libusb-win32 driver... my phone is at deadboot and unable to resurrect with RIFFBOX...
neilPD_07 said:
up up this thread.... i'm also experiencing with my s3 mini i8190 continuously disconnecting libusb-win32 driver... my phone is at deadboot and unable to resurrect with RIFFBOX...
Click to expand...
Click to collapse
Mebay u have dead mini USB port in SIII mini ?
Sent from my GT-I9070 using Tapatalk
Hi guys,
I had a little time playing with this, but I have good news :
I modified the default profile used for the flashtool backend to "ADL boot" : my "dead" phone now stays connected to the USB and is reported as "started" by the flashtool CLI ("flash-tool get_connected_equipments") however, when I try some "active" flash-tool CLI commands, the backend crashes.
As I was running it either in windows 8.1 64 bits or Linux in a VM, their might have some bad interactions with the OS on the one hand and the USB port forwarding on the other hand (there was issues with the LCD and LCM drivers in Windows, I grabbed the 64 bits ones from VSIW...).
-> I have to test on a 32 bit Windows.
Good to read to understand further (extracted from flash-tool-backend.html file) :
Note : ME stands for mobile equipment, "boot indication" can take the following values : ADL, ALT, Normal, Production, Programming : set into the config files pointed by the .mesp file)
Boot process description
When the peripheral boot sequence starts, the ME sends an asic id to the connected PC tool. The PC tool then answers with a boot indication. If normal, "ADL" or "production" is sent as boot indication; this means that the x-loader will start the binary software stored at the corresponding location in the boot image (based on the location stated by the TOC). If programming is used as boot indication, the PC will send a completely new set of boot code to the ME. This is used when a loader is downloaded during service mode startup via the Flash Tool Backend. When the normal boot indication is sent, Flash Tool backend sends no more data and the ME is booted with the binary software stored in the place where the normal software is stored according to the TOC.
The ADL boot scenario works like this:
1. Flash Tool Backend receives asic id
2. Boot indication ADL is sent
3. Flash tool backend starts LCD and LCM and waits for a loader startup message.
The loader is stored at the ADL location of the boot image (this is supported by the assemble tool).
I think I'd have to assemble the correct bootloader to enable "profile-STE_DBX500_flashloader.prfl" profile to work (we are missing corresponding loader.ldr loader). It would enable the use of the "LoaderCommunication"
I think I have all the pieces and the docs (we even have the certificates to sign it !): just need time and a better GFAF (Girlfriend acceptance factor).
The guys who managed to unbrick some Qualcomm based devices might be of a huge help, they would be much more efficient than I can be... I any of you have time to drive them around here, do not hesitate!
Enjoy!
flentus said:
Hi guys,
I had a little time playing with this, but I have good news :
I modified the default profile used for the flashtool backend to "ADL boot" : my "dead" phone now stays connected to the USB and is reported as "started" by the flashtool CLI ("flash-tool get_connected_equipments") however, when I try some "active" flash-tool CLI commands, the backend crashes.
As I was running it either in windows 8.1 64 bits or Linux in a VM, their might have some bad interactions with the OS on the one hand and the USB port forwarding on the other hand (there was issues with the LCD and LCM drivers in Windows, I grabbed the 64 bits ones from VSIW...).
-> I have to test on a 32 bit Windows.
Good to read to understand further (extracted from flash-tool-backend.html file) :
Note : ME stands for mobile equipment, "boot indication" can take the following values : ADL, ALT, Normal, Production, Programming : set into the config files pointed by the .mesp file)
Boot process description
When the peripheral boot sequence starts, the ME sends an asic id to the connected PC tool. The PC tool then answers with a boot indication. If normal, "ADL" or "production" is sent as boot indication; this means that the x-loader will start the binary software stored at the corresponding location in the boot image (based on the location stated by the TOC). If programming is used as boot indication, the PC will send a completely new set of boot code to the ME. This is used when a loader is downloaded during service mode startup via the Flash Tool Backend. When the normal boot indication is sent, Flash Tool backend sends no more data and the ME is booted with the binary software stored in the place where the normal software is stored according to the TOC.
The ADL boot scenario works like this:
1. Flash Tool Backend receives asic id
2. Boot indication ADL is sent
3. Flash tool backend starts LCD and LCM and waits for a loader startup message.
The loader is stored at the ADL location of the boot image (this is supported by the assemble tool).
I think I'd have to assemble the correct bootloader to enable "profile-STE_DBX500_flashloader.prfl" profile to work (we are missing corresponding loader.ldr loader). It would enable the use of the "LoaderCommunication"
I think I have all the pieces and the docs (we even have the certificates to sign it !): just need time and a better GFAF (Girlfriend acceptance factor).
The guys who managed to unbrick some Qualcomm based devices might be of a huge help, they would be much more efficient than I can be... I any of you have time to drive them around here, do not hesitate!
Enjoy!
Click to expand...
Click to collapse
Any good updates & tested solution sir? I'm still waiting for a big solution for this kind of problem... TIA
Hi !
well, I'm almost done with the bootloaders: I have a loader.ldr compiled + 2 bin.
I've reset my dev. env. to an Ubuntu 10.04 according to a .doc I found in the sources (search for "*.doc", you will find "getting_Started_with_Android_and_Linux.doc"): I now have far less compilation errors, but I'm still struggling to get the full compilation process just right. For eg. I had to remove the "alsactrl" component due to dependency issues I've not been able to solve.
As already stated, I'm far from being a dev. expert so it takes me a lot of time to acheive the right compilation.
I would highly need the help of s/b who is fluent with Android compilation/dev env.: first it would be necessary to establish how to merge correctly the disclosed sources with Google's sources + the open sources from Samsung (kernel + system) (we have duplicates here as the kernel is also available in the disclosed sources, but both are different releases).
As already stated, given the few spare tile I have and without the help of the right people this will take me ~4 months+ to have this unbrick done (if I face no deadlock).
So, if you want this faster: get the right guys on the forum (from the "dev" branches) and drag them here so we can go forward much faste!
Hi!
So, I think I'm getting close: I now have the boot files build procedure working (+kernel and sytem, but I don't need those).
When I try to boot my phone with those boot files using the "flasher -tXXXX -X0,normal.bin" command, it seems that they are rejected as the phone connects and disconnects (boot loop on the iRom startup, I believe).
So, now I really need to have some kind of debug console setup to understand what's going on (cause of rejection, like signature problem etc...):
I've been working blindly up to now hopping that the software would work "off the shelves"... it never does
I'll have to try to understand how the "trigger UART" parameter of flashkit backend works and what is it intended to (I'll have to read the code for that as I've never seen any explanation about it anywhere in the docs). I don't figure out how this could work as on the backend GUI it lists the host PC's serial ports...
Another option would be to have my FTDI debug setup working. Maybe it's not "another option" but is required if the "trigger UART" is just enabling UART debug on the phone and requires a debug cable to read these debug data. My problem in that case would be how to have USB *and* UART on the same port... unless all this is designed for dev targets that have 2 USB ports as the Calao's u8500 targets. In that case, i'd have to find something smarter
As usual, if someone with knownledge on all this is willing to help: wave your hand, I'd happy to share my researches and go forward much faster. But I really feel I'm alone on this (even if I know that there will be tons of leechers when/if I manage to have this work
That's life on XDA!
Nice nice
flentus said:
Hi!
So, I think I'm getting close: I now have the boot files build procedure working (+kernel and sytem, but I don't need those).
When I try to boot my phone with those boot files using the "flasher -tXXXX -X0,normal.bin" command, it seems that they are rejected as the phone connects and disconnects (boot loop on the iRom startup, I believe).
So, now I really need to have some kind of debug console setup to understand what's going on (cause of rejection, like signature problem etc...):
I've been working blindly up to now hopping that the software would work "off the shelves"... it never does
I'll have to try to understand how the "trigger UART" parameter of flashkit backend works and what is it intended to (I'll have to read the code for that as I've never seen any explanation about it anywhere in the docs). I don't figure out how this could work as on the backend GUI it lists the host PC's serial ports...
Another option would be to have my FTDI debug setup working. Maybe it's not "another option" but is required if the "trigger UART" is just enabling UART debug on the phone and requires a debug cable to read these debug data. My problem in that case would be how to have USB *and* UART on the same port... unless all this is designed for dev targets that have 2 USB ports as the Calao's u8500 targets. In that case, i'd have to find something smarter
As usual, if someone with knownledge on all this is willing to help: wave your hand, I'd happy to share my researches and go forward much faster. But I really feel I'm alone on this (even if I know that there will be tons of leechers when/if I manage to have this work
That's life on XDA!
Click to expand...
Click to collapse
U R great man..UP UP UP :good::good::good:
use UART debug on USB
This will help me, I'll test it on my working S3 mini (same proc and very similar HW)... when I have time...
-> this will validate my UART debug setup : http://forum.xda-developers.com/showthread.php?t=2100809
ok, UART debug up and partially running on my SIII mini: debug messages displayed on terminal but keystrokes do not reach the phone, this is secondary for me at the moment, I may have a bad contact somewhere.
Tested on my dead I9070: no display, so the Xloader on my eMMC is garbaged (or Xloader UART debug is disabled, but this is less likely).
As expected, I now have to figure out how to have flashloader boot files upload *and* debug working together to understand what's wrong with my compiled boot files. I think the "trigger UART" thing is a good track, but I'm really puzzled by how to have the USB *and* the UART setup at the same time.
I fear to fry something by having phone D+/D- connected to USB port of the PC and connected at the same time to my Prolific TxD/RxD + 5V VCC connected to PC USB... sounds like a bad thing.
Another track would be USB debug I see in some parts of the code, but I don't know how to read the debug from there, more code to inspect...
got it~
---------- Post added at 02:03 PM ---------- Previous post was at 01:22 PM ----------
I also have a fully bricked I9070( not I9070P).I`m waiting for your good news.Thanks first.
I received this PM, I believe it can be useful for others experimenting with it
flentus said:
Ola Paul,
I contact you on an advise from Cocafe.
I launched a while ago the thread "[Workshop] Unbrick fully bricked I9070" (http://forum.xda-developers.com/showthread.php?t=2701363)
I'm looking for help to acheive the task as I don't have very much time to spend on it due to huge work I have this year.
Would you be ok to participate if you have a little spare time and interest in it?
I think I'm very close to the solution, and this would help a lot of 9070 owners (and maybe SIII mini and Sony too).
As explained in my thread, I have difficulties getting the disclosed sources to build correctly up to the end when integrated with Google SDK. As a result the "finalizing" scripts (that gather the binaries and tidy the "out" directory) don't execute: I end up with a large mess and STE tools don't work out of the box. I have to gather the pieces one by one to have them run which is very time consuming and error prone.
I can say that the recovery process won't need any kind of soldering, wiring or whatever: just a regular USB cable and the right sofware.
The disclosed sources contain everything we need: PBL/SBL sources, signing tool+certificates, the software to talk to the iROM + various documentation.
The problem is just a question of assembling the pieces...
My idea is to assemble an Xloader (PBL) + Uboot (SBL) + recovery and boot from that to execute recovery.
The "flashkit" tool enables this process, I quote the docs: "If 'programming' boot indication is used as boot indication, the PC will send a completely new set of boot code to the ME. This is used when a loader is downloaded during service mode startup via the Flash Tool Backend.".
Tell me if you wish to help me, or if you know someone who has competencies and would wish to!
I speek average spanish if you prefer to exchange in this language.
Regards
Click to expand...
Click to collapse
I am sorry for pointing this out, STE tools wont work ever on i9070, the reason being that we do not have a STE bootloader, heck, most of the low level stuff do not resemble the ST-Ericsson Montblanc development board. You can't even change the bootloader arguments, you can only add to them (the way I first enabled SELinux), the Samsung Bootloader version that we have may be not as restrictive as others, but Sonys bootloader resembles more to STE's than ours.
The only way you may found how to restore it is accessing the JTAG mode (something that is determined only if JTAG is connected and recognized) and depends solely on the emergency bootloader (if that exists, because I am not sure how the device powers on without PBL), the "seconds" of power you get on the USB is the device looking for JTAG.
The "disclosed" sources are for ST-Ericsson devices
Something you should do, is analyze the structures of /dev/block/mmcblk0p10, which contains our partition table (GUID Partition Table - GPT).
Simple way of doing it, you have to do dd if=/dev/block/mmcblk0p10 of=/sdcard/janice.pit on terminal emulator, this is ROM agnostic, because the structures are the same on both stock and any custom ROM. Of course, that is from a working device, I'll do that and drop it here later since I am working on something else right now, and thanks diegoch for discovering this.
Anyway, as diego pointed to me, our partition table is like this.
PIT, CSPSA, EFS, MODEM fs, SBL, SBL2, PARAM, IPL modem, MODEM, Kernel, Kernel2, system, data, cache, preload, fota, sdcard
This is the correct order I believe, since basically, when you use ODIN and use a PIT file, the partition table gets rewritten according to whatever is on that .pit file. So PIT is basically the GPT partition table; obviously SBL is the Samsung bootloader, and SBL2 I believe it's either stage 2.5 or a backup of the first.
So, no clue by going the STE way, something familiar here.
So, I may say something good at the end, see if the i9100 guys ever did it, and go from there, since our device is largely based around i9100 (Galaxy S II)
Hi Paul,
thanks for your contribution.
A few replies/questions :
* you state that Montblanc dev board and I9070 are completly different: isn't the aim of dev dev board to be close to ME while adding extra connectors to ease debug and interfacing for prototyping? Calao dev board looks very close to I9070: I have compared the schematics and component list: they look very very much alike. For me, NovaThor U8500 plateform consists of a DB8500 SoC, a Mali 400, a built-in modem + chips for USB, audio and SIM operations.
So, to me, I may be wrong, at least the processor (u8500), PLL, eMMC, SDRAM, UART + several low level controlers should be the same. As we are trying to work at such level (just trying to get the basic system to boot to just enable eMMC write), don't we have a chance to manage to have those work (maybe with adressing adaptation, those might be tough)?
* I can't agree with you that "the "seconds" of power you get on the USB is the device looking for JTAG.": on boot time, even without trashed PBL, the ME connects to USB properly with vendor/ID=04cc/8500, and sends its ASIC ID (displayed on PC screen). As stated earlier in the thread, I manage to send some commands and receive response from the ME in this state using STE tools (flashkit_cli, sending commands threw flashkit_backend).
It's definetly not any JTAG stuffs. JTAG on the I9070 is accessible on the mainboard via dedicated pads, you can locate using the light schematics provided in the "Service manual" package.
This early boot behaviour is documented in the "flash-tool-backend.html" document (available in s-4.1_vendor_st-ericsson.tar in ./s-4.1_vendor_st-ericsson/vendor/st-ericsson/tools/platform/flash_kit/flash_tool_backend/com.stericsson.sdk.backend.build/doc):
Boot process description
When the peripheral boot sequence starts, the ME sends an asic id to the connected PC tool.
The PC tool then answers with a boot indication.
- If normal, ADL or production is sent as boot indication; this means that the x-loader will start the binary software stored at the corresponding location in the boot image (based on the location stated by the TOC).
- If programming is used as boot indication, the PC will send a completely new set of boot code to the ME. This is used when a loader is downloaded during service mode startup via the Flash Tool Backend.
- When the normal boot indication is sent, Flash Tool backend sends no more data and the ME is booted with the binary software stored in the place where the normal software is stored according to the TOC.
The ADL boot scenario works like this:
1. Flash Tool Backend receives asic id
2. Boot indication ADL is sent
3. Flash tool backend starts LCD and LCM and waits for a loader startup message.
The loader is stored at the ADL location of the boot image (this is supported by the assemble tool).
* If I understand well, as we don't have the sources for the bootloader, your proposal is to grab one from a working device.
That sounds a really good idea!
Here is the complete partition table/PIT of the I9070 (recovered by someone with a Riff box from a GB archive, if I remember well):
(copy/paste it in a traditional editor and add padding to recover the table).
Partition number Filename in archive Name in PIT starting offset HEX Size in bytes HEX
MBR, GPT 0 20000
STE_boot.bin TOC ISSW XLOADER 20000 60000
mmcblk0p10 GT-I9070P_EUR_XX_8G.pit PIT 80000 100000
mmcblk0p6 cspsa.img CSPSA FS 180000 180000
EMPTY 300000 100000
mmcblk0p7 EFS.img EFS 400000 A00000
mmcblk0p2 modemfs.img MODEM FS E00000 100000
mem_init.bin STE MEM INIT 1E00000 80000
power_management.bin PWR MGT 1E80000 80000
mmcblk0p14 normal.bin SBL 1F00000 200000
mmcblk0p16 normal2.bin SBL_2 2100000 200000
mmcblk0p1 param.lfs PARAM 2300000 1000000
mmcblk0p12 ipl.bin IPL MODEM 3300000 200000
mmcblk0p13 modem.bin MODEM 3500000 1000000
mmcblk0p15 kernel.bin KERNEL 4500000 1000000
mmcblk0p17 kernel2.bin KERNEL2 5500000 1000000
mmcblk0p3 system.img SYSTEM 6500000 26400000
mmcblk0p5 userdata.img DATAFS 2C900000 80000000
mmcblk0p4 cache.img CACHEFS AC900000 13200000
mmcblk0p9 hidden.img HIDDEN BFB00000 14000000
mmcblk0p11 ssgtest.img FOTA D3B00000 3200000
mmcblk0p8 ums.rfs UMS D6D00000 FAA00000
--> PBL corresponds to "TOC ISSW XLOADER" (STE_boot.bin in the flash archive) and SLB to normal.bin. So basically we have our boot files. We can extract them from the GB flash archive or from a ROM dump (I have dd'ed every partitions from 2 different I9070P + a full recovery dump from a 9070 provided by Riff box support files I found once I don't remember where).
So, if I have time one of theses days, I'll try to build a flash archive based on these files and try to boot from STE tools on it using "programming" as boot indication.
* Using the knowledge of the I9100 (Galaxy S II): I'm afraid this is a very different hardware, I9100 uses an Exynos 4210, so I hardly see what we could use from there... Could you give us some more advise on that idea?
Regards
Hi!
I had no time working on this for a while: extremely busy at work.
Maybe this weekend...
@cocafe: I've read you know how to extract the initramfs from the kernel, modify, repack, and reflash it. I'll need to do that to modify the "on boot" section of the init.rc to launch the recovery from standard boot. Could you drop me here the command lines to do that? Thanks in advance!
This looks by far the most advanced research into bringing back a hard bricked i9070.
@flentus Did you manage to upload a new bootloader?
Hi,
had to time at all to play with this for a loooong time.
I have grabed a few new phones so me 9070 is now burried deep into a drawer but I really wish to finish this one day because I feel I'm very close to something.
If anybody would like to take over this, feel free, I can provide support for the stuff I have understood (and remember of...)
Regards
Can anyone advise this rookie user how to set up a test environment to use with an Android Studio project?
I recently installed Android Studio on my Windows 7 laptop and put together my first simple app. When I tried to debug it, I was offered two pre-configured test environments. The first was "Nexus 5 API 21x86" but when I tried to use that one it told me I needed HAXM. After much research I worked out what I needed to do to install HAXM but the installation file gave me the following error message:
VT_Not_Support = This computer does not support Intel Virtualization Technology (VT-x). HAXM cannot be installed."
I therefore turned my attention to the second option "TestDevice". When I tried to run that, Android Studio reported:
emulator: ERROR: This AVD's configuration is missing a kernel file!!
emulator: ERROR: ANDROID_SDK_ROOT is undefined
I Googled the error and found the advice that I needed to install "ARM EABI v7a System Image" but when I ran the SDK manager it told me that this component was already installed.
Can anyone please tell me either how to overcome the ANDROID_SDK_ROOT undefined problem or advise how otherwise to set up an emulated test environment that works on my computer.
I am an experienced programmer but a complete novice when it comes to Android Studio, all the associated applications and Android devices in general.
Many thanks in advance for your patience.
Keith
writerman said:
... following error message:
VT_Not_Support = This computer does not support Intel Virtualization Technology (VT-x). HAXM cannot be installed."
Click to expand...
Click to collapse
Keith, have you tried enabling VT-x in your BIOS settings?
Thanks for the suggestion. I wasn't aware of this BIOS setting. I will give it a try but may not have a chance to try it out until the weekend
This should do the trick if you have compatible CPU.
Hi,
I installed the Linux Deploy program on my phone and installed Debian. When I load in framebuffer mode, i see an almost black screen
i tried different settings, none of them helps to make the graphics normal. Perhaps the problem is in the framebuffer driver in the android core? Will it work with custom kernels, maybe someone has already installed them and can check? Is there any way to fix the framebuffer on this device?
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Raven Boot v2.0 now includes persistent root. A huge thank you to @Functioner for getting it working! This package includes unrestricted U-Boot, fastboot & Amlogic burn mode commands, as well as TWRP and Magisk support. The Raven boot tool includes options to root your Cube, gain temporary root access without modifying your device, and a number of options for recovery and backup.
NOTE: FireOS < 7.2.7.3 required
A newer method is available that works up to PS7292, that doesn't use DFU or a DFU device, but has no DFU recovery options
NOTE: This process does not require you to open your Fire TV 2nd gen Cube
Changelog:
v2.2 April 7th, 2023
Minor update to Magisk 25.208
Hopping back on official signed Magisk app line
v2.0 and v2.1 use an unofficial Magisk build that will result in a signature mismatch when updating.
If you are using Raven root v2.0/2.1, delete the file /data/adb/magisk.db on your Cube,
before updating to Raven root v2.2.
Added USB booting for flash drives that use aml_autoscripts, for future development.
v2.1 February 18th, 2023
Updated TWRP v3.6.1-9-0 ---> v3.7.0-9.0
Fixed problem with TWRP not always displaying all the partitions under 'Mount/Backup'
Always mounts 'Internal Storage' to /sdcard now
Fixed bash menu to always use the included fastboot binary
Cube's physical buttons can be used on bootup
Volume Up ---> Fastboot
Volume Down ---> TWRP recovery
Action button ---> Amlogic Update
**Hold down button for ~5sec after power-on, and before the blue LEDs / 1st Amazon logov2.0 February 9th, 2023
Root is now persistent, does not require computer after every reboot
One click option to install root access, TWRP, Magisk & OTA blocker module
Magisk updates
Zygisk is working (July 1st, 2022)
Magisk can be installed from TWRP or direct installed from within Magisk Manager
Created module to block Amazon OTA updates via etc/hosts and hiding the OTA apk
updated quick access images to Magisk v25.2
TWRP updates
Bootloader flashing is blocked, so that full OTA firmware bins can be easily flashed (tested up to PS7624/3337)
Removed firmware downgrade checks & warnings
Added NTFS support for flash drives within TWRP
Added options to backup entire reserved partition, and mmcblk0boot0 & mmcblk0boot1 boot partitions in Amlogic update
Added emergency boot to Fastboot/Update modes
v1.0 May 15th, 2022
Temporary unrestricted fastboot, u-boot & update commands
Boot with root access or Magisk support
Boot to TWRP for backup & recovery
Backup Cube using Amlogic Update
What's needed:
linux installation or live-system (Ubuntu 20.04.x recommended)
micro-USB cable
device to put Cube into device firmware upgrade (DFU) mode [read below]
libusb is needed for your linux installation to detect the Cube over USB.
sudo apt-get install libusb-1.0-0
To automatically set the proper udev rules for Amlogic install Khadas utils:
sudo apt-get install libusb-dev git
sudo apt-get install git
git clone https://github.com/khadas/utils
cd utils
./INSTALL
***NOTE: If you previously installed Magisk on your Cube from raven_boot v1.0, first run adb shell rm /data/adb/magisk.db to prevent any conflicts with the new Magisk version.
Instructions
Download the latest raven_boot.zip and unzip it. Open a terminal window from the unzipped raven_boot directory
Power off the Cube and connect your DFU device to the Cube's HDMI port. Connect the USB cable (microUSB to USB-type A) to computer & Cube
Power on the Cube, type lsusb in the terminal to confirm ID 1b8e:c003 Amlogic, Inc. is present, indicating the Cube is in DFU mode
Unplug the DFU device from the HDMI port, reconnect the Cube to TV with HDMI cord. Keep the computer connected.
In the terminal type bash menu, and choose option 1) to automatically root the Cube.
To preserve the Cube's persistent root, be sure to confirm that both TWRP & Magisk are installed.
Quick Access
For options 2) and 3) to gain temporary root, download the images zip file that corresponds to your current FireOS version, and unzip the contents into raven_boot/images directory.For Cubes running FireOS 7242/2896 or later get ---> images_7242-2906_v2.0.zipFor FireOS versions 7201/942 to 7242/2216 get ---> images_7229-1853_v2.0.zip
Magisk v25.206 is included with Raven boot, it's recommened that you use this version or newer. For instructions on how to update your firmware and keep root access, read here
About the exploit
This exploit is based on a vulnerability in the Amlogic bootrom that allows for us to run unsigned code in the next boot stage (Bl2). To pause the automatic boot up process, before the Cube's saved Bl2 is loaded, we rely on Amlogic's device firmware upgrade mode (DFU). In DFU, only the boot code from the Amlogic s922x SOC (Bl1) has been loaded into memory. We then use the vulnerability to load our modified Bl2, breaking the 'chain of trust', and disabling secure boot so that we can make modifications to the bootloader downstream. The last stage of the bootloader is U-boot (Bl33) which hands off the startup process to the kernel (boot.img). U-boot is modified to unlock any restrictions on u-boot and fastboot commands, giving us full access to system features. We can then use fastboot boot to load our modified boot images (TWRP, magisk-patched boot.img), into memory without modifying the Cube's eMMC.
Visit GitHub for a more in depth write-up and resources used in this project
Contributors
@Functioner
@Zenofex
@npjohnson
@zeewox
@Pro-me3us
Additional thanks to
@tchebb - a bottomless encyclopedia of Amlogic knowledge, answering countless questions & troubleshooting
@roligov - providing photos, additional FireOS updates, and testing
@osm0sis, @canyie, @vvb2060 & @yujincheng08 - the Magisk team for being awesome, troubleshooting and making a number of code changes to get all features working on the Cube
@k4y0z - helping troubleshoot some TWRP and Magisk issues
Entering the Cube's DFU mode
To boot into device firmware upgrade (DFU) mode we need to pass a '[email protected]' command, to the Cube's Amlogic s922x SOC, through the I2C bus accessible via the HDMI port. This was first described in the FireFU exploit for the 1st gen Cube. Since then there are a few more options for devices to accomplish this:
DIY modified dummy HDMI dongle. Fully self-contained, and powered by the HDMI port. Simple to use, just plug-in and unplug, can be made for $5 or less and is what I recommend.
https://github.com/superna9999/linux/wiki/Amlogic-HDMI-Boot-Dongle
I2C emulator for ATmega boards (Arduino Duemilanove, ATmega48/88/168/328). Requires less skill, potentially little to no soldering. A Tiny88 ($2-3) wired to an HDMI breakout board ($2-3) can be programmed over USB with one command.
https://github.com/tchebb/amlogic-hdmiboot-avr
Arduino sketch to boot into DFU, compatible with ARM-based Arduino boards (Due, Teensy, Genuino). Costs more but a good alternative if you already have an Arduino board.
https://www.exploitee.rs/index.php/FireFU_Exploit#Preparing_HDMI_dongle
Flashing OTA Firmware with TWRP
To upgrade the firmware past PS7273+ and keep the Cube unlocked and rooted, we need to avoid flashing any bootloader version newer than PS7242/3516. The new build of TWRP included with Raven boot v2.0+ and Raven root shrinker automatically blocks any bootloader flashing. Be sure that you are using Raven boot v2.0 or newer! Firmware bin flashing is working and tested up to PS7633/3445.
The shrinker script only works up to PS7624/3337, upgrading past this version will still maintain root, but will lose the shrinker backdoor backup.
Update Procedure:
1) Download the full firmware bin (XDA or Github), change extention .bin to .zip
2) In ADB type reboot recovery to enter TWRP. You can also open Magisk Manager and choose the reboot to recovery option in the top right corner of the main screen.
3) Copy the firmware file to your Cube via USB connected computer, flash it, and re-flash Magisk
Code:
adb push <firmware-filename.zip> /sdcard/Download/
adb shell
twrp install /sdcard/Download/<firmware-filename.zip>
twrp install /sdcard/Download/magisk.apk
If you used the shrinker method, then the magisk apk is in /data/local/tmp/ instead
Code:
twrp install /data/local/tmp/magisk.apk
If you prefer to use a USB mouse and regular TWRP interface, rather than computer, download the firmware bin directly to the Cube in FireOS. Firmware updates don't require wiping data/dalvik. If downgrading firmware, wiping data/dalvik is advisable.
NOTE: It's IMPORTANT to not forget to flash magisk.apk after each firmware upgrade. Magisk & TWRP work together to preserve root access. Magisk prevents TWRP from being deleted, and TWRP helps to prevent accidental Amazon OTA updates. Without Magisk, OTA updates will no longer be blocked by the OTA blocker Magisk module.
Protected Packages
Amazon added package protection in +PS7273. To remove this, boot into FireOS with Magisk or root support, edit /data/system/PackageManagerDenyList, delete the list of applications, and save.
To prevent the protected applications list from being regenerated on reboot, disable:
Code:
adb shell pm disable-user com.fireos.arcus.proxy
All applications can now be disabled/enabled without root, including custom launchers.
reserved
Thanks for this! So far I've only confirmed old enough firmware (PS7229/1856) and installed a uart header. Seems I will have to wait a while to get a working hdmi plug for dfu access.
While looking at the uart log, I noticed that u-boot is interruptible prior to boot, which is a little unusual. But every u-boot command is disabled, even "help"!
I noticed some text about a one time override code of some sort. Did you find any additional information about this code while working on the bootloader?
Would it not be possible to just flash a patched bootloader, much like is described at the site you've referenced? Is the stock bootloader encrypted? If so, were the relevant keys extracted?
What about ≥ 7.2.7.3 kills this exploit? Is dfu access lost? If not, what else prevents it from working? I wouldn't think that dfu could be lost, since it is in rom, unless an efuse can disable it?
goapy said:
While looking at the uart log, I noticed that u-boot is interruptible prior to boot, which is a little unusual. But every u-boot command is disabled, even "help"!
I noticed some text about a one time override code of some sort. Did you find any additional information about this code while working on the bootloader?
Click to expand...
Click to collapse
On the stock bootloader Amazon has blacklisted all uboot commands. The bootloader code is available through Amazon's open source repository. The uboot console restrictions are in:
platform/bootable/bootloader/uboot-amlogic/s922x/bl33/common/amzn_lockdown.c
The unlock codes are generated by Amazon's servers in combination with the devices' serial number. This system is the same as other fire devices. There is a list of all the uboot commands in the documents folder of raven_boot.zip to give you an idea of what's available.
To work with the U-boot console, you can also send uboot console commands via Amlogic burn-mode for convenience.
Code:
./update bulkcmd "uboot command"
Unfortunately, i don't think there is a way to route the uboot console output over HDMI or USB, so TX is still necessary for visualization. Your soldering work and connector look a lot nicer than what I was working with, I'm jealous
goapy said:
Would it not be possible to just flash a patched bootloader? Is the stock bootloader encrypted? If so, were the relevant keys extracted?
Click to expand...
Click to collapse
The bootloader is signed, and verified by the bootrom. This is part of the 'chain of trust' that ensures the bootloader is not altered / tampered with. The reason the patched bootloader in the OP can be loaded is because we are using a tethered computer to run a bootrom exploit program (amlogic-usbdl) to inject our own next stage code (bl2.bin) that bypasses the bootrom verification process. The modified Bl2 code allows for the rest of the bootloader to load. Without a computer to run the exploit, our Bl2 code would fail verification, and the Cube would hang.
The bootloader is encrypted with several keys, and the keys change with major releases. I don't know what XDA's policy is on posting keys, so I don't want to chance a violation. A more detailed description of the whole process will be added to github relatively soon.
goapy said:
What about ≥ 7.2.7.3 kills this exploit? Is dfu access lost? If not, what else prevents it from working? I wouldn't think that dfu could be lost, since it is in rom, unless an efuse can disable it?
Click to expand...
Click to collapse
@roligov said he was not able to enter into DFU with USB after 7.2.7.3. There was an option added to the efuse file last year to disable DFU from USB, my guess is Amazon chose to burn the fuse(s) in 7.2.7.3.
EDIT: If you plan to be do a lot of probing, I'd recommend going with Superna9999's HDMI dongle design, it's a lot more convenient than the Arduino boards.
goapy said:
What about ≥ 7.2.7.3 kills this exploit? Is dfu access lost? If not, what else prevents it from working? I wouldn't think that dfu could be lost, since it is in rom, unless an efuse can disable it?
Click to expand...
Click to collapse
Pro-me3us said:
@roligov said he was not able to enter into DFU with USB after 7.2.7.3. There was an option added to the efuse file last year to disable DFU from USB, my guess is Amazon chose to burn the fuse(s) in 7.2.7.3.
Click to expand...
Click to collapse
Exactly that. I had a unit that worked fine, tested DFU mode before applying update Fire OS 7.2.7.3 (PS7273/2625). After updating to that firmware version, DFU mode no longer worked. Exact same setup worked 5 minutes before and still works on other cubes. If no one on here confirms it no longer works on the latest firmware, I may sacrifice another cube and update to the latest. I thought it wasn't possible either since it's a bootrom exploit, but guessing an efuse has been burnt.
It may be possible to probe the board and achieve DFU mode by someone who knows what they doing like the method used for the Fire Sticks (I tried with 1 cube which ended up in a bootloop, luckily Amazon replaced it).
Pro-me3us said:
The bootloader is signed, and verified by the bootrom. This is part of the 'chain of trust' that ensures the bootloader is not altered / tampered with.
The bootloader is encrypted with several keys, and the keys change with major releases.
Click to expand...
Click to collapse
Whatever bootloader keys are used for the chain of trust in order to ensure an internally consistent hand-off from stage to stage are distinct from the most external bootrom key that is used to encrypt the entire bootloader partition image from start to finish, right? That most "external layer" bootrom key, that is used to encrypt the entire bootloader partition image, must remain the same for the life of all instances of the hardware, at least if all similar devices are to be able to run firmware updates, right?
By the "most external layer" of encryption, I mean this layer;
If a device that is configured for secure boot, as distinguished from a device that is not configured for secure boot, like the khadas VIM3L (but still has a bootloader partition that is at least encrypted with the most external layer key), could it not run a different bootloader (that was internally consistent and unmodified), so long as that bootloader was encrypted with a matching most external layer key? Does secure boot prevent this?
For example, if an entire bootloader was taken intact from a generic 922 device, and that entire bootloader was not internally modified at all (but happened to have a functioning u-boot bl33 layer), and that entire bootloader (after itself being decrypted with its most external layer bootrom key, if necessary) was encrypted with the most external layer key matching the v2 cube, would that bootloader not boot all the way to bl33 and beyond on the v2 cube?
Perhaps an internally consistent alternative bootloader, even if if properly encrypted with the most external layer bootroom key, would still break the chain of trust because the portion of the bootloader that is in rom (bl1) is not just generic bootloader code common to many devices, but is customized specifically for that particular secure boot device (or references a root of trust elsewhere in the rom that is individualized), so the subsequent bootloader stages would fail trust because of that individualization that is in, or referenced by, bl1, even if they were entirely unmodified?
Perhaps this bootloader might boot but avb or vbmeta verification might fail in some other way, or whatever drm magic is in the bootloader might be absent, but would it not at least boot, or does secure boot prevent any internally consistent alternative bootloader from booting, even if it is encrypted with the correct most external layer key, matching the bootrom key?
I apologize if I'm missing something obvious because of my impoverished understanding of this process.
roligov said:
Exactly that. I had a unit that worked fine, tested DFU mode before applying update Fire OS 7.2.7.3 (PS7273/2625). After updating to that firmware version, DFU mode no longer worked. Exact same setup worked 5 minutes before and still works on other cubes. If no one on here confirms it no longer works on the latest firmware, I may sacrifice another cube and update to the latest. I thought it wasn't possible either since it's a bootrom exploit, but guessing an efuse has been burnt.
Click to expand...
Click to collapse
Do you have any guesses about how the efuse is burnt by the updated system? Might the new bootloader itself do it, or the running system, or is there anything obvious in updater-script (if amazon ota's use an updater-script)?
It seems that all of the quickly obtainable edid-spoofing hdmi plugs come with an eeprom in the sot23 package, lacking the a0, a1, and a2 pins needed for the addressing change. Does anyone know of a hdmi plug that uses an 8-lead eeprom that can be ordered for quick delivery?
Otherwise I'll modify the sot23 version that I have coming tomorrow, replacing the sot23 at24cs02 with an 8-lead version that I can pull from some waste board.
goapy said:
Do you have any guesses about how the efuse is burnt by the updated system? Might the new bootloader itself do it, or the running system, or is there anything obvious in updater-script (if amazon ota's use an updater-script)?
Click to expand...
Click to collapse
At power on Amlogic devices will print a string of SOC information that starts with G12B:BL....
in that string is F2FB39B0:432060. The 2 values report the security efuse status for the device. 32bit values:
CFG9: 0x00432060
CFG10: 0xF2FB39B0
Following 7273/2625 there is a 1 bit change in CFG10
CFG10: 0xF2FB39B0 (pre 7273) = 1111 0010 1111 1011 0011 1001 1011 0000
CFG10: 0xF2F339B0 (post 7273) = 1111 0010 1111 0011 0011 1001 1011 0000
Bits are read from right to left starting with bit 0, so Flag 19 flips from 1 to 0. The security efuse table shows that an efuse was buned to disable 'IS_FEAT_USB_BOOT_ENABLE', barring DFU entry via USB.
There is little documentation on how to burn efuses, more importantly I don't know of any public information on the efuse addresses that correspond to which features. Burning efuses would have to be done through uboot and the Bl31api which is how non-secure world talks to secure world. Amazon may handle it through cmd_efuse.c, since there was an addition to that code made to disable USB boot in 2021. The following can be found in the 2nd gen Cube package from Amazon's open source page
platform/bootable/bootloader/uboot-amlogic/s922x/bl33/common/cmd_efuse.c
goapy said:
Whatever bootloader keys are used for the chain of trust in order to ensure an internally consistent hand-off from BL stage to BL stage are distinct from the most external bootrom key that is used to encrypt the entire bootloader partition image from start to finish, right? That most "external layer" bootrom key, that is used to encrypt the entire bootloader partition image, must remain the same for the life of all instances of the hardware, at least if all similar devices are to be able to run firmware updates, right?
Click to expand...
Click to collapse
There are several layers of security, including encryption and signed code. The s922x contains an AES key which is static, and it can be used to decrypt the bootloader. The Cube has boot decrypt enabled, meaning that it is expecting Bl2 to be encrypted, and it will decrypt anything passed to it with the internal AES key. Amazon takes things a step further and encrypts the later bootloader stages with 3 more AES keys. So to fully decrypt the bootloader there are 4 total keys, one of which is static.
But in the case of the Cube, decryption is not an issue since we can dig to get all the keys. The keys just allow the SOC to unscramble the image. There is also signing which involves image hashes. By modifying the image, the hash changes, failing the signature check. The function of the amlogic-usbdl exploit is to bypass the code verification, not encryption.
The Bl2 signing tool is public but Bl2 is not open source. I don't know how functional the Bl2.bin is that is included in the firetv open source repository. There's likely also other security checks I'm overlooking.
goapy said:
For example, if an entire bootloader was taken intact from a generic 922 device, and that entire bootloader was not internally modified at all (but happened to have a functioning u-boot bl33 layer), and that entire bootloader (after itself being decrypted with its most external layer bootrom key, if necessary) was encrypted with the most external layer key matching the v2 cube, would that bootloader not boot all the way to bl33 and beyond on the v2 cube?
Click to expand...
Click to collapse
If it was from a generic device without any security features implemented in the bootloader maybe? The Cube has a root key burned to it that I assume is specific to the 2nd gen Cube. I believe this is used in verifying bl2.
There would be hardware/board differences that would lead to a host of issues as well. Uboot would be missing the FireOS layer, so I would be surprised if it could hand things off properly. Bl2 would still have to be encrypted using the AES key, since the Cube has boot encrypt enabled, which is doable.
That could be tested with Amlogic's update tool in DFU.
Code:
./update write bl2.bin 0xfffa0000 //loads bl2 into memory at the run address
./update run 0xfffa0000 //executes bl2 from memroy
./update bl2_boot bootloader.img //loads and runs the rest of the bootloader into and from memory
The closest thing to Khasdas' VIM3L for the s922x is the Odroid N2/+, in terms of a developer's board with little to no security features implemented. The unsigned Cube bootloader will load fairly far on the N2+, but I don't remember if it got as far as the kernel. I never tried the reverse, loading an N2+ bootloader on the Cube.
goapy said:
Otherwise I'll modify the sot23 version that I have coming tomorrow, replacing the sot23 at24cs02 with an 8-lead version that I can pull from some waste board.
Click to expand...
Click to collapse
I did ^this^ because the 8-lead version that I ordered still hasn't arrived yet. See before/after images below. It was a success and I was able to get the exploit running.
While swapping out the eeprom, I noticed that the ddc (display data channel) pair of lines was terminated in the plug, even though this edid emulator device supports passthrough. The ddc pair carries at least two kinds of data, edid and hdcp.
Presumably ddc is terminated because otherwise there would be a serial wire device conflict on the i2c bus at address 0x50, since both the edid emulator device and the sink would each have a eeprom (or prom) at that address.
But since for dfu usage the address is changed to 0x52, I figured the ddc lines could be reconnected and the 0x52 serial device could just ride on a passthrough i2c bus. So, I wired the sda and scl lines as passthrough lines.
I hoped that this would mean that I could repeatedly use the exploit over time without swapping hdmi connections for every reboot. And it does do that. But it also takes a power cycle in order boot to dfu mode from an actively running OS. Booting any of the other images, such as fastboot, twrp, etc., do not require a power cycle and reboot straight to dfu mode with the passthrough device installed.
So, it is still more convenient to just cycle power rather than swap hdmi plugs.
As far as testing the exploit itself, I've only spent an hour so far. The included magisk patched boot image does work, although when I tried to boot a magisk patched boot image that I patched myself (using the original image on the device as a source), it did not boot. All of the provided boot images do work, and are all very useful.
goapy said:
I hoped that this would mean that I could repeatedly use the exploit over time without swapping hdmi connections for every reboot. And it does do that. But it also takes a power cycle in order boot to dfu mode from an actively running OS. Booting any of the other images, such as fastboot, twrp, etc., do not require a power cycle and reboot straight to dfu mode with the passthrough device installed.
Click to expand...
Click to collapse
That's a very nice improvement over Superna9999's design, you should share this with him I did start to strip the plating on my HDMI cable from all the plugging/unplugging during testing. With this design, does the Cube end up powering two ICs, the one on the dongle and the one in the TV HDMI port? Are there any issues having the Cube power both?
Even with the original design, I think a power cycle is required to get into DFU, rather that just a reboot. I remember adb rebooting would cause the Cube to keep resetting until a power cycle or the dongle was removed. It may be that there is a bootrom level 'reboot reason' stored in volatile memory, that's not cleared until power cycling? If you send a reboot command from u-boot / burn mode are you put in DFU, or do you still need to power cycle? I briefly looked for a command to reboot into DFU (without I2C), but couldn't find anything.
goapy said:
The included magisk patched boot image does work, although when I tried to boot a magisk patched boot image that I patched myself (using the original image on the device as a source), it did not boot.
Click to expand...
Click to collapse
You'll need to use a canary build of Magisk to make your own patched boot.img. There is an Amlogic quirk that probably affects many slot A only devices. Amlogic uses the suffix 'normal' rather than '_a', which is not recognized by Magisk. A patch was added to ignore the suffix in canary build ~24.310.
When patching the boot.img with Magisk, choose recovery mode and leave vbmeta unchecked. Using the regular boot mode (not recovery mode), results in a mount/unmount loop during bootup. The cause of this will have to be worked out long-term for a persistent root. Right now SU works for Magisk but Zygisk doesn't. I'm not sure if that is a limitation of loading Magisk with fastboot boot, or because recovery mode is being used to create the patch.
You will also want to enable UART output from the kernel. This will be applied to your Cube automatically by choosing bash menu 1) boot to FireOS with ADB root / permissive. You can do it manually by booting to fastboot
Code:
fastboot oem flags fos: 0x4
The flags are stored in IDME and can also be changed directly there
Code:
fastboot oem IDME fos_flags 0x4
The IDME values will persist without the exploit, but values like
ADB root and DM-verity off will be ignored/rejected by the native bootloader when uboot determines the Cube is not an engineering device (defined as ARB=0). But the console enable value will be accepted, letting you see native FireOS uart output.
EDIT: I added the 31 IDME properties that can be edited
Pro-me3us said:
With this design, does the Cube end up powering two ICs, the one on the dongle and the one in the TV HDMI port? Are there any issues having the Cube power both?
Click to expand...
Click to collapse
I don't think current draw is a problem. A 24c02 eeprom draws 1 mA max when reading, and 5 μA max when in standby. Even if both eeproms on the bus were read at the same, that would not be a lot of current. There is only one read operation of each serial device per power cycle.
Consider another edid emulator with passthrough, the gofanco prophecy. The gofanco emulator has not only two onboard 24c02 eeproms, but also a 3AQ20 MCU and a hc4052 mux/demux IC, all powered by the hdmi port.
Pro-me3us said:
You'll need to use a canary build of Magisk to make your own patched boot.img. There is an Amlogic quirk that probably affects many slot A only devices. Amlogic uses the suffix 'normal' rather than '_a', which is not recognized by Magisk. A patch was added to ignore the suffix in canary build ~24.310.
Click to expand...
Click to collapse
Thanks. I didn't realize that 24.310 was used on the supplied image or that a recovery style patch was required. Now it all works.
Pro-me3us said:
The flags are stored in IDME and can also be changed directly there
Code:
fastboot oem IDME fos_flags 0x4
The IDME values will persist without the exploit, but values like
ADB root and DM-verity off will be ignored/rejected by the native bootloader when uboot determines the Cube is not an engineering device (defined as ARB=0). But the console enable value will be accepted, letting you see native FireOS uart output.
EDIT: I added the 31 IDME properties that can be edited
Click to expand...
Click to collapse
Thanks for the list of IDME properties. I'm getting up to speed now. It's quite different than the typical amlogic setup. No env or vbmeta partitions. There doesn't seem to be any vulnerabilities like the uboot/rsv exploit used for the gen 1 cube.
goapy said:
I don't think current draw is a problem. A 24c02 eeprom draws 1 mA max when reading, and 5 μA max when in standby. Even if both eeproms on the bus were read at the same, that would not be a lot of current. There is only one read operation of each serial device per power cycle.
Click to expand...
Click to collapse
Oh ok that's a minuscule amount. I think HDMI ports are rated for 50-300mA output. Are you able to passthrough 4k 30FPS, 60FPS (Youtube for example) with the one of those connected? Or DV/HDR? I'm curious if a dongle like that could be left in for regular use of the device.
goapy said:
Thanks for the list of IDME properties. I'm getting up to speed now. It's quite different than the typical amlogic setup. No env or vbmeta partitions. There doesn't seem to be any vulnerabilities like the uboot/rsv exploit used for the gen 1 cube.
Click to expand...
Click to collapse
Yeah an ENV partition would have made things a lot easier. Most Fire devices are MediaTek based, and the Cube is sort of alone in the use of U-Boot. There's also the 1st gen Cube and Pendant, but they are getting hard to come by. Frederic's exploit will probably work for any G12A/G12B/SM1 SOC from Amlogic, including the 1st gen Cube and Pendant, but I don't have one to test and make the necessary modifications. Amazon no longer sells these two models, and I'm assuming they also lost DFU access with the February/March update.
I think the uboot/rsv exploit got patched pretty soon after the FireFU release. I also checked aml_emmc_partition.c for the 2nd gen Cube and it was patched by the release version 7.2.0.4.
There is the u-boot vulnerability database. I don't know if any of these are present or useful on the Cube, testing them is above my skill level. I was only able to apply Frederic's exploit to the Cube because he documented everything very well.
I've posted a draft of the raven exploit on github with a little more information. I still need to edit it a bit, but the outline is there.
Pro-me3us said:
Are you able to passthrough 4k 30FPS, 60FPS (Youtube for example) with the one of those connected? Or DV/HDR? I'm curious if a dongle like that could be left in for regular use of the device.
Click to expand...
Click to collapse
It all seems to work so far. All 19 lines are wired as passthrough. The passthrough hdmi ddc link doesn't seem to be bothered by having a non-standard i2c address eeprom on the bus.
Pro-me3us said:
I've posted a draft of the raven exploit on github with a little more information. I still need to edit it a bit, but the outline is there.
Click to expand...
Click to collapse
That's a very illuminating writeup. It instantly filled in a lot of holes in my understanding.
That also seems to have been quite a lot of work, thanks again for sharing it all.
Isn't that most projects, more work than initially anticipated
I did all my testing with the ribbon cable to the physical buttons disconnected. Can you check something for me since you have UART access with the buttons active?
When in FireOS, holding down the Cube action button (button with dot) for 15sec kills all processes and appears shut the device down. But the device is not powered off, the mute button still turns on/off. If you boot into FireOS with the adb root/permissive option, what does the UART output say when doing this?
In this mode, if I press the action button again the Cube reboots, but if I press any of the other buttons, and then action, the Cube does not reboot. So I'm wondering if the Cube is being dropped into some sort of diagnostic that may be accessible from UART.
I'd be interested in seeing any of the UART output including the reboot string
Code:
G12B:BL:6e7c85:2a3b91;FEAT:F2FB39B0:432060;POC:7;RCY:1;USB:3;
I don't know if there are any hidden button combinations when powering the device on that do anything. I'm not sure where that would be defined in the source code. Holding the vol - button during bootup puts the Cube in safe mode. I don't think there are any other known power up button functions yet.
Pro-me3us said:
When in FireOS, holding down the Cube action button (button with dot) for 15sec kills all processes and appears shut the device down. But the device is not powered off, the mute button still turns on/off. If you boot into FireOS with the adb root/permissive option, what does the UART output say when doing this?
Click to expand...
Click to collapse
I'm pretty sure that I executed the sequence described above. Advise If the following is not the correct sequence;
1. boot into FireOS with the adb root/permissive option
2. after fully booted, hold the action button for 15sec
3. after shutdown, try alternatively pressing buttons other than the action button
4. compare the results (of initially pressing buttons other than the action button after shutdown) to pressing the action button without first pressing other buttons.
Code:
=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2022.06.08 16:45:42 =~=~=~=~=~=~=~=~=~=~=~=
idme_platform_write block_offset=3e7000, capacity=400000
fos_flags set to 87
idme_platform_write block_offset=3e7000, capacity=400000
dev_flags set to 64
cmd cb_download is download:008f2800
Starting download of 9381888 bytes
.......................................................................
downloading of 9381888 bytes finished
Booting kernel...success
boot_addr_start bootm 0x1080000
kernel_size 0x8af0af, page_size 0x800, totalSz 0x8b0000
ramdisk_size 0x0, totalSz 0x0
dtbSz 0x42000, Total actualBootImgSz 0x8f2000
amzn_verify_onetime_unlock_code: Verify one time unlock cert fail, ret = -5
ee_gate_off ...
## Booting Android Image at 0x01080000 ...
reloc_addr =73d75610
copy done
Kernel command line: rootfstype=ext4 ro rootwait skip_initramfs OTG_mode=DEVICE androidboot.selinux=permissive
load bootimage dtb from 0x74625610 ......
.
.
.
[ [email protected]] input input0: key 138 down.
.
.
.
[ [email protected]] vendor_write_shutdown_reason: shutdown_reason 0x0
[ [email protected]] hdmitx: hw: avmute set to 2
[ [email protected]] ISSI: resetting device before reboot!
[ [email protected]] meson-mmc: meson_mmc_clk_set_rate_v3 269
[ [email protected]] meson-mmc: actual_clock :0, HHI_nand: 0x80
[ [email protected]] meson-mmc: [meson_mmc_clk_set_rate_v3] after clock: 0x10100002
[ [email protected]] amvecm: shutdown module
[ [email protected]] di pre hrtimer canel 1.
[ [email protected]] [DI] shutdown done.
[ [email protected]] vout: vout2: aml_vout2_shutdown
[ [email protected]] vout: aml_vout_shutdown
[ [email protected]] fb: osd_shutdown
[ [email protected]] amvdac_drv_shutdown: shutdown module
[ [email protected]] reboot: Power down
bl31 reboot reason: 0x108
bl31 reboot reason: 0x108
system cmd 0.
bl30 get wakeup sources!
process command 00000006
bl30 enter suspend!
Little core clk suspend rate 1908000000
Big core clk suspend rate -2086967296
store restore gp0 pll
suspend_counter: 1
Enter ddr suspend
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
The above log happened both when the action button was pressed and also when any other button was pressed instead (after shutdown). New lines containing "DMC_DRAM_STAT11: 0x24" are repeated endlessly, or at least for the 10 minutes that I let it run.
Pro-me3us said:
if I press the action button again the Cube reboots, but if I press any of the other buttons, and then action, the Cube does not reboot
Click to expand...
Click to collapse
I could not get the Cube to reboot if I pressed the action button again after shutdown. Perhaps I wasn't supposed to wait to press it until the shutdown was complete?
A reboot string never appeared, just ""DMC_DRAM_STAT11: 0x24"" endlessly until the power was cycled.
I'm still running PS7229/1856. I don't have an ota for an android 9 version of fireos that is not the current version.
If this is some sort of standby mode, I can't seem to wake out of it.
Do you happen to know why a uart command prompt console can't be started? If;
start console
is executed in a shell with root access, it appears to execute successfully, but no console command prompt appears over the uart connection.
Edit: resolved, disregard.
goapy said:
The above log happened both when the action button was pressed and also when any other button was pressed instead (after shutdown). New lines containing "DMC_DRAM_STAT11: 0x24" are repeated endlessly, or at least for the 10 minutes that I let it run.
Click to expand...
Click to collapse
Ah ok, maybe it is only a shutdown command in that case. The reboot reason 0x108 might be SHUTDOWN_LONG_PWR_KEY_PRESS according to sign_of_life_vendor.c. This looks similar to adb reboot -p which is a software shutdown (0x109?). After a software shutdown the Cube can also be rebooted with the action button. There may be no way to completely shutdown Cube without a real power button. I don't know why in this state pressing the action button doesn't consistently reboot.
Pressing the power button on the remote might also put the Cube in a similar suspension state that does allow waking.
goapy said:
Do you happen to know why a uart command prompt console can't be started? If;
start console
is executed in a shell with root access, it appears to execute successfully, but no console command prompt appears over the uart connection.
Edit: resolved, disregard.
Click to expand...
Click to collapse
I only ever used UART for logs while the kernel was loaded. I never tried to bring up a command prompt. Did you manage to get input working through UART?
For fos_flags the default is 0x0. If you are using the bash menu script it is setting the fos_flags to 0x87 each time FireOS with ADB root is booted. You will have to fastboot boot the image manually to avoid that. You can also set the Flag values with ADB root using the command 'idme fos_flags value'.
The focus was pretty narrow while working on getting the exploit working. I didn't spend much time with the bootrom. Frederic gave me most of the addresses I needed once the bootrom was extracted. I haven't heard of anyone finding extra I2C commands. Both the FireFU and Superna9999 page mention [email protected], but I don't know if that actually works.
You can take a look to see if there is anything interesting. To dump the Cube bootrom run the following command with the zipped files:
Code:
sudo ./amlogic-usbdl memdump_over_usb_s922x.bin cube_bootrom
There is also the question of what that missing 20pin connector is on the Cube PCB.