Database Info

PC emulation on Android - OS XDA project links.

So in this thread it tells you how to install pc operating systems like windows and linux on the Evo 3D.
http://forum.xda-developers.com/showthread.php?t=1459153
This, is freaking awesome. This one is a big breakthrough.
----
Here is the thread in the Nook Color forums for ubuntu on the device:
http://forum.xda-developers.com/showthread.php?t=1055954
----
These two threads are native installs, not using some client to access the installation, the device itself is the client as it should be.
This is not some chrooted virtual OS simulation, but the real deal installed to the device.
----
In the back of my mind i've wanted to play with ubuntu installed on the MT4GS, but not a virtual installation I want it installed and running on the device natively.
I definitely don't have the time to do this and a lot i'm trying to do around here even if I wasn't in my busy season for work.
Dropping this information so I can find it later when I do get to trying to get ubuntu (and now windows XP looks like a possibility) installed on this device.
If anyone else feels like looking into this, here's a good place to start. If anyone comes across any other projects that are the real deal and not virtual installs please post links here.
Have fun!

Blue6IX said:
So in this thread it tells you how to install pc operating systems like windows and linux on the Evo 3D.
http://forum.xda-developers.com/showthread.php?t=1459153
This, is freaking awesome. This one is a big breakthrough.
----
Here is the thread in the Nook Color forums for ubuntu on the device:
http://forum.xda-developers.com/showthread.php?t=1055954
----
These two threads are native installs, not using some client to access the installation, the device itself is the client as it should be.
This is not some chrooted virtual OS simulation, but the real deal installed to the device.
----
In the back of my mind i've wanted to play with ubuntu installed on the MT4GS, but not a virtual installation I want it installed and running on the device natively.
I definitely don't have the time to do this and a lot i'm trying to do around here even if I wasn't in my busy season for work.
Dropping this information so I can find it later when I do get to trying to get ubuntu (and now windows XP looks like a possibility) installed on this device.
If anyone else feels like looking into this, here's a good place to start. If anyone comes across any other projects that are the real deal and not virtual installs please post links here.
Have fun!
Click to expand...
Click to collapse
Regardless of what impression you may have, it is ABSOLUTELY IMPOSSIBLE to run MSWin on ARM hardware natively. The reason for this is that MSWin is x86 and ARM is... ARM. The approach used in the first link is to use BOCHS (pronounced "Box"), which is a VIRTUAL HARDWARE EMULATOR. It requires a host operating system to be functioning in the background, in this case Linux.
As for Ubuntu... well sure. No problem. Its Linux and the phone runs Linux. Not that big of a stretch to replace the Android parts with GNU.
Note that NONE of this is any kind of "great breakthrough". Bochs has been around for a VERY long time. First OPEN SOURCED in early 2000. Yeah, 12 years ago. As for Ubuntu... well I suppose that the main reason that most people aren't making a native android replacement out of ubuntu, is that not many people are all that interested in it. Cute in theory, but not practical.
What would be a more worthy project would be to upgrade android to GNU libraries and utilities. This would afford us an actually USEFUL balance between the two. Also the ability to run X *through* android without having to do stupid things like VNC. Have the proper interface ***AS AN ANDROID APPLICATION***, leaving Android to work (i.e., phone calls, etc.) while simultaneously offering the standard Linux applications.
My thought though, is that this is becoming less and less important. Firefox is on Android now, the Document foundation has announced LibreOffice for Android -- supposed to be by late 2012 to early 2013... GIMP has no place on Android... That certainly covers the basics.

