Database Info

[Dev] Who wants to port ZGrom or GMenu2x?

Here's a link to the project:
http://code.google.com/p/zgrom/
A cut&paste from the page:
ZGrom is a gaming oriented distribution for Sharp Zaurus PDA devices. It's a console based distribution built around the Gmenu2X SDL GUI. ZGrom has a wide selection of quality emulators, game engines and apps. Currently, ZGrom only supports the following Zaurus models:
•C-1000 - Akita
•C-3000 - Spitz
•C-3100 - Borzoi
•C-3200 - Terrier
ZGrom comes with GINGE. In a nutshell, GINGE enables ZGrom users to run unmodified GP2X binaries. Some of the emulators and game engines that come with ZGrom are plain, unmodified GP2X binaries that execute on Zaurus devices via the GINGE static loader.
A link to the gmenu2x page:
http://mtorromeo.github.com/gmenu2x/
A cut&paste from the page:
GMenu2X is a frontend application targeted at embedded devices, originally developed for the GP2X and successively ported to other devices.
GMenu2X provides an easy to use interface with quick access to the games and applications of the device trough links similar to those found on PC's desktops.
Its interface is fully customizable with skins.
Other features include: built-in selector for emulators, manuals and readmes integration, built-in overclocker, gamma and volume configuration, ram timings tweaker.
I started working with these but like with other projects... i'm short on time these days. The last of my efforts had a working kernel for these, only a keymap was needed to give to the zgrom developer to build a rootfs, and for someone to text and debug.

IMO the better way would be focusing on developing Android distro, because probably most people are still waiting for working Android on our beloving UNI! Anyway, your efforts are great and mainly because of you UNI developing is still alive!!! Good luck!!

l2tp said:
IMO the better way would be focusing on developing Android distro, because probably most people are still waiting for working Android on our beloving UNI! Anyway, your efforts are great and mainly because of you UNI developing is still alive!!! Good luck!!
Click to expand...
Click to collapse
Lol, I know, I’m taking a break waiting for another project to finish up:
http://forum.xda-developers.com/showthread.php?t=1948803
I’m working on shrinking android now; deleting unneeded library’s and functions to lower memory/processor requirements and running processes. This OS is better suited for people who don’t use their universal as a phone and only have 64mb of ram. I don’t have time to work on this either, the question “Who wants to port ZGrom?” wasn’t rhetorical; I really want someone to pick up where I left off porting it. And android for universals is mostly done all hardware except the cams work. Power saving, gprs, sound on both ends of the call all work… I just need to trim and speed it up….and learn some arm assembly to add in iwmmxt optimizations.

I understand that 64 MB of RAM is too little to run any recent Android version (and by recent I mean higher than 2.2), so it'd be good if there was some alternative OS to bring life to old Universals with the standard RAM - even if that new 'life' doesn't including phone abilities. I don't think the PXA 27x CPUs aren't really that optimized to run Android either (Android can be slow on ARMv6, let alone ARMv5). I'm not telling you to give up on the Android thing; just trying to make people realize notime can't focus forever on something that can't be further optimized... but if it can, then just go ahead
In that sense, I support any development efforts towards something that's not Android.
Also, the work done in porting recent Linux kernel versions can be used not only in Android but in any other Linux-powered OS porting. I may have a go at it... once I format my computer with a bigger ext4 partition (currently out of space to install any kind of cross-compiling tools or SDK) - and this can get delayed for several months.

I was playing around with my Universal (with a dead battery), running old Linux distros on it (with things like Qtopia and Opie), when I started thinking if there wasn't a more recent thing to run other than Android. Then I remembered I had promised to try to port this thing once I got my computer formatted...
Actually I have already formatted my computer and now I have a mostly free >250 GB ext4 partition. I'll only be able to start working on this in the beginning of July, however.
This seems like the perfect use for a Uni that doesn't survive when it isn't charging.

CuBox-i. The little computer that can.

