I'm wondering if you should have a common kernel or if the kernel
should be Atom-optimized or non-optimized, too. AFAIK SSE3
instructions aren't used by the kernel at all, so it would only be a
difference of selecting another target CPU to optimize it for - and
the kernel doesn't really have a huge impact on performance anyway.
Stefan
> --
> You received this message because you are subscribed to the Google Groups
> "Android-x86" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/android-x86/-/bueMVoMCtWQJ.
>
> To post to this group, send email to andro...@googlegroups.com.
> To unsubscribe from this group, send email to
> android-x86...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/android-x86?hl=en.
this is a good idea, one (two) images for all devices! Then also no
special builds or device trees for my WeTab would be necessary anymore.
Beside of this a few "little" things could be important:
1. Include support for nVidia graphics drivers
2. Include support for Video-Acceleration and TV-Cards in general - the
cystal-HD-support could be a first step there, also ATI, nVidia and new
Intel chipset have video acceleration support which could be added by
this work
3. Add suport for hardware keyboard localisation
By the way, a few days ago I have read that the Linux Kernel guys
started over to again backpoprt Android Kernel changes to the official
Linux kernel, final target would be to have again only one kernel for
all. I think this would be the best solution of all as the Linux kernel
can support a lot of things where Android kernel guys are still working
on (for example by back porting Linux kernel features...).
This is what I have read about it:
http://www.golem.de/news/linux-weitere-android-patches-fuer-kernel-3-4-1203-90394.html
That is the project: https://lkml.org/lkml/2012/3/7/610
So maybe in future Android X86 could just use the official kernel.org
kernel???
Stefan
> --
> You received this message because you are subscribed to the Google
> Groups "Android-x86" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/android-x86/-/q1Wr1JqI2V8J.
The squashfs idea is great.
I started working on a recovery "3rd" stage boot loader for research purposes, but I think your approach is the way to go.
Also: could be nice to integrate into it an adb extension for the remount option, and hmmm... possibly a USB connectivity? Just a thought..
Anyway - I hope that non-atom Intel processors are also kept in mind - I use some core i5 and core i7 for my work, and I intend to elaborate on it.
One more serious issue: full 64bit support.
Android can be an Amazing X-86 platform - not only for the mobile.
--
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To view this discussion on the web visit https://groups.google.com/d/msg/android-x86/-/VxIUmivBvioJ.
> 1. I want to suggest using AuFS or UnionFS to make it possible to update/enhance the base system with the use of "add-on" packs. This is similar to the "update.zip"
and thank you all for your feedback right now. Just now, I want to
emphasize an important distinction here: it's clear that improved
hardware support like nVidia graphics or 64bit (guess Google will have
an ace up it's sleeve here) or you-name-it will be always an ongoing
task. But my important point is not that, because it happens anyway
(or should, at least). So don't use this thread as a wishlist, because
it won't do any good - I think it's fairly well known what hardware is
not supported and what features _could_ enhance the project. The only
way forward about this is that people will get their hands dirty and
code.
My argument was that _any_ new feature or hardware supported should go
into a common device tree, so that IF someone implements nVidia
support or whatever, it will not be yet another ISO to download, but
just an updated version of _the_ "Android-x86" ISO.
Stefan
I understood your question like that. I just had added a few really
annoying points like keyboard-layout/nvidia just to not forget these.
But my impression is that you missed the key point of my message:
Let's have a look on these backports from Android Kernels into the
Standard Linux Kernel. Maybe even support these peoples in adding more
Android changes to the Standard Linux Kernel. AND then, not use anymore
an Android specific kernel, BUT the always latest Standard Linux Kernel
for building the Android X86. Transform Android X86 into just another
portable devices optimized Linux distribution which is running the Apps
from Android Market. Maybe then it also would be able in the future to
switch between Android User Interface and KDE/Gnome/... just on
requirement and without rebooting.
(That, except of the last sentence, is also the way Microsoft goes with
Windows on ARM (WOA))
Also the above problems with nVidia, Keyboard, Video-HW-Acceleration
would be solved immediately with the use of the standard Linux kernel.
Stefan
On Mon, Mar 12, 2012 at 14:47, Stefan <matthaeu...@googlemail.com> wrote:
> Also the above problems with nVidia, Keyboard, Video-HW-Acceleration would
> be solved immediately with the use of the standard Linux kernel.
Well, actually, not at all, I'm afraid.
Not a single of those issues mentioned would be solved by using the
standard Linux kernel. For one, Android uses kernel extensions which
have not yet been accepted by the kernel maintainers. Have a look at
Xen and how long it took them to get even a minor subset of their
changes into the kernel, and you know what to expect.
nVidia - yes, kernel modules are necessary, but more important is the
Mesa part, so kernel doesn't help.
Keyboard locale - needs to be adressed in Android, possible, but just
no-one bothered yet. Kernel doesn't deal with it at all.
Video+HW-Acceleration, same issue. Yes, a kernel driver is often
needed, but if the already exist in the standard kernel it's a very
minor thing to backport them into the Android kernel. Much bigger
issues are to be dealt with in Android itself. Ask René if you like.
So - the kernel isn't the problem. In fact, the kernel is probably one
of our least problems, just because there is a mainline kernel to
borrow from. If you think that's not a good way to go, ask the
longterm kernel maintainers (2.4, 2.6.27, 2.6.32 etc.). They do this
all the time.
In fact, many people overestimate the role of the kernel. The kernel
just provides basic hardware support, so yes, nothing would work
without it. But once the kernel supports all your devices, you need to
make them work in the higher levels of the OS, which usually is much
more work. For example, the old wacom pens work on a serial interface.
You could probably use a 2.0 kernel and they work. But you need an
extra "converter" program to make Android recognize them as input
devices. Same goes for graphic cards: yes, the kernel needs to
initialize the PCI(e)/AGP device bus and maybe in recent kernels
provide some basic access features (KMS), but writing an OpenGLES
compatible driver for a graphics card is much more work.
I've run Linux distros on kernel versions one or two minor versions
higher or even lower than they were supposed to, and never encoutered
serious problems (e.g. running SuSE which came with 2.2 kernel on 2.6
kernel), and I know that on Android phones people also switch kernels
like their underwear, so we should just make sure the kernel works in
general for the devices we want to support, and concentrate on the
higher OS levels.
Also, on a more general note, I want to emphasize, that unlike Android
on phones, we're not heavily restricted in terms of space. My kernel
config has almost all modules enabled and they amount to only 23MB of
space, which is further reduced by squashfs compression, the kernel
itself is 2.4MB. The total image including all currently available
MESA drivers and kernel modules AND Google Apps is only 155MB, no-one
would care if it was 200MB. So, while building device-specific targets
may be reasonable for phones (e.g. my Milestone only has 155MB
internal storage), it's simply not needed for x86 computers, since
anything under 512MB storage is probably not even available on the
market.
Stefan
>
> Am 12.03.2012 09:11, schrieb StefanS:
>
>> Hello,
>>
>> and thank you all for your feedback right now. Just now, I want to
>> emphasize an important distinction here: it's clear that improved
>> hardware support like nVidia graphics or 64bit (guess Google will have
>> an ace up it's sleeve here) or you-name-it will be always an ongoing
>> task. But my important point is not that, because it happens anyway
>> (or should, at least). So don't use this thread as a wishlist, because
>> it won't do any good - I think it's fairly well known what hardware is
>> not supported and what features _could_ enhance the project. The only
>> way forward about this is that people will get their hands dirty and
>> code.
>>
>> My argument was that _any_ new feature or hardware supported should go
>> into a common device tree, so that IF someone implements nVidia
>> support or whatever, it will not be yet another ISO to download, but
>> just an updated version of _the_ "Android-x86" ISO.
>>
>> Stefan
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Android-x86" group.
So what changes do we have now:
1. Kernel command line.
2. Additional kernel modules, we could live without, but it does make
live a lot
more easy.
3. Android hardware drivers, some we can handle with the "board" name,
so maybe
4. adding system apk's, and other "configuration files" etc.
If we can find them during initrd, that should not be a problemn.
5. Initial user apk's.
Would be nice, but needs a lot of thinking.
Again I think there are two options.
a. Create a tool to change /system in the generic iso.
b. Find a storage space, where the additions are stored, and include a
way to add the stuff in there during boot.
To summarize, yes Stefan, I thing we could need a new setup for device
tree's.
It would require effort, I am willing to spend (the few time I can
spare) to help.
Lets hope more people will step in.
-------- Original-Nachricht --------
Hi Stefan,
On Mon, Mar 12, 2012 at 14:47, Stefan<matthaeu...@googlemail.com> wrote:
> Also the above problems with nVidia, Keyboard, Video-HW-Acceleration would
> be solved immediately with the use of the standard Linux kernel.
Well, actually, not at all, I'm afraid.
Not a single of those issues mentioned would be solved by using the
standard Linux kernel. For one, Android uses kernel extensions which
have not yet been accepted by the kernel maintainers. Have a look at
Xen and how long it took them to get even a minor subset of their
changes into the kernel, and you know what to expect.
<< Then I think it would be a good task to work on this acceptance.
<< http://www.golem.de/news/linux-weitere-android-patches-fuer-kernel-3-4-1203-90394.html
<< https://lkml.org/lkml/2012/3/7/610
<< Get in touch with John Stultz from that site to accelerate this process. Invite him to join this group, etc...
nVidia - yes, kernel modules are necessary, but more important is the
Mesa part, so kernel doesn't help.
<< Agree for mesa, who is working on this?
Keyboard locale - needs to be adressed in Android, possible, but just
no-one bothered yet.
<< Not true, if I scroll back in the messages here on the list, I find many requests for hardware keyboard localisations
Kernel doesn't deal with it at all.
<< Ok, it's not kernel, but a standard Linux distribution has some mechanism for it, this thing should be integrated into Android. It should be combined with the language/virtual keyboqard setting.
Video+HW-Acceleration, same issue. Yes, a kernel driver is often
needed, but if the already exist in the standard kernel it's a very
minor thing to backport them into the Android kernel.
<< porting back and forward from one kernel to another might be an easy task, but it takes time you could work on other things. So why not unifying the kernel with the one from standard Linux.
Much bigger
issues are to be dealt with in Android itself. Ask Ren� if you like.
<< I have read his posts about this.
So - the kernel isn't the problem. In fact, the kernel is probably one
of our least problems, just because there is a mainline kernel to
borrow from. If you think that's not a good way to go, ask the
longterm kernel maintainers (2.4, 2.6.27, 2.6.32 etc.). They do this
all the time.
<< Anyhow, you are doing double work which already has been done by the Linux kernel guys. Or those guys woking on mesa, X and other things.
In fact, many people overestimate the role of the kernel. The kernel
just provides basic hardware support, so yes, nothing would work
without it. But once the kernel supports all your devices, you need to
make them work in the higher levels of the OS, which usually is much
more work. For example, the old wacom pens work on a serial interface.
You could probably use a 2.0 kernel and they work. But you need an
extra "converter" program to make Android recognize them as input
devices.
<< Then better working on this interface than always backporting things from one Kernel into another
Same goes for graphic cards: yes, the kernel needs to
initialize the PCI(e)/AGP device bus and maybe in recent kernels
provide some basic access features (KMS), but writing an OpenGLES
compatible driver for a graphics card is much more work.
<< I agree with OpenGLES. But, doesn't that already exists and only has to be converted to X86? Or is nVidia Tegra graphics so much different from Geforce line of graphics chipsets?
I've run Linux distros on kernel versions one or two minor versions
higher or even lower than they were supposed to, and never encoutered
serious problems (e.g. running SuSE which came with 2.2 kernel on 2.6
kernel), and I know that on Android phones people also switch kernels
like their underwear, so we should just make sure the kernel works in
general for the devices we want to support, and concentrate on the
higher OS levels.
<< Don't tell me too much about Kernel versions, etc... Ok, I wasn't working on the source codes, but I have been tester for new kernel modules for brand new PC hardware in one of my previous jobs a few years ago. I also was able to forward chipset documentations to some of the developers. For example there wouldn't have been any good working driver for SIS integrated graphics chipsets about 7/8 years back...
Also, on a more general note, I want to emphasize, that unlike Android
on phones, we're not heavily restricted in terms of space. My kernel
config has almost all modules enabled and they amount to only 23MB of
space, which is further reduced by squashfs compression, the kernel
itself is 2.4MB. The total image including all currently available
MESA drivers and kernel modules AND Google Apps is only 155MB, no-one
would care if it was 200MB. So, while building device-specific targets
may be reasonable for phones (e.g. my Milestone only has 155MB
internal storage), it's simply not needed for x86 computers, since
anything under 512MB storage is probably not even available on the
market.
<< I fully agree with you. My WeTab has 2 GB of memory, some here like to use a core i3/5/7 processor based laptop for Android, it was already running smooth and nice with one GB with Android X86 on my WeTab, and a 32 GB SSD is more than the most smartphones and ARM tablets are having - and I can buy a 120 GB SSD for it, give me five minutes to swap it over... So don't care on ten more firmware files, twenty more Wifi kernel modules, three different graphics drivers (Intel, AMD/ATI, nVidia) in the image, that does not care as long as the most Android Apps are happy with a file size of up to 50 MB.
Stefan
On Mar 12, 2012 5:01 PM, "rvdb" <rene.van....@gmail.com> wrote:
>
> Stefan(S),
>
> > > 1. Kernel command line.
> > Yes, indeed, although what do you really need?
> Well, my device should not have a acpi_sleep.
> So in general it might be usefull.
Actually, no devices need it anymore because these ACPI quirks are handled in the kernel since several kernel versions ago.
> > Additional modules are so uncomplicated. Just have them all in the image,
> > and do the modprobe'ing in the xxx_info script (detect_hardware).
> Oke, but then we can not have conflicting modules.
> Search for atk3k, in real kernel already a problem for a few years, on
> different hardware.
> I could live without it, but a possibility to overwrite a module,
> would be nice.
Yes, exactly what an update file could do. But you can just rename your module and modprobe it when needed.
>
> > That's what I meant, but I have the feeling you imagine it too complicated.
> As always :-(
>
> > Already the init system is looking for the system.img/system.sfs file and
> > mounts this as /system. It is, I believe, trivial to add at this point a
> > function that finds files called update-*.sfs which lay at the same place
> > (or SD card or wherever) and do a unionfs/aufs mount with them _over_ the
> > /system mount. This means that any file contained in the update files will
> > appear instead of the original file. So the user can have an update file
> > with maybe very new kernel modules and a newer _info script to load them,
> > he can have a update-apps file containing the Google Apps and so on.
> >
> Is you're idea to have all the "device-trees" IN the generic image?
> I believe it would be helpfull if they are not (gapps).
That's exactly the point! gapps would be an add-on. Look at the Cyanogenmod Wiki. They distribute "plain" images and offer gapps as a separately downloadable package.
Stefan
>
> Greetings Rene.
Basically speaking, I like StefanS's idea.
If the goal could be achieved, it does solve
some difficult problems we suffer now.
Personally I'm familiar with Aufs technology.
I did some projects with Aufs author before.
Actually I also considered to use it when we
started android-x86 project, but finally
I thought we don't need it, at least at that time.
Anyway, it's a good idea to do customization
by "overlay" some files via aufs.
Though there are still some unclear points
that need to be clarified.
Let me consider the possible infrastructure changes
(provided I have time :p)
If you already have some, please provide.
--
Chih-Wei
Android-x86 project
http://www.android-x86.org