Related
http://forum.xda-developers.com/showthread.php?t=1119555
Logically speaking, this application should also work with the Bionic correct?
Just wondering, if its deemed safe in this thread to attempt using, I will try it and post back with results.
---------- Post added at 12:30 AM ---------- Previous post was at 12:08 AM ----------
Okay, so I just backed up everything and tried the app, which won't work due to the fact that it checks the phone model number, Theres a manual guide to get ubuntu running on the atrix, and I'm going to start from scratch there. Probably going to be a couple of days before I do anything since I need a new microhdmi...
I tried the app that comes with it to partition the sdcard but it does a device check then it stops with an error message that the device is not an Olympus (Atrix). Maybe we can get the dev to check on the differences, albeit small, for the Atrix and the Bionic.
Worth a shot. I've been playing around with /osh for a few days but had to reflash to stock due to the lapdock staying on the screensaver.
Hey guys, I am working on the same thing at the moment trying to port over Sogarth's method of unlocking the 10.10 maverick build of Ubuntu on our phones.
http://forum.xda-developers.com/showthread.php?t=1000316
The link here is for his old automated .bat script he made for the Atrix that I believe will work for our phones with a little modification to it to reflect Maverick packages instead of the Jaunty packages for their phones.
Please jump into the irc in my sig because I would like to get this going as well.
I would hop in IRC but I'm about to head out the door.
I'm currently approaching this situation from two directions:
1.) I'm dumping /osh/ (webtop partition) and uploading it to dropbox as soon as I can get a complete dump. (hopefully tonight) and providing it to the original Atrix dev to see if he can hook us up with an app to help do whats needed
2.) I'm also attempting the manual method as soon as I get a new microHDMI cable (I was using a cheap adapter).
You are 100% correct though, you should be able to get that install script working just by changing the packages to reflect the updated Ubuntu. MAKE SURE you backup ANY files before you change them (and preferably a complete backup of /osh/. Since we have SU on our phones we have free reign over the /osh partition, so be careful in there.
OT: I can't wait until we can get on-demand CPU overclocking for this thing... if it clocks as well as past mobile chips... Toggle 1.2-1.4ghz and plug it in the LapDock. You'd have a damned fine netbook...
(Not necessarily talking to any experienced users or noobs, the disclaimer about Linux & SU is for everyone reading this thread - I'm relatively experienced in the Linux world... and I need to be reminded of SU's power sometimes.)
I just realized that their phone's Ubuntu distribution is under the 9.x series versus the 10.x series. A lot of Major changes happened to Ubuntu between 9.x and 10.x that affected the way the operating system talked to devices and booted, they stopped using HAL and moved to a new boot method, I am uncertain whether or not the install script will work or not, though I'm somewhat confident it will, given the nature of webtop (Android does the hardware abstraction, and the booting, we just run a second set of executable's on a different X window session attached to a different display) This should mean that the portions that would normally prevent us from just duplicated the script are omitted from the Ubuntu distribution entirely. As long as we keep a backup we should still be fine.
No worries, just remember to keep FXZ and RSD handy. I've screwed up the /osh partition a couple times but that has saved me from complete disaster so far
Good call on bringing this up. Let me know if you need to test anything for this.
@xaero252
So I modified Sogarth's script to use Maverick build of all the tools it downloads and installs but the problem with the script is that it needs the phone to have the ro.secure=0 so that ADB always launches with root access without manually initiating su each line of code. I am not sure if there is a way around it or if we have to modify the script differently. Anywho, I've upload a copy of the work I've done to the script.
Is it just an sh script? If so and ut doesn't reboot the phone at all you could launch a SU terminal and do "su sh script.sh"
oh i see the issue now... we would have to be able to edit the boot loader for that method... if i'm correct though his android app doesnt use the pc for much... if you change that variable on boot do you think it woukd work?
Hmm, I have an idea, its not as polished as the pc based script, however it should still work presuming you can get a SU terminal to run on the phone ( I happen to have one running right now ) I'm going to see if I can't adapt that to a bash script. probably going to take a while.
Curiously we happen to have a 1.5gb partition for Ubuntu on built in memory, where as the atrix only had a 600 or so mb partition... This is great because we should likely be able to continue to install /, /boot and such to internal memory, and use the sd card (even left as ntfs) for /home...
Couple of things: reading through the script it looks like 100% of the commands he runs could be run on the phone via a bash script run as su. The idea is this: convert the entire script over to bash, copy the script, and the required files to the phone, and execute the script from the phone. The only other concern I can see is the wget package included with the script not being compatible with maverick, which doesn't seem likely.
I'm gonna start working on rewriting the script linux native. My idea is to use a terminal emulator (they are free on the market) and run su script.sh and pray. I need to get a new microHDMI before I do this though, so I can test my results reliably.
xaero252 said:
Is it just an sh script? If so and ut doesn't reboot the phone at all you could launch a SU terminal and do "su sh script.sh"
oh i see the issue now... we would have to be able to edit the boot loader for that method... if i'm correct though his android app doesnt use the pc for much... if you change that variable on boot do you think it woukd work?
Click to expand...
Click to collapse
As far as correcting that, no one has attempted doing custom kernels yet so to do the edit to get root access out of the gate is moot at this point.
Hmm, I have an idea, its not as polished as the pc based script, however it should still work presuming you can get a SU terminal to run on the phone ( I happen to have one running right now ) I'm going to see if I can't adapt that to a bash script. probably going to take a while.
Click to expand...
Click to collapse
Your linux skills are probably 10 folds better than mine but I believe if you convert my modified script, which has all the necessary links to the correct packages for our phone, then it might just work.
Curiously we happen to have a 1.5gb partition for Ubuntu on built in memory, where as the atrix only had a 600 or so mb partition... This is great because we should likely be able to continue to install /, /boot and such to internal memory, and use the sd card (even left as ntfs) for /home...
Couple of things: reading through the script it looks like 100% of the commands he runs could be run on the phone via a bash script run as su. The idea is this: convert the entire script over to bash, copy the script, and the required files to the phone, and execute the script from the phone. The only other concern I can see is the wget package included with the script not being compatible with maverick, which doesn't seem likely.
Click to expand...
Click to collapse
The WGET I packaged in the .zip is the correct for Maverick along with all the files in the \bin directory are corrected to match our phone. If you can convert all this to a bash script, that would be awesome instead having to do each command via ADB Shell. The only problem I had with this is every time I tried to run the DPKG command on the .deb I downloaded manually, it threw up an error saying it could not find the file or destination.
On a side note, you are correct that we have 1.5gb partition opposed to their 700mb so we could honestly forget the part about creating a ubuntu.disk on the /data partition and modify the /osh directly for now until the time we need more space. After that, we can see if Sogarth will incorporate your script into his Webtop2sd app or we could make a 3gb ubuntu.disk on the /data partition since we have plenty of space there.
I'm gonna start working on rewriting the script linux native. My idea is to use a terminal emulator (they are free on the market) and run su script.sh and pray. I need to get a new microHDMI before I do this though, so I can test my results reliably.
Click to expand...
Click to collapse
Make sure you get the adapter as well to trigger Webtop cause at the moment our phone wont do webtop directly over HDMI without the HD Dock, Webtop adapter or Laptop dock. If you want to test the script out for now, hit me with the script and I will test it for ya
Ok, this goes out to any and all DEVs out there. We all know by now that we (some people not me) can run linux within android using the loop mounts, vnc viewer, etc... Now how about REPLACING android with a linux distro like debian or maybe even what these guys use http://openpandora.org/ ..... its linux based and has an arm CPU.. Any way I'm talking about flashing over android wiping the internal sorage and installing linux on it or even using the boot loader to flash over android???, of course this is getting rid of any 3g connection and phone usage. I understand that, I am talking about giving our RETIRED droid 1s a use. I wanna see my D1 run a linux distro in full hardware mode NO MORE ANDROID. now dont get me wrong I love android as much as the next guy, but why now flash something else to it???
Another link I found, this is for windows mobile but hey, similar idea.
http://wing-linux.sourceforge.net/trac/wiki/FAQ
P.S. I AM NOT A DEV JUST AN IDIOT WITH AN IDEA!! my ignorance is NOT bliss and I would love to know if this is even possible. I'm willing to help ANY WAY I CAN. lol
THANKS!!!
I don't think it's possible. Because of the locked bootloader we're forced to use Motorola's bug-ridden Kernel and as Android's Kernel is a heavily modified Linux Kernel it most likely won't run an ordinary Linux distro.
But I'm no expert either
Milestone is locked, Droid is not ...
Maybe this will help (if you don't know german, you can use Google Translate):
http://www.android-hilfe.de/anleitu...debian-chroot-mit-lxde-auf-dem-milestone.html
Thanks for the replies. Again the USA Droid 1 is nit locked or at least has been completely unlokcked. I've read a million "run debian on android" posts... I don't need to know German to see that the post above is the same thing. Like I said before I have NO INTEREST IN RUNNING LINUX ON ANDROID. I want TO REPLACE android completely with Linux to make a device like the openpandora handheld from my first link.
Any one up to the challenge????
Thanks again!
Really, no one??
I've been running Debian on my Droid booting from the SD card for a while, more recently trying Arch Linux after realizing that anything optimized for ARMv7, VFPv3, NEON, or Thumb-2 (I'm not sure which unfortunately) won't boot because of a page fault or something. Ubuntu, MeeGo, and Angstrom just kernel panic and don't give any useful information even at the highest debugging level. I'm back to using an ARMv5te Arch Linux build (http://archlinuxarm.org) although I could just as well use Debian. I really wish Ubuntu worked for multitouch.
Well, I got the touchscreen calibrated! I forgot that my screen rotation hack only rotated the framebuffer It's stuck in portrait for now. I decided to use mtev (MeeGo's multitouch X11 input driver) after being fed up with evdev's aversion to being rotated, but now that I'm back to the stock portrait rotation evdev should work fine.
If you want instructions, either PM me or wait until I post a full guide and/or my patched kernel tree. It's not super difficult, but it's a lot of command line use and compiling.
What works:
*CPU and SD card (obviously )
*Touchscreen (single touch/portrait only for now)
What needs work:
*Keyboard mapping is wrong, the number keys and symbols don't work. I need to figure out how Android handles Alt. I had to patch the GPIO keyboard driver because the keyboard worked in the console but not in X11, which expects EV_SYN.
*Sound is OSS only, but there is no mixer device, so aumix is useless and there's no volume control or sound output.
*I haven't tried the SGX driver, so I can't comment on hardware acceleration yet.
*Battery charging relies on battd, which is a proprietary Android binary from Motorola. It might run on Debian with "ls -s / /system" and the creation of the socket it expects (init.sholes.rc I believe), but I'm not getting my hopes up.
Untested:
*WiFi (needs firmware, but should work)
*Bluetooth
*Calls/data
*Sensors (although the accelerometer and compass seem to be recognized by evdev)
I'll upload my kernel, either as patches or on GitHub (or binaries if there's enough demand) once I get around to fixing the keyboard issue. Fingers crossed that I don't get carried away cleaning up the kernel, or worse yet, give up...
This is incredible news! I'm so glad to hear it. Of course you are running in hardware mode? Not through android? If so I'm super exited about this! I love arch Linux, I run it on all my computers and I understand it more than any other distro I've tried. I would love to give it a shot, though I'm not that great at compiling I think it will be worth it.
As I said before I am in no way a dev or even a Linux pro, but I can get by and if theres any way I can help this project become "complete" I'm willing to learn what ever is necessary to do so.
Also were u able to get an x server running? Possibly a DE? That would be crazy awesome.
Thanks a million, looking foreword to work with you and make this happen!
For anyone who's interested, I put together a quick package containing my kernel patches, configuration notes, and an automated kernel build script.
It's pretty self-explanatory aside from the installation of the root filesystem, which I leave up to your imagination
As I've probably repeated several times now, I've run Debian and Arch Linux natively on my Droid with my patched kernel (no chroot or VNC "hack"). With enough determination, it's possible to run practically anything on it - personally, I'm determined to get Ubuntu on it.
WOOT... insta-fail for me LOL you have it set up to work in specific directories? I thought i placed everything right but I guess not.. I got an error on the first line of output lol
Welcome to gTan64\'s lazy Droid kernel compiler\!
build.sh: line 5: [: missing `]'
build.sh: line 5: -z: command not found
build.sh: line 5: -z: command not found
Entering $WORK
Applying patches
build.sh: line 16: /*.patch: No such file or directory
mv: cannot stat `/arch/arm/boot/compressed': No such file or directory
cp: cannot stat `/compressed': No such file or directory
Setting up build
cp: cannot stat `/GNUmakefile': No such file or directory
cp: cannot stat `/sholes_config': No such file or directory
FIXME! No numeral or symbol input until someone finds a third-level
modifier key to use instead of AltGr for the keyboard.
cp $MISC/defkeymap.map $K_SRC/drivers/char
Building kernel!
make: *** No targets specified and no makefile found. Stop.
Kernel build done!
You have done something amazing, I'm just to stupid to figure it out my self. XD
I can understand why you would want ubuntu with all its pre-setup glory and support for nearly all hardware but dont you think its a little heavy for this hardware? lol I doubt you would try to use the Unity UI but I doubt that alone would even fit in ram LOL you could just use the ubuntu packages and drivers with debian maybe?
THANKS AGAIN!!!!
That's what happens when I don't test my own scripts
I was thinking too much about making it easy. Just try applying my patches to your tree manually.
Code:
cd kernel_src
patch -p1 <../patches/first.diff
patch -p1 <../patches/next.diff #and so on...
#Obviously, substitute the paths of the actual patches ;)
#Finally, copy sholes_config to .config and invoke 'make'.
It's actually much simpler than my script makes it, and you don't need my convoluted folder setup.
UM lol I cant find any patch files? are they in the ZIP? or do I have to obtain them elsewhere?
I can tell this is gonna be a hell of a project LOL
THANKS!!!
"Duh" moment - I used the .diff file extension instead of .patch
I'm such a scatterbrain... Remind me not to release anything before testing
EDIT: Strike that, reverse it. They're .patch files.
I AM BLIND lol I found them... BUT.. when I try to patch. terminal just seems to lock up... I press enter, the curser moves to the next line but it doesnt do anything. lol how long should 1 patch take?? its been about 10 minutes and I leave it be for now
EDIT:
LOL i forgot the "<" in the command OOPS but I'm not seeing any .config file or folder in the source to copy the sholes_config too. yes I have show hidden files on.. PS unfortatly usinf Fedora 15 gnome 2...... (on server so I can work on this anywhere through vnc )
THANKS
When I said "copy sholes_config to .config", that's literally what I meant. .config is the Linux kernel build configuration file, not a folder.
'cp /path/to/sholes_config .config' from your kernel tree should do it.
Oh, I forgot to mention that you need an ARM cross-compiler/toolchain. I use the gcc-arm-linux-gnueabi package in Ubuntu, but I don't know what the Arch equivalent is off the top of my head.
The "GNUmakefile" is just a convenience, it exports "ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-" before calling the actual makefile. If you don't have an ARM cross compiler in your path, it won't build at all. If you do, modify CROSS_COMPILE to point to it - on some systems it's called arm-unknown-linux-gnueabi, etc. etc.
Let me know if you get anywhere before it errors out.
OK I put the config file in the kernel_src but unfortainatly I'm using Fedora 15 XP I installed arm-gp2x-linux-gcc which is the fedora arm gcc I guess... lol so wha would I edit in the .config to make it point to arm-gp2x-linux-gcc. Its not my first attempt to compile an android kernel but I've never been succesfull LOLOL
thanks
I'm pretty sure that toolchain won't work - the GP2X was ARMv5 IIRC, so unless it's a newer build of GCC (4.3 or higher) and you're absolutely sure it supports the ARM EABI and the ability to generate ARMv7 instructions (which is unlikely if it's pre-4.1), I would recommend a newer toolchain.
CodeSourcery makes a pretty solid one: https://sourcery.mentor.com/sgpp/lite/arm/portal/release1803
If you end up using it, you can change the second line in GNUmakefile to "CROSS_COMPILE=arm-none-linux-gnueabi-". Don't worry about changing .config.
Well I DLed the linux/GNU installer and it gave me "arm-2011.03-41-arm-none-linux-gnueabi.bin" LOL
so I was thinking would it just be easier to just use my lappy with crunchbang (debian based) so I can follow ur instructions with deb / apt-get LOL fedora is a ***** and it dont have what I need... I cant find an arm v7 cross compiler for it
thanks
.bin files are the Linux equivalent of Windows EXE installers. Run it like this:
Code:
#cd /path/to/installer.bin
./installer.bin
#substitute the actual name, of course.
It needs root permissions if you want to install it to /usr/local (sudo ./installer.bin or su -c 'sh installer.bin'). You can also install it to /usr, but that will make it more tedious to uninstall later. If you decide to install it in your home folder - say ~/toolchain - you don't need root permissions, but you will need to add ~/toolchain/bin to your path:
Code:
export PATH=$PATH:$HOME/toolchain/bin
To be honest, I prefer Ubuntu to Fedora/OpenSUSE/$RPM_distro, so if you have access to a Debian or Ubuntu system, using that would make my life easier
Omg duh... the "non_Linux" part of the name true me off lol i'll start doing this on my laptop it's deb based crunchbang. I prefer anything over rpm distros too but it was a quick painless install on my server XP thanks ill try this when I get home
Sent from my DROIDX using XDA App
Hello everyone! Just like others here, I've been somewhat spooked by our inability to enter Ouya's Recovery partition at the earliest stage of booting, meaning a bad flash of the Boot partition would leave the device inoperable. When I heard that Ouya's stock firmware updates were possibly bricking a few units out there, I decided to block updates on mine and see if I could transform the Boot partition such that it would become a logical extension of the bootloader. What I ended up with is something close to the "Ouya Safe Recovery" project, where a user should only need to flash Boot one additional time, along with chain-loading support as well.
Chain-loading in this case refers to the booting of ROM kernel images that reside as regular IMG files under the /sdcard and/or /system filesystems. With this capability it is possible to choose an image to run when the Ouya turns on. As an example, one may wish to set up a 2nd/test kernel+ramdisk image to use with your installed ROM, or he may wish to run Tuomas Kulve's Debian project from time-to-time without having to set up the USB cable for Fastboot mode. When dealing with distinctly different ROMs (not just alternate kernels), only one of them may install to the Ouya's built-in storage (e.g., /system); others must have been designed/created to use external storage.
An image for the Recovery partition is available along with the Boot. The former may be helpful if you wish to try out the boot menu before performing the flash of the Boot partition, or are generally okay with bouncing to Recovery before invoking a chain-load. Either of these may be tested from Fastboot mode, but do note that a successful chain-load requires that the image actually be flashed to the Ouya. (Otherwise it just reboots.) The ClockworkMod (CWM) recovery application is available on both images and is accessible from the boot menu.
Additional Information
There are a few things to consider when deciding if this approach makes sense for you:
- Users of the "Ouya Safe Recovery" project may want to stay put unless the dual-boot aspect is of interest. If so then it would be cleanest to choose my Boot image; the Recovery partition (your ROM image) could be left alone.
- The images here are not compatible with Ouya's stock firmware, due to the auto-update nature of Ouya's ROM. Either your flashed Boot image would get overwritten, or an installed non-Ouya Recovery might cause that update to hang. Therefore, you should be prepared to switch to one of the ROMs here at XDA. If you're currently on stock and don't want to switch right away, that's fine; we'll go over how to block updates for the time being.
- The Ouya CM10 ROM is nice in that it provides the IMG file separately, allowing us to handle it as we wish. However, the other ROMs end up placing their boot.img in the main ZIP. This is standard practice for other devices, but we need to be careful ensuring our Boot partition doesn't get reflashed as part of the ROM installation. Therefore, it would be necessary to investigate repackaging the ROM with an alternate updater-script prior to installation. See my StockPlus post on page 2 for more. (This shouldn't affect those who've opted for my Recovery image.)
This feature is based on CWM's initial ramdisk, and includes a new boot menu application that comes up prior to CWM itself. Basically, CWM shows up later if the menu application exits for any reason. The Ouya stock kernel (561) has also been compiled with HDMI's copy protection turned off, and includes two patch sets:
- KExec-HardBoot is the key to chain-loading on our platform. It overcomes standard KExec's lack of hardware reset (and thus failed execution) by triggering a reboot in the middle of the preparation of the new kernel. This ingenious system has been developed by Tasssadar and others over in the Nexus forums. (Be sure to enable CONFIG_TEGRA_HARDBOOT_RECOVERY if interested in compiling a Recovery kernel.)
- HDMI visual stability has been improved with a little hack of mine: a significant relaxing of a timer in the driver. (The latest Android source has corrected the instability with a significant design change, but my hack seems fine enough for this project.) Also picked up specific Android fixes in the area of Framebuffer double-buffering, as that needs to be working for CWM usability.
Installation
If you're on Ouya's stock firmware, then you should make sure that any future updates do not get applied. There is a project here ("Mod Collection For Ouya") that should help. I personally side-loaded the Baxy custom launcher to avoid Ouya's update environment. It is also likely necessary to stay out of the Ouya/Discover store if going the custom launcher route as I believe the store app can trigger an update.
At this point you can download your chosen image (Boot or Recovery) and unzip to get the IMG file. Boot your Ouya to a working Root/BusyBox environment (ROM or Recovery), and then transfer the IMG to the Ouya. (An example using ADB would be "adb push boot102513.img /sdcard/boot102513.img".)
Bring up the Ouya command prompt (e.g., "adb shell") and run these commands to get started:
su [command not present on CWM - that's okay]
cd /dev/block/platform/sdhci-tegra.3/by-name
ls
You should see the various 3-letter partition names from that last command. Your command prompt should also contain the "#" character to denote root-level access. This next step will save off your current ROM image, both because we may end up overwriting it, and because the saved file will end up as your main bootable kernel for the chain-loader. Run:
cat LNX > /sdcard/kernel.img
(If configured for "Ouya Safe Recovery," then replace the preceding "LNX" with "SOS".)
We are near the flashing stage. Check to make sure your Ouya has a reliable source of power, preferrably from an uninterruptable power supply. Recall that a bad flash of my boot image can leave the device inoperable, but I feel the risk is very low provided the following directions are heeded. Fortunately the flash process only takes a few seconds.
For the Boot image option, verify by running:
md5sum /sdcard/boot102513.img
Do not proceed unless you get "e4b1b1ad553e55ad0b2ce3fb8f5bf623".
Again for the Boot image option, flash to the Ouya by running:
dd if=/sdcard/boot102513.img of=LNX
For the Recovery image option, verify by running:
md5sum /sdcard/rcvy102513.img
Do not proceed unless you get "dda0811a7e8e82a7d4ad3fa4c3ae35e4".
Again for the Recovery image option, flash to the Ouya by running:
dd if=/sdcard/rcvy102513.img of=SOS
You may optionally verify (post-flash) by running "md5sum" on the partition name. Finish up with these commands:
sync
reboot
Usage / Configuration
The menu should come up, defaulting to "kernel.img" for the Boot image and "CWM" for Recovery. That default will then launch after ten seconds of inactivity. You may also briefly press the Ouya power button during the wait to advance through the options. The option list is 1) kernel.img, 2) kernelA1.img, 3) kernelA2.img, 4) CWM, and 5) Recovery Partition.
The defaults from above should be fine for most everyone, but it is possible to fine-tune them. An optional configuration file (/sdcard/bootmenu_b.cfg for Boot, /sdcard/bootmenu_r.cfg for Recovery) may be established to specify the default menu entry as well as the inactivity timeout. As an example, the following command would make Recovery start kernelA1.img after five seconds:
echo "2 5" > /sdcard/bootmenu_r.cfg
It is hoped that the menu would never hang. If it does, then waiting a full minute should allow CWM to start. Otherwise, it may be necessary to attach a wired/USB keyboard and type in the Alt-SysRq-X sequence, similar to Ctrl-Alt-Delete on a PC. The sequence might have to be done early on in the menu startup process, and should blink the Ouya light and place it in Fastboot mode.
The menu may unexpectedly place you in CWM, which would indicate an issue with a chain-load. The reason may be due to a missing or corrupt IMG file. Otherwise you should be able to determine why by checking /tmp/bootmenu.log against the attached source code.
---
I hope this project will be of help to others!
An additional support forum that everyone should be able to post at is available: http://forum.xda-developers.com/showthread.php?t=2450711.
Wow, really great. Thanks a lot for your effort
Gesendet von meinem One X+ mit Tapatalk
nchantmnt said:
Wow, really great. Thanks a lot for your effort
Click to expand...
Click to collapse
My pleasure, nchantmnt. Hope your new Ouya is helping you feel at home!
Yes im happy it already arrived, but after a second miscarriage and lots of stress because of a lawsuit with our neighbour i didn't have time nor nerves to play or code. Seriously this year sucks
Gesendet von meinem One X+ mit Tapatalk
nchantmnt said:
Yes im happy it already arrived, but after a second miscarriage and lots of stress because of a lawsuit with our neighbour i didn't have time nor nerves to play or code. Seriously this year sucks
Click to expand...
Click to collapse
Gosh, I'm very sorry to hear that. Do think ahead to the upcoming holiday season, and may it be a time to reflect and anticipate a fruitful 2014.
@Hal9k+1 - THANK YOU!
I was so nervous flashing CWM and StockPlus as there is no real way to fix things if something goes wrong. This should give people more confidence when flashing their Ouya.
I understand the process using ADB...my question is: can this be used from CWM somehow?
PS. I assume new kernel will always be flashable from CWM, the hack does not require 561 specifically.
Ipse_Tase said:
I understand the process using ADB...my question is: can this be used from CWM somehow?
Click to expand...
Click to collapse
Hi Ipse_Tase - I do hope the feature will be helpful to you and others.
As I think about your question, I suppose I could have have created a ZIP that would have been installed by CWM. Similarly I could have worked through some form of installation shell script. But for an important operation such as flashing, I prefer the one-at-a-time approach of the interactive shell.
Note that CWM does have an ADB service running with it. Your Ouya would show up as a different device while in CWM, so you'd need to enter Device Manager (Windows) and point the unknown device to the same ADB driver as used for the main ROM.
Alternatively you could skip ADB for this Ouya Boot Menu installation and set up an SSH server on your main ROM. I personally have installed "SSH Server" (Ice Cold Apps). I recall two screens to set up (does require the trackpad in cases), where I enabled automatic start on both, and also set the port number to 2222. After an Ouya reboot I had SSH/SCP capability and could use PuTTY/pscp from Windows.
Hal9k+1...fast reply, thank you.
Just to put my ever-so-senile brain at ease: so I run StockPlus 519r1, and WHILE in the ROM, I start ADB and follow your instructions .
OR...I enter CWM, make sure I get the right ADB drivers installed for THAT instance and go from there.
For a developer, I'm sure it's easier and more familiar to run ADB commands - for people like me (5%-over-the average-user) a CVM option to flash a zip and do all this would be more in-line with the abilities to hack.
I have rooted 4-5 devices so far and the only time I type any ADB commands is at root/unlock time - sometimes not even then (Nexus 4 and the Root Toolkit).
So if you ever consider creating a recovery flashable file, it would help many. Probably not me, as by then I would have done the ADB trick
Sounds like great work! I was hoping to implement something like this myself, but I haven't made any more time for OUYA-related development in a while (due to positive life events/busyness)
I will definitely take a look at your work when I have time!
~Troop
Ipse_Tase said:
Hal9k+1...fast reply, thank you.
Just to put my ever-so-senile brain at ease: so I run StockPlus 519r1, and WHILE in the ROM, I start ADB and follow your instructions .
OR...I enter CWM, make sure I get the right ADB drivers installed for THAT instance and go from there.
Click to expand...
Click to collapse
You got it! You don't need to worry about booting to the other partition prior to flashing. That is a given partition (LNX/SOS) is no longer being accessed once the image is booted. For CWM's ADB, you'd simply point Windows to the same INF file that you originally used. Hope this helps.
StockPlus Installation
Well, I finally retired this old stock 393 ROM I was on, and moved to StockPlus 519r2. I was not able to install it the normal way given my Boot image is in place here. So I ended up modifying "updater-script" under META-INF/com/google/android, and then repackaged prior to running the install procedure. I'm attaching my changed version in case it helps anyone, and please note that it makes StockPlus the main image (kernel.img).
(You'll need to right-click to save the attachment. Once done it will need to be renamed such that it does not include the ".txt" suffix.)
The Windows "7-Zip" utility is helpful for packaging. You may start by right-clicking the downloaded ZIP, then 7-Zip --> Extract to "OUYA_[...]". Enter the newly created directory, get to the updater-script, and replace it with mine. Now back up to the area with META-INF, system, and boot.img, still in the new directory. Select all three under Windows (Ctrl+Click), right click that area, and then 7-Zip --> Add to "OUYA_[...].zip". Be sure this new ZIP is the one that makes it to the Ouya.
Still haven't tried this out yet, but I hope to soon.
I missed out on news over the holidays though and just noticed this:
Announcing Ubuntu and Android dual boot developer preview
http://developer.ubuntu.com/2013/12/announcing-ubuntu-and-android-dual-boot-developer-preview/
I'm curious of their dual boot implementation and how it compares and if we can synergize with their approach, but haven't looked into the details of how theirs works yet (its sounds like it uses a custom recovery image, and they have the ability to trigger it to reboot into Ubuntu from an Android app and vice versa, which is cool)
It'd be awesome to be able to multi-boot an Ouya ROM, an Android ROM (CyanogenMod), and Ubuntu with that kind of ease.
EDIT: This may be more our speed though: (MultiROM)
http://forum.xda-developers.com/showthread.php?t=2011403
(did you pull anything from there? Sounds like they have a modified TWRP that can flash zips to the other ROM slots, which is something I was also hoping to implement)
~Troop
Thanks, Trooper. Good to see Ubuntu moving further along in the mobile world.
I briefly looked at MultiROM since it originated from the KExec-HardBoot work, but decided not to go in that direction. The main reason is that I decided not to pursue the setup/learning of an Android build environment, but also because it wasn't clear how I'd deal with our lack of a touchscreen and lack of volume up/down buttons. I ended up creating a small application that fits within Ouya's CWM framework and starts up before CWM itself; it monitors the power button for click events and writes to the framebuffer memory region using regular Linux calls.
I'm not too concerned about the dual-boot aspect of this new Ubuntu, but the lack of touchscreen could be a hindrance if mouse/keyboard were not a viable substitute. Whether this Ubuntu is designed to work from external storage is another question, since our /system and /data would be occupied by Android. But in general I think we could boot it from my framework, and if my Boot image were selected over the Recovery one, then the Ubuntu kernel could reside in Recovery and also be bootable from the Android side with the "reboot recovery" command.
Best of luck, and hope you'll have a chance to try it all!
accidental post please delete
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
Hi everyone,
Today I'd like to dust an old subject that was quite discussed: emulating a custom Android ROM.
There are in threads arround here or in some Stack Overflow subjects (for instance) peoples talking about this, providing ideas or even complete tutorials.
These tutorials show how to use the SDK tools to create an Android Virtual Device to run the desired ROM.
But all these informations are purely deprecated and can't be applied exactly for new touch phones (higher than Jellybean you can't do that!)
Didn't realizing it yet and wanting to try it out I personnally downloaded the latest Android Studio software with the basic SDK tools.
I tried to run commands specified in the tutorials to test some things out (like creating an avd) and actually creating an avd this way is purely deprecated. Well.
What a good start.
So instead I used the avd tool of the Studio software and I successfully created one.
Got into the C:\Users\%USERNAME%\.android\avd\avdname.avd folder to check components of the avd. I even read .2cow things files to know the location of the missing components (like system.img)
So I am almost done. I prepared my .img files to replace avd img basic components to test my emulated firmware out. But...
I have no idea where to start!!
I am missing some img files that would be necessary to run the avd correctly, like the kernel.img or userdata thing...
I just don't know what to replace or not, how to obtain necessary files without breaking something, I need help...
Here is finally the question of the subject:
Can somebody post out a complete updated tutorial on how to emulate a full custom rom using the AVD tool provided by Android Studio, please? (If possible of course)
This would be really nice and pretty useful for ROM development. I'm still experiencing things, trying to modify the close-to-my-devive avd I generated but this is just messing arround with things, I am pretty inexperienced so I don't think I could help...
Ok, no contribution as expected...
Fortunately I started reasearches despite the fact that I'm not a dev so I have a really really little idea of what I'm doing...
So here are what my researches led to (report with my memory, I will re-edit my post soon to add what I missed) :
Note: I used my SM-G361F pre-rooted ROM to test emulation.
==========*#1*==========
Operations:
•Created a close-to-device AVD (Same API Level etc.)
•Found out AVD dependencies folders: [C:\Users\%USERNAME%\.android \avd\x86 (I guess?)\(devicemodel).avd then another location containing kernel, system.img etc. thanks to .qcow2 files in the previously presented folder ("link" were in.)
•Made a backup of these folders **obvious**
•Edited some configurations (config.ini etc.) to make the final emulated system as close to the real device as possible to avoid incoherences
•Replaced some components of the AVD (build.prop, cache.img, userdata-qemu.img, etc.)
•Replaced the system image in the second folder
•After an hard struggle to get boot.img file of my device, decompiled it to get the ramdisk.img and kernel.img I used to replace kernel-qemu
Test:
•Starting the AVD from Android Studio
=> Outputs option "repair device"
•Attempted a repair: selected... My device SM-G361F to repair.
(=> Weird...)
•Repair seemed to work well according to the fact I could run the AVD
•Statut of the AVD: Black screen. Using power button and all doesn't make anything working: the AVD doesn't react.
=> Quiting made the emulator crash
Initial reason: see troubleshooting section
Result: FAIL
Troubleshooting:
•I shouldn't had to replace kernel-qemu by the stock extracted kernel: it has nothing to do with the actual system because it isn't purely system but device related. Will fix that next time
•ramdisk was badly recompiled: after extracting it from boot.img using Android Image Kitchen I recompiled it with the recompile.bat that ouputs two files: img-new.img (cannot figure what's its utility...) and new-ramdisk.cpio.gz that I simply renamed ramdisk.img. This could be the main reason why the AVD isn't working.
Will look up how to deal with ramdisk soon.
==========**2**==========
Operation:
•Restored the original kernel-qemu from backup
Test:
•The AVD still not show anything but quiting the emulator doesn't trigger any crash now.
Result: FAIL
Troubleshooting:
•As mentionned before will look up ramdisk.img file that seems problematic
Thread closed. But the project of emulating a custom rom is not abandoned.
Actually I didn't find a way to use the new AVD tool provided by Google to reach this goal. Instead I am heading over the new idea of creating a software generating an environment for Android emulation with given components (kernel, system, data etc. prealably extracted or, better, from a backup)
I hope I'll get help in the future because I'm pretty sure I won't be able to do such enormous task alone...
New thread here: https://forum.xda-developers.com/android/development/help-environment-builder-custom-rom-t3758360