I got pretty sick of "Linux on xyz Android device" meaning a chroot with varying levels of usefulness. This is the first post in a while that shows some actual low-level dev work being done.
How difficult would it be to get a (mainline?) kernel booting on this, maybe even into Debian?
There are lots of cheap boards out there, way cheaper than a Nexus, of course they require a bit of electronics knowledge, but that should be part of any proper CS degree (at least mine had it).
The oem unlock allows you run a custom OS (e.g. a custom Android build) that is not signed. This is well known, and is what allows this demo to work. However, the comment I was making is whether the firmware (i.e. the bootloader, "BIOS" if you may - in particular the Secure OS) can be reflashed.
The reason the existing firmware could be desired to be replaced is that the Secure OS component specifically disallows an OS to run in hypervisor mode (i.e. no KVM or Xen), or because of terrible bugs in HBOOT that cause hangs if the boot.img exceeds a certain arbitrary size (a few tens of MB). All these limitations mean that even an OEM-unlocked device is not quite entirely available to the mercy of a developer.
Of course, the ability to reflash the low-level boot code is not very useful unless you have sources to build a better replacement.
Are there any devices that ship with Android that could be reflashed to support a Linux kernel with KVM or Xen bits? Either Intel Atom or ARM-based devices?
[+] [-] andreiw|11 years ago|reply
[+] [-] voltagex_|11 years ago|reply
How difficult would it be to get a (mainline?) kernel booting on this, maybe even into Debian?
[+] [-] voltagex_|11 years ago|reply
[+] [-] pjmlp|11 years ago|reply
[+] [-] hobo_mark|11 years ago|reply
[+] [-] higherpurpose|11 years ago|reply
I don't think it does. I think you usually need "root" to install another ROM/OS on the device as well.
[+] [-] andreiw|11 years ago|reply
The reason the existing firmware could be desired to be replaced is that the Secure OS component specifically disallows an OS to run in hypervisor mode (i.e. no KVM or Xen), or because of terrible bugs in HBOOT that cause hangs if the boot.img exceeds a certain arbitrary size (a few tens of MB). All these limitations mean that even an OEM-unlocked device is not quite entirely available to the mercy of a developer.
Of course, the ability to reflash the low-level boot code is not very useful unless you have sources to build a better replacement.
[+] [-] lancemjoseph|11 years ago|reply
[+] [-] Aissen|11 years ago|reply