Hi,
I hope that this is the right forum in xda to discuss this; but I'd like to introduce CuBox-i; a tiny 2"x2"x2" scalable mini computer that has up to quad ARM processor; quad GPU shader, up to 2GByte memory that is based on Freescale i.MX6 SoC.
The machine is powerful in it's specifications and already has a community around it that fully supports it from software point of view (kernel 3.10 LTS, also upstream work in parallel, lots of distributions etc...)
The biggest advantage of this machine vs. others is it's 64bit DDR memory interface that provides a thick pipe that the GPU, processors and video engine can utilize without hitting walls on 1080p resolutions. Within the interesting features is 1080p HDMI with CEC, power USB hosts, infra red receiver and transmitter, Gigabit Ethernet etc...
We already provided Android 4.3 images and now working on Android 4.4. Look for github rabeeh/android-imx6-kitkat (I can't send the link since this is my first post on xda).
There have been numerous Linux ports already done, including XBMC support; mainly by the community around CuBox-i -
(Again, can't send link; just google "CuBox-i wiki" or "CuBox-i forums" and you will find it).
What we are trying to achieve now is perfecting Android on CuBox-i; with that we are looking for developers that are willing to provide from their spare time to contribute to this project. We have issues already posted on the github issues tracking system.
Needless to say that we will be providing the hardware for the developers for free
Please PM me if interested.
Best Regards,
Rabeeh

Bump!!!

Did you use perhaps the cubox i pro 4?
I am really searching other guys who try to bring the android-os forward.
First I use OpenELEC/kodi - Helix, but I want more from that great hardware, so decide to install android (android-4.4.2-1.0.1b-ga-aaf118bb78-gapps.img.xz). Works good but not perfect.
-There is no IR-Sensor Support or CEC to controll the interface with e.g. Samsung-TV remote
-Another launcher (I mean the gui) should be neccesary. I like this here:
-I think this is the android rom- ->This is not for the cubox!
-Here some more Android-FW's- ->They are not for the cubox!
-I think the hardware is not 100% supported. Antuntu gives worse scores and some app crashes again and again or some video stock while playing.
-My Teufel Decoder-Station don't recognice dolby or dts.
I you have no cubox and wanna help I can only replay:
Needless to say that we will be providing the hardware for the developers for free
-Full source code support is available here-
Greetings by I_did_it_just_tmrrow

http://www.solid-run.com/community/ ENJOY i have the i4pro there is like 3 differnt versions of XBMC there

I am using the beautiful product that Rabeeh c.s. made: the cubox has a nice spot in my network. It is my NAS and my media-server among other things. And it's all based on Android (in my case 4.3). I am impressed by the things that developers can do in this Linux-environment. There seems to be a solution for every wish or problem. Thanks to you all. I am hoping you can also find a solution for the problem I posted on the cubox-community: "The one thing that is missing on my amazing cubox-i-installation is the possibilty to remotely control the android "desktop" on my cubox-i from my tablet or phone. There are several sollutions for it, but all my attempts fail on the same error: the apps all give the message that there is no internet-connection. I don't understand what is happening here. Obviously I do have an internet-connection to my cubox-i. I use it to download the apps. The only explanation I can think of, is that the android-app expects a Wifi-internetconnection and unfortunately, my cubox-i only has an ethernet-connection. Can anyone tell me what to do to let the app find my internet-connection? For example: which modifications should i make on the driver of the ethernet-adapter? The apps I tried to install, all look promising: Teamviewer, Bomgar, google remote desktop. They all will install without any problem, but they refuse the final step of getting an ID for remote access because of connection-problems."

[Q] Is the Dinosaur Extinct?

I like this phone. Feels good in my hand. Did the job fine with Froyo. When the GB update never came, rooted it and began a new hobby (obsession?). Now running a 4.4.4 Omnirom. Works mostly quite well. Doubtful if there will ever be Lollipop.
I do not need a quad-core screamer. This is a mobile phone and information device. I am not playing Grand Theft Auto on it, and if I spend time viewing my favorite flicks, there will be no battery left when I need to phone home. Wife will not be happy (unless here battery is also dead for similar reasons so will never know).
However, more and more apps will not run. Armv6 is definitely on the outs, even though some providers still sell such phones. Running old Maps version, Google Now does work, sideloaded, with an online-voicesearch-wrapper. Not bad, in all.
But maybe time to get a newer device. Or maybe another OS ...
Android was designed to be a Java-based Linux. Apps written would simply install and run on any hardware. No need to compile for that Atom or other chip. Simply played. The way it was supposed to be. (Gnu Linux depends on Gnu C and C++ compilers, and every distro needs to maintain app package variants for various HW architectures. Android was to be the alternative with one app store ...)
and then, devs started incorporating pre-compiled JNI (Java Native Interface) components. These are compiled (using the Gnu compilers?) for specific architectures. Read Armv7. Lets out our devices, Intels, etc. It is too much trouble to maintain multi-architecture apps this way. Armv6 is obviously obsolete, so goes by the wayside entirely. Most apps are not opensource even if I were to compile them myself.
This destroys the whole idea of Android and Google is the worst offender. How long till that shiny ridiculously priced flagship ends up like our device? How long to only 64 bit is supported (definitely need 64-bit on a ... phone!)? How long till Armv8, 9, .... Maybe time to forget about Android all together. Google is the prime offender.
Problem is that Windows and Ubuntu both need compiled Apps (though QML and HTML5 should be portable). Both do look good. Put in the Dalvik VM, just like Java gets installed on any distro, and made in the shade, can keep the more reasonable apps. Gnu tools should be available for Ubuntu.
Do not know whether this is the place for this tirade, but ... what say you?

Why aren't there any universal ROM?

Why everysingle device have his own ROM and there isn't a universal ROM for all devices? I know, every single devices have lots of different features but why just a single HAL which load the appropriate drivers for each device's componente (speaker, io, chipset, etc)? (Like Windows, OSX, Linux Distros does) What is wrong with this? why not? Did anyone ever tried to build something like this?

Scr3w1912 said:
Why everysingle device have his own ROM and there isn't a universal ROM for all devices? I know, every single devices have lots of different features but why just a single HAL which load the appropriate drivers for each device's componente (speaker, io, chipset, etc)? (Like Windows, OSX, Linux Distros does) What is wrong with this? why not? Did anyone ever tried to build something like this?
Click to expand...
Click to collapse
This will take to much space to hold every driver of every device and the partition sizes are limited

Scr3w1912 said:
Why everysingle device have his own ROM and there isn't a universal ROM for all devices? I know, every single devices have lots of different features but why just a single HAL which load the appropriate drivers for each device's componente (speaker, io, chipset, etc)? (Like Windows, OSX, Linux Distros does) What is wrong with this? why not? Did anyone ever tried to build something like this?
Click to expand...
Click to collapse
Some software needed to be in a specific processor/cpu or hardware,every model of device is working differently even though their brand are same and the name of the phone is same,like there are exynos and snapdragon for samsung galaxy s flagship phone and they are working differently.maybe in the future there is but it will need experienced engineer or whatever it takes to build an os that work for every phone,and of course it is costly to maintain the development like the remix os.but it just nearly impossible(maybe not).

You know that when you install Windows, you still need drivers for almost everything, motherboard, gpu, some ssds need drivers to work properly. Maybe in the future because device space is increasing and we might have like chromebooks, 2 partitions for drivers and system files, then after installation, it determines drivers and loads them, then deletes the rest of the double partitions and cleans up. This will take up space though, a lot. And it will take a heck lot of space and will most likely only be available for new devices because what's the point of having devices from 2016 and their files in a ROM for devices from 2020 etc. Space is the only limitation.

Not Possible.
Every manufacturer built it's system using public patents (like IEEE 802.11) and multiple private patents, that they acquire or researched. This way all the companies have different architecture means different drivers set and hardware settings. In order to achieve something that you are describing, they have to agree to 1 manufacturing standard (and believe or not no company will agree to this thing). As another person wrote above about installing many drivers and stuff. This will make the ROM extremely heavy and it will take allot of time each time, it will start as it have to check the system and load all the drivers compatible. This is the thing Richard Stallman is saying for many years but close system developed by each and every company have produced 'restrictions on each and every side of the technological field'

strongst said:
This will take to much space to hold every driver of every device and the partition sizes are limited
Click to expand...
Click to collapse
Well, nice point, honestly how much space are we talking about? We may just have some generic drivers (like windows) and some thirdy part proprietary drivers to download separately
Thunderoar said:
Some software needed to be in a specific processor/cpu or hardware,every model of device is working differently even though their brand are same and the name of the phone is same,like there are exynos and snapdragon for samsung galaxy s flagship phone and they are working differently..
Click to expand...
Click to collapse
Linux (And Windows as well) is/was designed to run on a very large number of platforms, like RISC, ARM, X86, AMD64, IA64 etc. Both Exynos and Snapdragon processors are based on the ARM/ARM64 Platform so this kind of abstraction OSes do already from long time
Thunderoar said:
maybe in the future there is but it will need experienced engineer or whatever it takes to build an os that work for every phone,and of course it is costly to maintain the development like the remix os.but it just nearly impossible(maybe not)
Click to expand...
Click to collapse
We are a open source community, look at Linux kernel, everything is possible.
RAZERZDAHACKER said:
You know that when you install Windows, you still need drivers for almost everything, motherboard, gpu, some ssds need drivers to work properly. Maybe in the future because device space is increasing and we might have like chromebooks, 2 partitions for drivers and system files, then after installation, it determines drivers and loads them, then deletes the rest of the double partitions and cleans up. This will take up space though, a lot. And it will take a heck lot of space and will most likely only be available for new devices because what's the point of having devices from 2016 and their files in a ROM for devices from 2020 etc. Space is the only limitation.
Click to expand...
Click to collapse
"Space is the only limitation" Yeah but space is increasing, everyphone have at least 16 GB, only video drivers are very heavy, we may drive some generic video drivers (like xorg-amd, xorg-nvidia etc) All other drivers are relative lightweight, bluetooth, wifi, modems etc.
GenieKnudson said:
Every manufacturer built it's system using public patents (like IEEE 802.11) and multiple private patents, that they acquire or researched. This way all the companies have different architecture means different drivers set and hardware settings. In order to achieve something that you are describing, they have to agree to 1 manufacturing standard (and believe or not no company will agree to this thing). As another person wrote above about installing many drivers and stuff. This will make the ROM extremely heavy and it will take allot of time each time, it will start as it have to check the system and load all the drivers compatible. This is the thing Richard Stallman is saying for many years but close system developed by each and every company have produced 'restrictions on each and every side of the technological field'
Click to expand...
Click to collapse
I think we already talked about some aspect of this answer, private patents? CyanogenMod, AOSP, are opensource those roms run on kinda everyphone out there, we may just write a real "os" based on those roms. What do u thinK?

[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