Appreciate the post. I didn't have time to dig into it too deeply, so took it at face value for the impression I got. Happened to come across it in passing and didn't want to lose track of something vital to the future dev of a project like this on the doubleshot. (but definitely this doesn't belong in the dev section at this time - just clutter there.)
I was hoping people would add to it, especially the way you have, who had more of an understanding of what's going on there - I didn't realize that it was a virtual environment for the windows stuff, but it did seem to good to be true.
Even if no one responded I figured the thread would get pushed down out of the way, but still be here when I got the time to come back to it.
----
My reason for running native linux on the device itself is to be able to use the Android SDK and tools without needing a computer to do so. I have 2 of these phones and a Nook Color. The NC has USB host support, so I could plug the doubleshot into it without frying either device. (yes, i'm blending android and linux concepts here - but usb host support in android shows that it's capable of doing it)
Even from one doubleshot to the other I could use wifi adb for a lot of stuff without plugging them into each other through USB and frying the phones. So that would be a victory as well.
The lack of a hardware charging circuit in the doubleshot makes the worry of frying the phones a big deal, power transfer through USB is a big hurdle to jump in management.
Beyond that - the doubleshot is powerful enough on hardware specs to be able to compile a kernel, but that's not gonna happen through a virtual linux install because the overhead is too much. A native install might just be able to do it though. Won't know until I try, but it's worth the work to get to the point of trying, even if it doesn't work out.
The Nook Color probably won't be able to compile a kernel - it's asking too much from a device not really able to handle that.
Getting what I mentioned above to work would mean I could do all my dev work with what fits in my pocket, and let me keep working wherever I am.
I do like the idea of an app to work with this through Android itself - but I don't see how I could use the SDk and variety of user-created tools without a native linux install. Worth pursuing either way though.
If anyone has anything to add, i'd be welcome to hear it. Just understand this is not a project i'm working on or actively pursuing right now - but fully intend to down the line.

Actually blue. There is a thread somewhere that has a step by step on installing ubuntu on gingerbread. I meant to add it when I added the backtrack link. For some reason I didn't, I probably forgot, I actually think the link for it is in the backtrack thread in the sticky.
If I do find it ill let you know.
Sent from my ICS Splashed using Tapatalk

What's the real problem about linux on surface rt ?

Hi,
I've buy from at lest one mont a surface rt, i've jailbreak it and install filezilla and notepad+++ so.... but i'd like anymore. Like many people i'd like to install a linux distribution on it but i dont really understand what is the problem...
I've know about:
Surface get a secure boot (EFI) and we can't disable the secure boot on surface RT caused windows need a valid key (?). I've read that linux got some distributions arm based (ubuntu, debian, fedora) and i think i've understand about ubuntu got a valid microsoft signature with a ssl provider that can bypass the useless verification... am i right?
So, if ubuntu (or another distro), got a valid sign for bypassing the limitation to due EFI why can't we normal install linux such like surface pro??
Best regards and sry for my bad english ^^'
----------------------------------------------

Some distros has keys to X86 UEFI. No one (other than Microsoft) has keys for ARM.
And (afair) due to some limitations of jailbreak we have no way to execute linux kernel.
This applies to any RT device.

kitor said:
And (afair) due to some limitations of jailbreak we have no way to execute linux kernel.
Click to expand...
Click to collapse
Is this true for sure? I figured especially since we have driver-level access we could possibly tear down the Windows kernel in reverse and start execution of arbitrary code. But I might have missed something.
The bigger issue about trying to port Linux to any device without official Linux support is usually in getting the kernel to boot and then making the hardware itself useful after that. This usually means you have to work "blind" and rely on some kind of low-level serial output to monitor the kernel boot to see where it panics. Only after getting a successful kernel boot can you even begin to think about drivers for the display, touch screen, etc.
So the prerequisites to even beginning to port to e.g. a Surface would be to find some way to kick out Windows and start arbitrary execution, enable some kind of low-level serial debugging for the would-be kernel, and then tediously poke and prod until it can successfully start. I'm not sure anyone knows of a dependable way to get serial debugging information.
Embedded devices on the whole are a lot more finicky and a lot less tolerant than normal PCs, generally due to their proprietary nature requiring a lot of hardware knowledge to initialize everything properly. About the only thing we'd have going for us is that it's a Tegra chipset, so if you can get the underpinnings working, you can probably at least get the basics like video and USB working without too much trouble.
I think the biggest thing about it is like the rest of RT ... there's just not enough interest in those with the skills to even attempt this because this is such an extreme minority platform. I imagine a Surface RT would make an excellent little Linux tablet, but I'm not holding my breath.

Well, If somebody would write something like WinKExec, or HaRET (haret allowed to analyse gpios and memory on WinCE/WM devices) then things may be possible. I own XPS10, so quite different device (as it has Snapdragon CPU), but I have some (small) experience on porting Linux on ARM devices - some time ago I was able to get Linux working on Bsquare Maui: http://pdasite.pl/kitor/maui_linux/ (including hardware reverse engineering - tracking gpios using multimeter - this way i found hidden usb host )

There's been talk of a WinKExec-like approach for months. Nobody has attempted it yet, though, or if they have they kept quiet about it.
One of the problems getting something like that working on RT is that it blocks kernel debugging, so you have to work pretty blindly. Then there's all the driver issues.

What about getting android to boot on it? There's drivers and such for tegra 3. I think its possible to build and deploy if we can get a kernel exploit. Am I wrong?

Android depends on Linux. If you can't get a Linux kernel booted, you won't be able to get Android to start up either.
skiman10 said:
What about getting android to boot on it? There's drivers and such for tegra 3. I think its possible to build and deploy if we can get a kernel exploit. Am I wrong?
Click to expand...
Click to collapse

The kernel by itself would be *relatively* easy (translation: still quite hard, but we could probably do it if people cared enough). However, getting all the other hardware (you know, things like the touchscreen, WiFi, and such) would likely be difficult, and without all that, it's pretty useless as a tablet. This is true for both Android and "desktop" Linux.

Where should I start to get a kernel to boot? I'm an android exploiter trying to dabble in Windows exploitation.
Sent from my HTC6500LVW using Tapatalk

Well, unless you think you can break Secure Boot, you should start by writing/porting a way to use the NT kernel to launch the Linux kernel. That probably means a lot of NT driver development stuff (done without the aid of a kernel debugger, just for extra fun).

There's a doc on internet from the blackhat usa 2013 seems to be interesting.
The man from the pdf get the exploit of injecting some code from the boot, so i think we can done this, no ?
If anyone tried and arrive he'll get amout of money from me

graphsys said:
There's a doc on internet from the blackhat usa 2013 seems to be interesting.
The man from the pdf get the exploit of injecting some code from the boot, so i think we can done this, no ?
If anyone tried and arrive he'll get amout of money from me
Click to expand...
Click to collapse
Can you PM me the article?
---------- Post added at 10:59 AM ---------- Previous post was at 10:57 AM ----------
GoodDayToDie said:
Well, unless you think you can break Secure Boot, you should start by writing/porting a way to use the NT kernel to launch the Linux kernel. That probably means a lot of NT driver development stuff (done without the aid of a kernel debugger, just for extra fun).
Click to expand...
Click to collapse
I think there is an exploit for Secure Boot, it just hasn't been shared yet...

If you mean the exploit I think you mean (discovered by an XDA member), it's a Windows bug, not actually a Secure Boot bug. It doesn't actually allow booting a different OS directly, just messing with Windows after bootup. We already have the jailbreak (for 8.0), which is pretty much equivalent.

GoodDayToDie said:
If you mean the exploit I think you mean (discovered by an XDA member), it's a Windows bug, not actually a Secure Boot bug. It doesn't actually allow booting a different OS directly, just messing with Windows after bootup. We already have the jailbreak (for 8.0), which is pretty much equivalent.
Click to expand...
Click to collapse
Im researching the doc i've found to provide you it.
Its not the jailbreak done by clockr ported by neman its another jailbreak who's available from the boot, but if remember they dont give sources... search in progress i'll post the link

There is one theoretical way to remove secureboot on a jailbroken device. It is rather easy: write a driver that reads/writes physical RAM. Find EFI_RUNTIME_SERVICES in memory and look for SetVariable function. Patch it so that it does not check for a valid signature. Than write your own certificates to UEFI with this patched function. Profit.
I've already done the first part - wrote a driver and found the table in memory (this is really an easy part). But my device died before I was able to successfully overwrite the certificates.
As far as I know similar method was once demonstrated for an x86 UEFI, just noone made it for ARM.

That... is a rather clever option too, although I'm tempted to avoid things which require modifying the firmware (too much option for future updates to break things). Still, a good option for those of us with gen1 devices who would like to be able to upgrade without losing the jailbreak, and also a good option for those who would like to install different OS images...

mamaich said:
There is one theoretical way to remove secureboot on a jailbroken device. It is rather easy: write a driver that reads/writes physical RAM. Find EFI_RUNTIME_SERVICES in memory and look for SetVariable function. Patch it so that it does not check for a valid signature. Than write your own certificates to UEFI with this patched function. Profit.
I've already done the first part - wrote a driver and found the table in memory (this is really an easy part). But my device died before I was able to successfully overwrite the certificates.
As far as I know similar method was once demonstrated for an x86 UEFI, just noone made it for ARM.
Click to expand...
Click to collapse
Can we get in contact? I'd love to get a more detailed plan that I can try. Gen 1 Surface RT on Windows 8 RT.

One demo about bypass: youtube.com/watch?v=i9ULYwRK1iU searching again the pdf mens

GoodDayToDie said:
Well, unless you think you can break Secure Boot, you should start by writing/porting a way to use the NT kernel to launch the Linux kernel. That probably means a lot of NT driver development stuff (done without the aid of a kernel debugger, just for extra fun).
Click to expand...
Click to collapse
About the only way you could possibly break secure boot is possibly by spoofing a key or potentially modify the UEFI to have secure boot disabled. While both are technically possible, you'd have to find an exploit to do it because I'm sure the UEFI probably can't be easily flashed

ThatGuy94 said:
About the only way you could possibly break secure boot is possibly by spoofing a key or potentially modify the UEFI to have secure boot disabled. While both are technically possible, you'd have to find an exploit to do it because I'm sure the UEFI probably can't be easily flashed
Click to expand...
Click to collapse
if you got a device with a jtag interface left open, that should be easy enough. The problem is that EPROM "fuses" are usually burned on the SOC. The secureboot check is hardcoded check that flag. You can't alter the bootloader without invalidating its signature, and it's practically impossible to unset an EPROM fuse.

Is bare metal Linux possible?

Bit of a story here.
So I have been long into car hacking, doing all sorts of canbus related modifications to my Merc W203 model.
The stock radio is utter garbage by today's standard, and Xtrons do a ton of android head units for my car. (Either with an A35 CPU and 2gb ram, or Px5 CPU with 4gb ram).
I am wondering, would it be possible to COMPLETELY remove android from it, and instead boot something like archlinux-arm on it. I want to create some custom applications on it whilst also having full control over the entire OS (Hence the want for Linux, not android).
I do kernel development as well so I am not worried at all about devices not working, I can likely hack together a kernel driver for nonworking hardware on the unit.
I am simply looking if it is possible to wipe android and see if it's possible to use it as a bare bones PC.
Any help would be appreciated, before I bite the bullet and spend £250 on one!:laugh:

You still need the GUI and stuff like that.
Besides, Android "is" Linux! Much better, imo, to base it off of Android, to keep the ecosystem that that comes with.

FransUrbo said:
You still need the GUI and stuff like that.
Besides, Android "is" Linux! Much better, imo, to base it off of Android, to keep the ecosystem that that comes with.
Click to expand...
Click to collapse
I am pretty sure by he said 'bare bones' does not mean an (Linux kernel based) operating system with only an command line terminal (i.e. something that looks like MS-DOS).

My point is that native Linux doesn't HAVE "mobile GUI". It have X11, which is *NOT* (!!) suited for such a project..
So either have to port whatever GUI Android have back to Android, or write his own. Which is a *MASSIVE* (!!) undertaking..
Also, Linux isn't quite suited for mobile applications. That's why Android was created. It took all the good from Linux and made it fit a mobile application.. Reverse engineering or back porting all that work to Linux is just dumb..

FransUrbo said:
My point is that native Linux doesn't HAVE "mobile GUI". It have X11, which is *NOT* (!!) suited for such a project..
So either have to port whatever GUI Android have back to Android, or write his own. Which is a *MASSIVE* (!!) undertaking..
Also, Linux isn't quite suited for mobile applications. That's why Android was created. It took all the good from Linux and made it fit a mobile application.. Reverse engineering or back porting all that work to Linux is just dumb..
Click to expand...
Click to collapse
Wait does the OP mean he need some thing like postmarketOS(some kind of Linux distribution with mobile GUI)?

Of course he does!! What do you think "Linux" is?!
Linux is *JUST* (!!) the kernel! NOTHING else.
The *distribution* is everything else. Boot procedure (scripts, commands, filesystem tools - technically that's "The Userland" - the install procedure, the packaging etc etc). Then you put your GUI on top of that.
On top of that you have X11. Or "The GUI". TECHNICALLY, X11 require some more stuff, the window manager too actually be useful. Without it (the window manager), X11 is just an API to the graphical functions - "draw window border", "draw a close button" etc etc. Which is what the window manager utilises.
So: kernel <- userland <- X11 <- Window manager <- Graphical apps
Then all of that is packaged up in a need CD/DVD/Image to make it easily installed and used. And we call that "The Distribution".
This is how UN*X works and that's how LINUX works. Simple, portable and very useful. But not for a phone, tablet or, in this case, a car!
That's why Android was created. It is ALL of that, in ONE package! With thousands and probably millions of apps compiled for it. Do it yourself, and you have to write EVERY (!) app you need yourself - radio apps, navigation etc etc ad-finitum..
Because NO ONE/THING (except in very rare occasion) "talks" to the kernel. They "talk" to libraries (libc, libX11 etc) to do what they need. Which is why you need "The Userland". THEY (the libraries) then "talk" to the kernel (networking, filesystem, input, output etc) giving the apps a nice API - "Application Programming Interface". A set of functions and tools for applications to use, so they don't have to recreate "the wheel" every time.
Now, I'm not going to go deeper, unless you want me to . I do understand that the un-initated don't know the difference between "Linux" the-kernel and "Linux" the-everything. But this *IS* important, believe it or not..
The kernel is absolutely useless on its own. It can't do squat! It was never MEANT to be used on its own. It was designed and built to be used *with* a distribution - "GNU" in the large majority of cases..
Although it's possible to use bare-bones Linux with either your own distribution (MASSIVE amounts of work, I know, I've tried it!) or an existing one (Debian GNU/Linux, RedHat, SuSE etc - they all provide binaries and packages for a multitude of processors), none of them have all the goodies that Google Play Store have.
And none of them are really targeted towards a mobile graphical environment.
Raspbian for example, was made for the Raspberry Pi, but that is in 99% of cases a non-graphical environment (robots and media stations mostly). Most distributions is like that.
The Play store on the other hand is *specifically* targeted towards a mobile, graphical environment. As this is. I would be foolish to try to reinvent the wheel when Android already IS Linux+userland+GUI+distribution.
Keep in mind though that Android apps on Google Play is compiled for an ARM (ARM64) architecture! Meaning, whatever hardware utilised, MUST run on/with an ARM processor..
All this limits the hardware choices substancially.

Everything "is possible". In theory. In practice though, I'd say the answer is "no". It is simply to much work to get it working. For absolutely no benefit.

With that being said... Bare Android on the other hand!! Now THAT is an idea.
Get your Android kernel source and compile it for the specific hardware you're using and then your Android distribution, set it up juuuuuuust so and you'll get what I (and probably everyone always wanted - a non-bloated piece of ... well, we've all seen them.

Ubuntu Touch?

I have a rooted phone that I would like to install linux natively that wouldn't need to do much except for access the phones camera and gps. (no other driver support necessary, not even display)
I was looking into UbuntuTouch (although, it could be any linux) and this guide here: https://devices.ubuntu-touch.io/installer/
I observed that it says "Devices generally require a specific version of Android/stock rom to be installed. This depends on the halium version the port is build on. For example, if the port is based on halium 9, make sure you have Android version 9 installed"
This is confusing to me, because if the new OS is replacing the stock rom, why does it matter what version it is on?
Looking at the ubuntu touch website, a lot of them still seem to be requiring Halium version (therefore android version) 9 and 10. But that seems pretty out of date, is there much work on installing Ubuntu Touch on Android 11 and 12. What if I have a new phone that launched recently and it doesn't have a firmware for android 10 or below. (or even for android 11)

Just like that, Ubuntu Touch must have a "host" OS. Analogy to apps that require a certain version of android, because they contain references to its properties.

ze7zez said:
Just like that, Ubuntu Touch must have a "host" OS. Analogy to apps that require a certain version of android, because they contain references to its properties.
Click to expand...
Click to collapse
hmm, Okay I didn't understand it needs a host OS... I thought its a standalone replacement. So if it installs itself onto of an existing firmware, Is the android OS still running beneath Ubuntu touch?

Devices - porting to a new device | Ubuntu Phone documentation
phone.docs.ubuntu.com
I'm not interested in Ubuntu Touch.
I installed it, saw what I was dealing with, and quickly gave up.

ze7zez said:
Devices - porting to a new device | Ubuntu Phone documentation
phone.docs.ubuntu.com
I'm not interested in Ubuntu Touch.
I installed it, saw what I was dealing with, and quickly gave up.
Click to expand...
Click to collapse
Thanks for the info. Yea it may not be helpful for me either. However, my use case may be different. All I want to do is write some native code, probably C++, and have it access the GPS and the camera. I don't need anything else working, touch, display, audio, cellular, wifi, etc, etc.

For more, see Ubuntu Touch on XDA.

For more, see Ubuntu Touch on XDA.

[Firefly] [ROCKCHIP] [ITX-3588J] ITX-3588J ARM Android/Linux Dual "Deskphone" Progress

First off, I wanted to say I posted a few threads about this thing here asking questions about stuff I needed to get it working in the way I'd like and I'd want to thank you because I have made a lot of progress in getting it to be what I'd like it to be. I also don't know if this is the best forum to post this report because it's neither a question nor necessarily a tutorial but rather a summary and description of work already done so far, and especially because this device, while it sure runs Android (very well!) does not fit into any of the categories on this site neatly.
The story so far
This post concerns my experience working with the ITX-3588J, a board released just a few months ago by the Chinese manufacturer Firefly (or T-Chip Intelligent Technology Co. Ltd, based in Zhongshan) that is in the coveted mini-ITX form factor which means it can actually fit into a small-size desktop computer case and indeed has enough compute power to theoretically - and perhaps not so theoretically! - function as an honest desktop system with an ARM processor: namely the - also very new - Rockchip RK3588 system-on-a-chip.
About two months ago, I was looking into acquiring a new kind of computer to replace my somewhat longer on the tooth x86 machine that would be compact, low-power, and easy to transport while also being a fully capable desktop. And I certainly didn't want Apple. I had seen some very small form x86 desktops before, but I also knew there were many boards - like Raspberry Pi - that featured the ARM processor. Not content with the Pi, which is still very weak for this application at least when compared against modern software, I wanted to see if there was something else by now in a similar vein, and when I saw this board I thought it was an amazing option, esp. given I have not yet found a peer. Many ARM single-board devices exist but this is the only one I've found so far that looks to be in a proper desktop form factor and sporting a processor powerful enough to work at that level.
So I got the board, a case, and - noting it had SATA ports - a cheap 250 GB SSD, and put it all together ... and fired it up! And to my surprise, it booted up Android! Which was a real shocker because I generally thought this'd be like another PC board, not having had much experience with this ecosystem beyond phones, so that it would just give the usual "OS not found" stuff. Nope - pre-loaded on the board. Very minimal, very bare-bones though, not even the Google Play and similar essentials required for a usable Android experience. Yet with the little bit I had, I couldn't help but notice it was extremely fluid, responsive, and snappy, moreso than my aging 2018 era x86 box. Moreover, it was very, very interesting (and exciting!) to see Android booted onto a full-size monitor screen like Linux or Microsoft Windows - and actually and surprisingly, to see that it didn't look and feel all that bad!
However, of course, I wanted more. First, I wanted a fully-featured installation of Android. Second, I wanted to run Linux on it - especially given that, a short while later, I found that the board manufacturers were offering a stock Ubuntu 20.04 to be installable to it. Although, in the early stages, I didn't know how to do this at all, and then soon after learned how to reflash the embedded MMC chip to change the OS. And I did so, trying the Ubuntu and finding it also very performant, but not liking either that it was not quite the newest version but also more that it was mutually exclusive with Android - so far.
And that would begin a long - and at many times frustrating, especially given how much information out there is not at all tuned to a device like this being pressed into this application - learning journey toward exploring topics as diverse as how ARM processors and SoCs work under the hood, U-Boot, kernel features, the Firefly-Rockchip developer kit - and having to essentially single-handedly discover many of that kit's ins and outs given there was pretty much no documentation - and more, ultimately leading to where I've got it to now.
What it can do at this point
And that is, right now, I have it sitting here, loaded up with the stock Android 12 and Ubuntu 20.04 - with the former on the eMMC and the latter on the SSD hard drive. On the Android side, Google Play is now loaded and functional, though Google Chrome is not (it crashes with a "Telephony is null" exception for some reason, which seems to suggest for some reason it's trying to act like it's on a phone but isn't). Zoom - an app that I really, really wanted to have (and why I wanted to keep Android around on it) - works and works smoother and cleaner than my 2018 x86 Linux clunker. On the Ubuntu side, though, things are not yet coming - mostly because of seeming inability to use U-Boot to boot from the SSD. I managed to install GRUB, and given that Firefly's generous board SDK provides the full U-Boot source code was able to recompile it with the necessary "bootefi" command enabled which is not present in stock, but nonetheless alas this U-Boot seems to have its SATA support bugged or incomplete, because it would crash immediately upon trying to initialize that subsystem.
Where I'd like to go with it
Obviously, full dual boot of Android and Ubuntu, so getting U-Boot to boot the GRUB resident on the hard drive, is the biggest issue so far, and that means investigating whatever is the problem (or not?) in its SATA subsystem. Getting Google Chrome working on Android is another important step. Moreover - though it would cost extra money that I do not have right now - there's the very interesting possibility, owing to the fact that it has a built in M.2 slot on the board, and alluded to in the title - that the device could be made to act as a cell phone. And finally, the possibility of upgrading to a newer version of Ubuntu (ideally 22.04) - however from what I know so far, it looks like this will have to wait because the stock Linux kernels do not currently support the RK3588 fully - though I'd suggest the Linux kernel developers really should take a look at the SDK that came with this thing because it has lots of code in it including for the kernel, all under GPL.
Final note
One of the most interesting things I've learned from this project, and mentioned earlier, is just how well Android seems to work as a desktop OS. While there have apparently been some attempts to port it to x86, this is perhaps one of the first devices that is desktop-workable and which runs it natively. And one of the things I find that's nice about it is that ironically, because all the apps are designed for small screens, when they are run on a very big screen (and this monitor is not "very big" even by today's monitor standards, being a used and earlier LCD type), they are extremely easy on the eyes and have minimal UI clutter when compared to a typical desktop app on most Linux WMs and on MS Windows.
If you want to know more about the details, or anything else, feel free to ask any questions you might have!

UPDATE:
I believe I may have found an easier way to dual-boot Linux with Android, and that consists of configuring a custom ROM that will put both kernels, and GRUB, on the board's eMMC, while the rootfs for both OSes is placed on the hard disk. Will be seeing how it works.

UPDATE:
I have almost completed the custom ROM! I have now both Android and at least the base system for Ubuntu 20.04 (Kernel 5.10.66) bootable with Android now storing user data on the hard drive; though I'm still running into some hardware initialization issues in the latter that are keeping me from actually installing the desktop system. With regard to the Ubuntu system, there is some interesting issue in that for some reason the provided SDK kernel, which I had to rebuild, seems to build more Android-like because it wants to look in "/vendor" for some things related seemingly to the networking facilities, and it is possible this is preventing me from bringing up wifi, which I need in order to download the rest of the system.
But lots of progress overall - it seems that a full-fledged ARM desktop running simultaneously Android and Ubuntu is within reach to be wrung from this board!

Ignore my request for an update in another post. Seems you like you moving along. I don't need dual boot, just a working Android 12 with GPlay and Chrome. Did you get Chrome to work?

mebalzer said:
Ignore my request for an update in another post. Seems you like you moving along. I don't need dual boot, just a working Android 12 with GPlay and Chrome. Did you get Chrome to work?
Click to expand...
Click to collapse
Thanks. Yeah, I want to say that I have pretty successfully gotten Android 12 working on it for sure, but Ubuntu is proving much more difficult due to graphics support issues, and I'm not sure if it will be possible until RK3588 is supported in the mainline Linux kernel tree which is still something under development. And yes! I got Chrome to work Everything works, actually - it's great as an Android system, though obviously Android is kinda funny to use as a desktop OS. I am wondering if I can't get a "pseudo" Linux using something like Linux Deploy in lieu of running it natively, at least until the kernel development catches up with this new processor.
(FWIW, I'm posting this post from that machine while it is running A12. )
Good to see someone else is interested in it, though. What are you planning on using yours for?

Insofar as getting Android 12 to work w/GApps - it depends on if you want to do it purely on the eMMC or you want to also put user data on an attached hard drive like I did. In either case, the best option, I feel, is to create a custom ROM - I could provide custom ROMs for it for download, but don't know because of Google's licensing conditions around the GApps and have heard of people getting in trouble with Google for distributing custom ROMs for phones that have GApps in them. You basically need to unpack the stock Android image, unpack the "super.img", then load the apps from a package like NikGApps into the "product" partition (NOT "oem" - that was a big mistake), then repack everything and flash to the eMMC again. You will need the board SDK from Firefly for all this as it has the custom ROM-packing and flashing tools.
Alternatively, it is possible to manually install the NikGApps GApps using the Android console - as it's a fully unlocked system, obtaining root access is trivial: just put it into Developer mode and you will find the root access in the "Developer options..." menu under "System".

Shimmy99 said:
Insofar as getting Android 12 to work w/GApps - it depends on if you want to do it purely on the eMMC or you want to also put user data on an attached hard drive like I did. In either case, the best option, I feel, is to create a custom ROM - I could provide custom ROMs for it for download, but don't know because of Google's licensing conditions around the GApps and have heard of people getting in trouble with Google for distributing custom ROMs for phones that have GApps in them. You basically need to unpack the stock Android image, unpack the "super.img", then load the apps from a package like NikGApps into the "product" partition (NOT "oem" - that was a big mistake), then repack everything and flash to the eMMC again. You will need the board SDK from Firefly for all this as it has the custom ROM-packing and flashing tools.
Alternatively, it is possible to manually install the NikGApps GApps using the Android console - as it's a fully unlocked system, obtaining root access is trivial: just put it into Developer mode and you will find the root access in the "Developer options..." menu under "System".
Click to expand...
Click to collapse
Thanks I will keep this in mind. See my reply to you other reply on another post as well.

I would to run gplay as well please send me instruction the nikapps github doesnt say nothing