Any chance of someone or a group of great developers putting together android in a format like ubuntu that can be loaded onto the device in question through USB. Ok hear me out all that ubuntu does when installing is configure itself from a compiled database of your hardware specifications. So there are only so many devices out and only so many drivers to run those devices hardware, could we feasibly compile all of them and put them in with an android installation thatr ran from the host computer and installed itself according to what the computer told the installer to do if the computer reads that you have a specific chipset with a 1ghz processor it loads in the files and commands for that and so forth, just an idea, its gotta be possible right? its just an miniature OS............
I'v read some post on about install Linux distribution(Ubuntu, Arch Linux ARM, Gentoo) into a tablet pc, and I wonder if I can install Linux on Kindle Fire... I've no idea about this kind of thing, so if you think it's possible, I'll learn how to do it... Thank you in advance...
I Think if Kindle fire run on linux arm kernel you can. but you must porting Ubuntu's package to ARM and install this. But It is not so easy and can make problem to device
What about extending, not replacing, android linux?
Shouldn't it be possible to add commands to the Linux that underlies android to give it the functionality of at least some version of full Linux while keeping the android layer on top of it? I'm not a developer, so I don't know what all the technical problems might be, beyond the following:
Some kind of compiler is necessary, but isn't that also needed to create an android ROM anyway?
Code:
Since the KF doesn't accept an SD card, space might be a problem, but maybe a USB memory stick (flash drive), an OTG adapter, and perhaps some change to the bootloader to allow the KF to go into USB host mode might work. And the solution would probably be easier if the external memory were used for data and apps, but not for any part of the OS?
Perhaps this discussion belongs under Android Development, either specifically for the KF1 otter or more generally. Maybe there already are such discussions on xda or elsewhere. Guidance from developers and others in the know would be appreciated.
This sounds like a Decent idea. I actually want to try that now.
Boot from SD card
This is a placeholder for some work I was doing on booting and alternate copy of Windows RT from SD card
by adding extra entries in the bcd store and a ‘copy’ of windows on the SD card
(or a reinstalled version of Windows RT installed onto the SD card)
Note it actually still boots from the system partition on the internal flash but tries to boot an alternate Windows installation from \windows on the SD card
However having problems getting it to find the SD card volume at boot time
Still working on that
and on how to use the recovery environment to install the OS onto SD card
Best to have a Class 10 SD card
But now moved on to dual booting Windows RT and RT 8.1 (both from internal flash)
http://forum.xda-developers.com/showthread.php?p=43062190#post43062190
Also working on booting a full OS from USB stick
That'd be quite cool. It'd also be an important part of a Linux or Android port to Surface RT. You could make an extremely-stripped-down Windows RT installation that boots just enough to run some exploit automatically. The exploit could load a kernel driver to do the equivalent of kexec() into Linux.
Such an installation on a USB stick could be a bootable Linux live "CD" as well.
Myriachan said:
That'd be quite cool. It'd also be an important part of a Linux or Android port to Surface RT. You could make an extremely-stripped-down Windows RT installation that boots just enough to run some exploit automatically. The exploit could load a kernel driver to do the equivalent of kexec() into Linux.
Such an installation on a USB stick could be a bootable Linux live "CD" as well.
Click to expand...
Click to collapse
Someone just needs to actually come up with that exploit first. I'd totally convert my surface to a Linux device if it was available ... Windows is nice and all, but I love that warm, fuzzy feeling of having full control of hardware I own. I got CyanogenMod on just about every Android device I have, and getting out of the restricted RT arena would be awesome.
southbird said:
Someone just needs to actually come up with that exploit first. I'd totally convert my surface to a Linux device if it was available ... Windows is nice and all, but I love that warm, fuzzy feeling of having full control of hardware I own. I got CyanogenMod on just about every Android device I have, and getting out of the restricted RT arena would be awesome.
Click to expand...
Click to collapse
The general idea behind netham45's exploit (which originates with a Google guy) would actually work for this. If you control the entire boot image, you can make cmd.exe start a script and cdb very early. There exists a modification to the technique to do the exploit without the two-minute instability problem.
If Microsoft doesn't lock out the 8.0 bootarm.efi, this would keep working after 8.1's release--just boot 8.0 to do this part.
The difficult part of this entire thing to me is how the hell to write Linux drivers for hardware we know nothing about.
Myriachan said:
The general idea behind netham45's exploit (which originates with a Google guy) would actually work for this. If you control the entire boot image, you can make cmd.exe start a script and cdb very early. There exists a modification to the technique to do the exploit without the two-minute instability problem.
If Microsoft doesn't lock out the 8.0 bootarm.efi, this would keep working after 8.1's release--just boot 8.0 to do this part.
The difficult part of this entire thing to me is how the hell to write Linux drivers for hardware we know nothing about.
Click to expand...
Click to collapse
Linux for tegra might be a start, think that is now upto tegra 3 specs. But there are still several unknowns like you say. Some disassembly might clear up a few more unknowns (is the screen DSI or LDVS, which interface is used for the storage as there is more than one which would be capable for eMMc usage).
We do know that all the sensors are i2c devices at least.
But yeah, there is alot of work for a community to do in order to port linux to the surface. Not unless microsoft release a few datasheets which they have no reason to. Making matters worse, not all RT devices would be the same so the surface RT would need a different port than dells qualcomm based tablet. Even the tegra based tablets might need a different BSP to each other.
I do think though that if there was linux on the surface RT then I would probably consider getting one. Would at least double the chances at any rate.
SixSixSevenSeven said:
Linux for tegra might be a start, think that is now upto tegra 3 specs. But there are still several unknowns like you say. Some disassembly might clear up a few more unknowns (is the screen DSI or LDVS, which interface is used for the storage as there is more than one which would be capable for eMMc usage).
We do know that all the sensors are i2c devices at least.
But yeah, there is alot of work for a community to do in order to port linux to the surface. Not unless microsoft release a few datasheets which they have no reason to. Making matters worse, not all RT devices would be the same so the surface RT would need a different port than dells qualcomm based tablet. Even the tegra based tablets might need a different BSP to each other.
I do think though that if there was linux on the surface RT then I would probably consider getting one. Would at least double the chances at any rate.
Click to expand...
Click to collapse
I'd imagine focusing on one at a time would keep you from getting overwhelmed, and I would think the stock Microsoft Surface RT is the one that makes the most sense to start with, at least get a proof of concept working. As far as "hardware we know nothing about", the Tegra itself is pretty well documented and I imagine it operates essentially the same as it does anywhere else.
I would imagine stages to doing this:
1) Figure out the exact sequence to stop Windows and disengage the kernel, watchdogs, or whatever else in a stable way to start executing arbitrary code in RAM, with some kind of POC demo, e.g. getting data out over I2C or something, which we ultimately will need to debug a kernel.
2) Once this has been accomplished, start playing with ARM-based Linux bootloaders, with console output happening over I2C or whatever else works. This can allow for just trying to get the kernel to run, even if at first this renders a completely non-interactive device.
3) If you get this far, obviously now it's all about getting the magic mix of drivers...
With an actual kernel running, most likely a lot of hardware would become more easily identifiable, and we could at least figure out where we stand. Of all these things, I imagine #1 is the most difficult to overcome, but there's been some suggestions.
southbird said:
2) Once this has been accomplished, start playing with ARM-based Linux bootloaders, with console output happening over I2C or whatever else works. This can allow for just trying to get the kernel to run, even if at first this renders a completely non-interactive device..
Click to expand...
Click to collapse
I dont think anyone knows the exact pinout but there is i2c on the connector for the touch/type covers, they are themselves i2c devices. If someone knew the pinout, theres your access. Stick some magnets on some card with a few pieces of wire sticking out of it, should be able to hold against the connector. But that doesnt matter so much.
I've heard of linux consoles being accessed over UART (infact I have done this with a raspberry pi) but not i2c. The tegra does have at least 1 UART though (I have a feeling it might have 3 or 4). Whehter you would have to tear a surface apart to get at it though is another matter. I know that several devices actually make the uart externally accessibly via either the USB or audio jacks with a quick pinmux. A nexus 4 for example you stick a certain resistor between the mic and ground channels on its audio jack and I think the left audio channel becomes Tx and right Rx or vice versa. A few android tablets (I think HTC are big on this) use the microUSB, certain resistor value between the sensor and ground lines as is often used for enabling USB host triggers D+ and D- to become Tx and Rx instead. No microUSB on the surface though. My guess if they ran one externally it would either be on the cover connector (there are 5 connected contacts yet only worked out a purpose for 4 of them, then there is 1 pin not connected to anything for some reason, probably future expansion, perhaps this 5th pin enables a UART instead of i2c???) or the audio jack, there might well not be one accessible externally at all :/
I would assume the surface screen is either LDVS or DSI, the prior is more likely to be documented than the latter (DSI isnt even fully standardised, in theory it is but in practise DSI devices are rarely compatible even with the same res, colour depth etc). May well be possible to output direct to that initially.
With the keyboard being i2c it may well be possible to write a driver to use it on linux on an existing device, not sure how well USB-i2c adaptors work but the pi has 2 native i2c buses.
I do agree that the surface is the logical starting point. Its probably sold the most units at any rate and is the first thing people think of when you say windows RT. Other tegra devices would be the most logical to follow on with, qualcomm would perhaps be able to reuse step 1 but step 2 you would likely have to start from scratch all over :/
Oh well, 1 hurdle at a time. Honestly though, the existance of a functioning linux port for the surface would make me tempted to buy one. That or microsoft unlocking RT to literally be windows 8 on ARM not windows 8 stuck in a cage.
southbird said:
1) Figure out the exact sequence to stop Windows and disengage the kernel, watchdogs, or whatever else in a stable way to start executing arbitrary code in RAM, with some kind of POC demo, e.g. getting data out over I2C or something, which we ultimately will need to debug a kernel.
Click to expand...
Click to collapse
There is already a method of running any unsigned EFI file (for example a GRUB loader). But it works only on Asus tablets and requires USB stick inserted on boot and Bitlocker turned off in Windows (as the "trusted boot environment" is broken). I'll publish it later - probably after 8.1 official release, as it can be easily closed by Asus in a next firmware update that may be required for 8.1.
I have searched lots on the subject of getting a full linux distro running on an android device most of which were really not really what I am looking for, almost everything I find on the subject seems to be some kind of hybrid solution where running linux side by side or on top of android but imo that just seems messy and may as well just be using andorid with it's apps than do that.
I ran into interesting information about modding chromebooks some of when were the similar side-by-side solution but others actually more what I was looking for, they enable legacy seabios while not enough to get windows installed seems to work fine to boot into linux and another guy had baked his own custom seabios replacing the chrome bios entirely.
my question, the atom tablets Im seeing pop up a few places are standard x86 right ? is it possible to either
1/run a modded sea bios similar to chromebook mods? then boot a stock ubuntu distro installation maybe from external storage?
2/or somehow have the existing/modded bootloader boot linux kernel/ubuntu install ?
can't help think if it were that simple maybe someone would have done it already but also thinking the hardware (drivers) are supported by android so they should be supported by linux right ? and if it is standard x86 can't be too much a stretch right ?
I don't own an atom tablet but was thinking it may be desirable (and add more use) if I could get a full linux distro installed and be a lot more affordable than full fledged windows based tablet.
anyway thanks
ps:that captcha is harcore
They are kinda standard. But they are not following PC architecture. They are so called Intel MID (Mobile Internet Device). On such devices you may find neither EFI nor ACPI. They have so called SFI which is a complete disaster. But Intel Merrifield is more or less supported by upstream kernel and Yocto (thanks to Intel Edison platform). You may try to gather information about those devices (official name of SoC is Intel Atom Z34xx).
Hello World,
I want to buy an octacore single motherboard. However they are expensive. I would like to do testing and calculations(run HT-condor) or other cluster software on this. I would like to know if there is a possible way to use my phone for this. I know since it requires specific drivers it would be hard, but then i thought ubuntu has its own operating system so maybe it is possible to use those drivers and create a clean ubuntu install that has not extra features of camera or ads etc. I am only interested in network support(wifi) and being able to use cpu and gpu.
Is this possible ?
Greetings,