Related
Hi,
I'am French and new in your community, I have a Tattoo since 2 months
I would like try to build custom rom but i have several questions
When you build/test your rom, you always test directly on your device ?
Is it possible to use the Android SDK emulator to test our own Rom ?
There is a site or others that explain the Android boot process ? or this boot process is exactly the same as in a classic linux ?
Thx.
Android is based on Java, which runs in a Dalvik VM on top of a Linux base. Linux is actually the internals, the hardware detection, etc.
When you boot up the Tattoo, it loads the linux kernel holding all the things required to boot Android. It then looks for the system partition, and then starts the VM to load Android's java apps.
From a development and user standpoint I am of course interested acquiring root for the android side of things but my main interest and focus on gaining the ability to modify and enhance the webtop image that provides the "full feature" capability for Firefox. So in a sense there is a goal for Double Root on Atrix. Rooting first the android side and then rooting the webtop Linux instance.
I am guessing from the looks of it that webtop is based on Ubuntu Light. It is also likely run in a VM otherwise the phone instance of android (Dalvik) and the Webtop could not run simultaneously. Given that the platform is probably something to the effect of:
Linux File System -----> Dalvik VM ------> Android Runtime
Linux File System -----> Some other VM? -------> Ubuntu Light
I am running under some assumptions (not having an Atrix till next week ):
* The "Some other VM" is not Dalvik since I don't think as an App VM.
So some of the questions I seek to answer right away are:
What VM is running (presumed) Ubuntu light
Does that VM have security around the disk image (singed)
Is the (Webtop disk image) encrypted/signed
What is needed to get root access on the Webtop side.
The best way to get root on the Webtop side is to go after the file system. I am guessing that will be signed but it MUST be writable at some level to save state.
Just a bunch of musings. I am looking forward to getting my atrix so I can start answering some questions.
I think getting root to one or the other will make it VERY easy to root ther other.
I for one hope it is ubuntu lite, or something debian based. Hopefully make it really easy to port over a full distro.
being able to boot into a full linux distro would be the cats meow!
i have full expectations of being able to do this within a month or two ;-)
Do you guys think it would be possible in the coming weeks/months to be able to boot into a full linux distro on the Atrix itself - without the laptop dock?? that would be ultimate awesomeness right there!
jgc121 said:
Do you guys think it would be possible in the coming weeks/months to be able to boot into a full linux distro on the Atrix itself - without the laptop dock?? that would be ultimate awesomeness right there!
Click to expand...
Click to collapse
well the nexus one and nexus s and dell streak and motorola Droid (OG) could run ubuntu so I hope the atrix will.
emoose said:
Linux File System -----> Dalvik VM ------> Android Runtime
Linux File System -----> Some other VM? -------> Ubuntu Light
I am running under some assumptions (not having an Atrix till next week ):
Click to expand...
Click to collapse
It's also possible that they have a Linux variant running on bare-metal, without a VM. I have seen some architectures in the embedded world that allow each CPU core to work together as a typical dual-core system, OR to boot a different OS kernel on each core.
The latter case would be the most interesting in terms of getting the most out of Linux on the Atrix, assuming the second OS can be rooted. This could (speaking with almost no knowledge of Android itself), also be another angle of attack/defeat though if that means the webtop linux kernel also needs to be signed...
Then again, a VM does make more sense in terms of the near-instant boot time of the WebTop mode.
I can't wait to see the "double root... oh my god... what does it mean???" Youtube video come out in a few weeks =)
If I can get a command prompt and root access on the Webtop instance I will sound just like the Double rainbow guy.
Things I believe to be true right now.
WebtopSession app initiates then session when you plug in HDMI. This is no different than any other peripheral launch.
WebtopSession app (speculating based on other posts) checks you connection type and provisioning. If you don't have a tethering plan it doesn't allow you ton continue. If you are on wifi it allows you to continue.
If you start off on WiFi and then change network state to mobile radio (and no tethering plan) will it discontinue the session?
The WebtopSession App doesn't look like it does anything other than manage the initiation of the Linux (Webtop) session.
There is nothing in the dumps that looks like it could remotely be a disk file which makes me think that there is a partition that is different that the normal android partitions. I would love to see a partition map of a rooted phone.
jgc121 said:
Do you guys think it would be possible in the coming weeks/months to be able to boot into a full linux distro on the Atrix itself - without the laptop dock?? that would be ultimate awesomeness right there!
Click to expand...
Click to collapse
im also wondering this!
edit: Erm. Whoops. A little bit of research and it turns out Motorola has left the code in for when they test the OS in "goldfish-qemu", an Android emulator. Sorry ><
It's got to be QEMU. In the retail firmware dump in /etc/init.goldfish.sh:
Code:
# call 'qemu-props' to set system properties from the emulator.
#
/system/bin/qemu-props
So what I'm thinking after parsing the information I've got...
... WEBTOP is simply a QEMU (ARM version?) instance running off of some unknown image/partition on flash that outputs to HDMI with some hackery to support local media [mounted in the host OS, Android] and local control and USB keyboard/mouse input, along with special extensions to allow for use of the Android/host OS instance within the VM.
labsONE said:
edit: Erm. Whoops. A little bit of research and it turns out Motorola has left the code in for when they test the OS in "goldfish-qemu", an Android emulator. Sorry ><
It's got to be QEMU. In the retail firmware dump in /etc/init.goldfish.sh:
Code:
# call 'qemu-props' to set system properties from the emulator.
#
/system/bin/qemu-props
So what I'm thinking after parsing the information I've got...
... WEBTOP is simply a QEMU (ARM version?) instance running off of some unknown image/partition on flash that outputs to HDMI with some hackery to support local media [mounted in the host OS, Android] and local control and USB keyboard/mouse input, along with special extensions to allow for use of the Android/host OS instance within the VM.
Click to expand...
Click to collapse
So then you are saying it could be possible to do something like this:
https://help.ubuntu.com/community/WindowsXPUnderQemuHowTo
jgc121 said:
Do you guys think it would be possible in the coming weeks/months to be able to boot into a full linux distro on the Atrix itself - without the laptop dock?? that would be ultimate awesomeness right there!
Click to expand...
Click to collapse
Running the webtop or a full distro without any docks will be just plain awesome...
emoose said:
If I can get a command prompt and root access on the Webtop instance I will sound just like the Double rainbow guy.
Click to expand...
Click to collapse
Oh maaan. Double root all the way What does it mean???
In all seriousness, the Atrix is certainly the most interesting phone from a developers standpoint, but I'm sitting and watching for a bit as I want to see how much of a problem the signed bootloader becomes first.
So does the Signed Bootloader rule out the Double root ? or changes to the Webtop APP/Module ?
hrishi2das said:
So does the Signed Bootloader rule out the Double root ? or changes to the Webtop APP/Module ?
Click to expand...
Click to collapse
It depends. Signed bootloader refers to the fact that the phone boots only if certain partitions match the Moto signatures.
The question is, where does the Webtop mode boot from, and is any part of *that* boot process signed?
I don't know why you guys think it has to be running in a VM. It's more likely they have just install Xorg and Firefox on Android and run them, with X displaying on the HDMI.
Exactly the same as the ubuntu-on-android hacks, but instead of using VNC to view X, you just display it on HDMI.
The phone view is an X11 app which communicates with the Android system server to mirror the display.
I seriously doubt they are using QEMU or anything like that.
Bah! Edited post since my last one was way off.
Did some looking and it looks like qemu in this instance is related to running some proc emulator for android development sdk support.
There this is a bunch of stuff out if you google: android goldfish
Its related to ARM targets for the sdk and in this instance probably not webtop.
I'd still really like to see the output of:
adb shell
cat /proc/mtd
Timmmmmm said:
I don't know why you guys think it has to be running in a VM. It's more likely they have just install Xorg and Firefox on Android and run them, with X displaying on the HDMI.
Exactly the same as the ubuntu-on-android hacks, but instead of using VNC to view X, you just display it on HDMI.
The phone view is an X11 app which communicates with the Android system server to mirror the display.
I seriously doubt they are using QEMU or anything like that.
Click to expand...
Click to collapse
Agree. But from the DG's / dump could not find more interesting info except the WebtopSession.apk. I guess webtop stuff live in another patition which is actived when webtop session starting.
Could anyone who has a rooted Atrix dump the phone while webtop on?
sexydroid said:
Agree. But from the DG's / dump could not find more interesting info except the WebtopSession.apk. I guess webtop stuff live in another patition which is actived when webtop session starting.
Could anyone who has a rooted Atrix dump the phone while webtop on?
Click to expand...
Click to collapse
I don't have the webtop device. What about while the phone is plugged into the TV? If it'd help any just give me the steps and I'll do it.
Yes if you plug your phone into the tv it will be able to access webtop.
(I have to post here as I can't yet post in the dev forum.)
I have a set of command line executables (let's say something very broadly similar to Busybox though it's not really the same) written in C/C++. I compile these under Windows and Linux with MSVC or MinGW and gcc, respectively. There's no GUI at all, it's all pure command line stuff making heavy use of the respective C/C++ runtime libs.
Let's say I want to compile these for the likes of the HD/HD+. Would I need to install the whole Android dev kit (of which I know precisely nothing at this point in time)?
Or is it possible to cross-compile such executables from a Linux desktop machine? Perhaps naively, I assume it should be.
TooMuchSloeGin said:
(I have to post here as I can't yet post in the dev forum.)
I have a set of command line executables (let's say something very broadly similar to Busybox though it's not really the same) written in C/C++. I compile these under Windows and Linux with MSVC or MinGW and gcc, respectively. There's no GUI at all, it's all pure command line stuff making heavy use of the respective C/C++ runtime libs.
Let's say I want to compile these for the likes of the HD/HD+. Would I need to install the whole Android dev kit (of which I know precisely nothing at this point in time)?
Or is it possible to cross-compile such executables from a Linux desktop machine? Perhaps naively, I assume it should be.
Click to expand...
Click to collapse
You can cross-compile. Its been a while since I did it but I used CodeBench. They have a free version.
Sent from my Nook HD+ running CM10.1 on emmc.
Thx for that, this is really good news. I was/am not keen on installing, investigating and battling a (to me) new tool chain. If cross-compiling works at all I am sure 'll get it up and running with what I have and know.
(I know this thread maybe should belong to Development forum, but I'm posting here since I don't have enough posts to discuss there yet)
I'm in the second year of Computer Science, being a dynamic/interpreted languages programmer for over 6 years now, C/C++ for 2 years.
I have a solid understanding on the x86 PC architecture: interrupts, buses, etc. I'm pretty good at basic x86 assembly... Been studying UEFI for over a month... Whatever.
I've lost the past couple hours searching but didn't find anything on the architecture of our device. Is the "Bootloader" here compared to a BIOS? Or is it like any PC bootloader (MS-DOS, Windows, Linux bootloaders). Is there anything like a BIOS at all or does the OS, once booted, manages all the hardware interrupts by itself? Can I use INT 10H on XT890? Is it ANYTHING close to the PC architecture?
PCI, ISA, (parallel and serial) "ports" managed by a chipset between the peripherals and the x86 core itself?
Ok, it's x86. Once the system has booted, we can call x86 instructions, ok... But what is under that? Is there any reference on this? How can I boot my own code, if it's not Linux?
I really got nowhere trying to learn about the architecture underneath Android and Motorola's Bootloader on Medfield. Found nothing on Intel nor Motorola websites. What am I doing wrong?
Thanks in advance!
I'm studying this myself but there is a lot that i need to learn. Check those to see if helps.
http://bootloader.wikidot.com/android
http://elinux.org/Android_Booting
http://www.ibm.com/developerworks/linux/library/l-linuxboot/
I would like more info about the RAZR I as well, considering it's the only mainstream phone with a x86 processor I'd expect more documentation about it, I am receiving a RAZR I soon.
For what I know, it's boot process is similar to other Android devices, it loads and decompresses a boot.img file that includes a ramdisk and the kernel, you should be able to load another non-linux OS by chainloading a secondary bootloader there, I honestly would like to see more development on the Razr i, specifically to get native Gnu-linux with x11 running
Using @thiagomtl's links, I was able to understand a little more about the Boot process. XT890 seems to have basically the same mechanics of the ARM ones, but x86 tuned.
However I'm yet to understand the differences between "normal" Linux bootstrapping and the Android Bootloader's one.
On a average legacy Linux box we have GRUB/LILO on the MBR. Making a hell of a simplification here: The user turns the PC on, BIOS does the POST and then loads whatever code is on the MBR. GRUB is a very small program there, which simply loads a driver for the storage device, loads vmlinuz and the f*ing ramdisk on the memory and executes it (effectively by simply pointing the IP to the address where the kernel is on the memory).
Samuelgames said:
I would like more info about the RAZR I as well, considering it's the only mainstream phone with a x86 processor I'd expect more documentation about it, I am receiving a RAZR I soon.
For what I know, it's boot process is similar to other Android devices, it loads and decompresses a boot.img file that includes a ramdisk and the kernel, you should be able to load another non-linux OS by chainloading a secondary bootloader there, I honestly would like to see more development on the Razr i, specifically to get native Gnu-linux with x11 running
Click to expand...
Click to collapse
But the Boot process is just a part of my original question. Ok, a important one, but a part.
What about the structure of the device? How it's all implemented? Is the display using plain old VESA VBE? Are the input devices PS/2? USB? Is the power implemented using ACPI standards? lol
As far as I'm concerned Atom SoC doesn't respect many industry standards for the architecture, even for those who run Windows 8, buttons on the Razr I should be naturally be defined as GPIO as the notification LED, I don't think the display respects VESA standards (SGX 540 can't even do scaling) but it should fallback to them at some extent depending on how you initialize the framebuffer.
All of this should be in the Motorola kernel, I haven't taken a look at it but I'll surely will once I get my phone
@Hazou, @YaPeL, @Omar-Avelar
you guys know anything about this?
Ok this is all i know about it by searching through the code and internet and by finding out myself (no sources included, just my memory). It's all linux, nothing like Windows.
Kernel:
We indeed are making a x86 kernel, but not for normal PC's. We use the mid-x86 implementation within the x86 code of the kernel. (arch/x86/platform/mid-x86) MID is the intel word for all the socs for mobile platforms intel is using. The normal upstream linux doesn't provide all the necessary code. And is has changed with the new android version 4.4.2 for our device.
Boot sequence:
The android devices use some sort of bootloader. Droidboot. Droidboot includes the fastboot commands and starts the bringup of the android system. You can read about it on the internet. In most devices (ARM) it is the first thing thats get called for.
Our intel device is a little different. Before the droidboot gets loaded the firmware of the device loads another OS. Also called POS (i think preprocessor OS, or something). Those gets updated with the dix and efwi(wrong name) files we got. The POS can be accessed by booting in the medfield download through the camera button, if i am correct. The POS then loads the droidboot which will in turn load the rest, like a linux device which loads from the bootloader.
The partition layout can be found in the gpt.bin. It can be flashed through fastboot and can change every partition afaik.
So the boot order is:
1. POS/RADIO
2. DROIDBOOT
3. BOOT.IMG is like linux. First the kernel then the ramdisk with the kernel modules.
4. ANDROID
To comment about the JB implementation.
We can build our own kernel and we can, if we want and take the time, upgrade the kernel to the newest version (for android is that 3.10, but we should be able to manage to go fully upstream 3.17). But that takes a lot of time.
I also noticed that, from what i heard, some kernel modules specific for our device has changed and now the kernel that we have can't load the new firmware files in 4.4. So we will need the next kernel from Moto to compile our own when 4.4.2 is released. Those changed are not upstream.
Hazou said:
The POS then loads the droidboot which will in turn load the rest, like a linux device which loads from the bootloader.
The partition layout can be found in the gpt.bin. It can be flashed through fastboot and can change every partition afaik.
So the boot order is:
1. POS/RADIO
2. DROIDBOOT
3. BOOT.IMG is like linux. First the kernel then the ramdisk with the kernel modules.
4. ANDROID
Click to expand...
Click to collapse
This is the most interesting part for hundreds of us. Is there a way we can find what sectors are used for the pos so we can possibly repair code corrupt?
I have a feeling the gpt is messed up so any amount of writing to the dnx or ifwi will be in the wrong location.
I can't find any information on this phone at all.
I think it's time I bought a spare mobo and dumped everything to compare a broken to working
Flacid Monkey said:
This is the most interesting part for hundreds of us. Is there a way we can find what sectors are used for the pos so we can possibly repair code corrupt?
I have a feeling the gpt is messed up so any amount of writing to the dnx or ifwi will be in the wrong location.
I can't find any information on this phone at all.
I think it's time I bought a spare mobo and dumped everything to compare a broken to working
Click to expand...
Click to collapse
If i am correct they are present on the partition layout of the phone. I just don't know wish ones are the right ones. Never looked good enough at that.
Also to repair the gpt and write the dnx or ofwi to the right location u need a dd command or flash command with the right parameters. The flash command most likely won't work because of the gpt partition and the DD command wont either because most of the time u don't have access to a recovery anymore.
But my knowledge about this is limited, so if u dare to put your phone on the line and have maybe the knowledge and skills to do what some people need, please do I can't and need my phone working
Hazou said:
If i am correct they are present on the partition layout of the phone. I just don't know wish ones are the right ones. Never looked good enough at that.
Also to repair the gpt and write the dnx or ofwi to the right location u need a dd command or flash command with the right parameters. The flash command most likely won't work because of the gpt partition and the DD command wont either because most of the time u don't have access to a recovery anymore.
But my knowledge about this is limited, so if u dare to put your phone on the line and have maybe the knowledge and skills to do what some people need, please do I can't and need my phone working
Click to expand...
Click to collapse
Skills/knowledge = limited. I'm no programmer but I take information in like a 100 petabyte SSD.
My phones knackered, I'm trying to fix it but it's not easy! If it's fixed, I'll break it again to make sure the fix works :good:
It's going to be a long road, there is zero success since the first report of code corrupt.
As you say, I need the right param. There's almost no information about it anywhere and what information is about is very fragmented.
I'll keep you updated
Flacid Monkey said:
Skills/knowledge = limited. I'm no programmer but I take information in like a 100 petabyte SSD.
My phones knackered, I'm trying to fix it but it's not easy! If it's fixed, I'll break it again to make sure the fix works :good:
It's going to be a long road, there is zero success since the first report of code corrupt.
As you say, I need the right param. There's almost no information about it anywhere and what information is about is very fragmented.
I'll keep you updated
Click to expand...
Click to collapse
I am almost certain it can be fixed as long as it is a software failure (some maybe have a hardware failure). As this seems one of them it should be fixable as long as your BL is unlocked. With a locked bootloader u don't stand any chance (nah, maybe with medfield flasher, but that one is also limited).
Take a look at the acer padphone or something. Dunno how it is called exactly. Is also uses the intel SOC and makes use of the medfield flasher.
I never had a phone thats corrupt so can't say much about it, but i can help with thinking my way through. If u have that problem can u boot in fastboot or is that even impossible? I know we can flash the POS and fastboot through xfstk. So with the right combination it should work. And if not we can try flash the modem as extra if that is possible. But do know it can hard-brick the device (modem, lowest thing of the device) of-course, aldo u don't have much choice now
Another thing, because fastboot (and even recovery) can flash the dix, ifwi and bootloader files. I 'assume' xfstk (that can also flash the ifwi, dix and bootloader) can flash the whole emmc with indeed the right parameters. We have the source code of the fastboot/recovery ifwi, dix and bootloader flasher. Also called update_osip.
So think it out, i will wait and see.
uart console
Has somebody tried to access a uart console on our razr-i? would be nice for debugging.
Intels datasheet says the board has 3 uart ports. http://ark.intel.com/products/70097
I hope one uart port can be accessed via usb or audio jack. Like on this device: http://forum.xda-developers.com/showthread.php?t=1081743
Or is it only possible with opening the phone and looking for jtag pins?
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