I'm trying to build an android linux kernel for an amlogic meson3 processor. Specifically the current running Linux shows the display configuration is
CONFIG_AML_TCON_KR070PC7S
When searching on google, it turns out to be a "60P LCD screen KR070PC7S". However, it seems google does not search the source code repositories around the web to give an answer.
Thus the questions:
Where you can find the driver in source code? Or in pre-built obj binary?
Where you can find the datasheet of the LCD if the driver is not available?
Which other devices (model, brand) use the same display?
Is 60P LCD a standard interface? Where is the spec?
Thank you in advance for any answers or hints.
Google does normally index CONFIG_xxx in parts of the Linux mainline kernel OK. I suspect you're running a custom kernel where they haven't merged it back into the mainline and haven't placed the source in a publically indexable area.
There is nothing wrong with the latter under the terms of the GPL as far as I know, but the original hardware vendor should make the modified kernel source available to customers upon request assuming they have based the driver on GPL code. Otherwise they have no obligation to provide datasheets / code etc.
Related
I am working on my hello-android app, which involves using the VpnService class to inspect traffic from specific apps (if anyone knows a better method, please let me know). Doing so requires the TUN/TAP driver, which is not included in the Verizon Galaxy Nexus, emulated Galaxy Nexus, or Verizon Moto X, and is also not available via the Tun.ko installer app.
The android source appears to be a bit of a fragmented mess, and I'm trying to find a good resource for understanding things.
Specifically:
Google maintains 8 kernel source repositories and loosely maps some of the devices to those repositories. Does a more comprehensive mapping exist somewhere?
None of the real-world android devices/emulators I am currently using have a /proc/config.gz. Verizon customer support has encountered this issue before, and indicated that the manufacturer produces the image (Verizon sends their bloatware to them for inclusion). The settings page indicates that the kernel was compiled by a bot within Google proper. The kernel includes some default configs in arch//configs, but using that requires knowledge of the appropriate git branch and also the appropriate config from within that directory. There have been some indications that for a galaxy nexus, one should use tuna_defconfig (though that file is not always present for the arm architecture). Does anyone know of a robust process for determining the correct kernel config to use?
The kernel version (g9f818de in this case) does not appear anywhere in the git logs for kernel source repository (omap in this case, which is supposed to be used for the galaxy nexus). Does anyone know how to map kernel build numbers to a source repository/commit?
Once I find the correct source/version/config, I'll also need to be able to load the module on a non-rooted device. Attempts with test-modules yield either Function not Implemented, or EACCESS (don't recall the message).
edit: The build number -> tag mapping indicated in https://source.android.com/source/build-numbers.html does not appear to apply to the kernel sources (at least not the omap repository)
Any pointers to thorough and accurate documentation would be appreciated.
Edit - Partial resolution to original problem, but questions remain
I spoke with the guy who wrote the OpenVPN app, and he was kind enough to point out that:
Basically all 4.0+ should work out of the box with the VPNService API.
Also the Android 4.4 emulator is broken.
Does any one know the real difference between stock & aosp kernel? If know please describe in detail or give me any reference.
Currently I want to build an aosp kernel based on htc stock kernel.
Android uses slightly different approach. To interact with the hardware it has a special intermediate layer between drivers and Linux kernel (called Hardware Abstraction Layer). So, even if you port kernel to a new device, this does not mean that drivers will work there. I guess you understand this.
As for the question itself, I can recommend you to find a book of Karim Yaghmour
"Embedded Android". There is main differences between stock Linux kernel and Android modifications are considered.
I own a Samsung Galaxy 3 and want to port kernels available for other Android Devices. I have all building environment ready. I have C knowledge also. What exactly I dont understand is how and what all things porting involves, which codes should be modified in what way?
If someone could help me. It would be great.
Thanks in advance.
Ok I got it. But the real problem is I dont understand one thing.
What needs to be changed in the source code so that to make it compatible in other device? Can someone explain me that?
Idolon gives a good suggestion. In theory what is written there is true. In practice, it's a little more involving. I've been porting Android Kernel for months now. My goal was to have a custom S5PV210 processor module on my custom board with my custom I/O. I have the source code for Samsung's galaxy tab and several Samsung's android smartphone as well as a few versions (Froyo, Gingerbread) for the Samsung's Evaluation board (SMDKV210 for S5PV210 CPU). FYI, S5PC110 is a close derivative. Here is what I found out.
Eventhough all the device drivers are supposed to be built in a very modular way and independent from each other and you should be able to replace them with similar devices, the way Samsung did it is not exactly that. To give you one example is about power management. In many low level drivers dealing with hardware devices, it calls some specific routine for other hardware devices like power management chip. So, When you change the choice of drivers in the "make xconfig" or "make menuconfig" it will remove the source code of what you don't want and add the one you want but, there are still other modules that are calling the low level function you removed. When building, you will get tons of unresolved external because you removed a power management chip that your hardware doesn't have but is used in the source you started with. I looked through several Samsung's device source code and they have branched very early on. They have been adapted by different teams and it would be a major amount of work to go from one device to the other from one source kit.
Here is how I succeeded: I bought an S5PV210 evaluation board with an already ported Android Kernel (Gingerbread). All the power management and inter dependant issues where already cleaned-up. Then, form a working kit, I could change the device I needed (the one you can't buy without a 100K unit/yr commitment) without getting stuck with the interdependancy. Then I could even change LCD resolution (from 800x480 to 1024x768), touchscreen, Cell modem etc etc. The whole thing takes about a month worth of work with only one guy (me).
Starting with a Galaxytab or other commercial device made me waste months of headakes with no useful results but the thing I've learned.
There is one requirement to succeed on my approach. You have to know the hardware you are working on. As an example, you need to know what touch screen your hardware has (chipset) to select the driver and were is it connected to hook it up to the right device (USB, Serial etc). That the same thing for all other devices (power managemnt chip, keypad, backlight, LCD etc etc)
Hope that is useful to give you an idea of the work involved and how you can do it.
You should take a look at the cached copy of Android Platform Developer's Guide and at android-porting google group.
There is also an old but useful article about porting Android to Nokia N810, which will give you some hints about Android Linux kernel porting.
I am also into android porting stuff for quite some time I suggest the following route :
Read
You need to have basic knowledge of android porting and AOSP source code, directory stucture hierarchy.
I suggest you to start reading https://books.google.co.in/books/about/Embedded_Android.html?id=plHsngEACAAJ&hl=en
and also refer https://source.android.com/devices/index.html as good guys pointed out you can also google android porting related groups and become a member there, if you are stuck on a issue there are chances similar issue might have been faced by someone else previously.
Observe
AOSP code :
Parallely you need to dive in to the android source e.g from links like https://android.googlesource.com/ observe which components are placed where in the source code, what are the updates from previous android release (like ART replaced dalvik in LL), at top level there would be generic code, code specific to your hardware called HAL in hardware/ and device/ folder.
Kernel code :
In the kernel also you need to observe the directory structure and know which things lie where like SoC specific code will be in arch/ directory defconfigs (used for selecting kernel configuration) will be arch//configs/ directory.
Also there are good books available for linux kernel, you can google them and start reading them also.
While porting kernel you need to take care of following
1.If in the new kernel there is already support of SoC which is used in hardware to be ported then you need to add only device specific changes like suppose you want to port new kernel version to samsung galaxy s3, you can take a reference android kernel having exynos support and then you need to make changes only for adding support for samsung galaxy s3.
For that you need to have reference of some old kernel having support of s3, from there you can study patches which have been added to add support for s3 and port those patches to newer kernel.
Experiment
First you can only port the bare minimum changes required to up the platform, compile and flash it on your platform, then observe the output, if everything looks fine than go on for next changes otherwise try to solve the issue.
Thanks,
Devarsh
I am new to android technology. Can somebody answer few of my question:
What are the similarities and differences between linux kernel and android kernel?
What is the minimum hardware requirement for mobile device to have android support?
Whether it is required to have a touch-screen mobile to run android technology?
Q1. The Android kernel is the Linux kernel with added device drivers for the hardware components that are not supported by the pure Linux kernel. However, there are also other differences. Quoted from here, and here:
The Android kernel code is more than
just the few weird drivers that were
in the
drivers/staging/androidsubdirectory in
the kernel. In order to get a working
Android system, you need the new lock
type they have created, as well as
hooks in the core system for their
security model. In order to write a
driver for hardware to work on
Android, you need to properly
integrate into this new lock, as well
as sometimes the bizarre security
model. Oh, and then there's the
totally-different framebuffer driver
infrastructure as well.
You may also refer to this page for an opinion on this matter.
Q2. You may take a look at the Android 2.3 Compatibility Definition
(I haven't read it). For 3.0 the requirements are (quoted from here):
1GHZ processor, 512MB RAM, a display
screen that is at least 3.5-inches in
size
Q3. No, your device does not need to have a touchscreen to be compatible with Android. Refer to the compatibility guide above, but this is also evidenced by the first Android testing devices, that were running android (picture).
I am working on a system on which currently linux kernel and microwindows windowing system is running. Code of current linux system drivers is available to me. I want to port android on it, just as a hobby project.
can you please tell me what all understanding of linux-kernel is required to port it?
Please give me references (Books, Tutorials) to build-up understandings.
Thanks, Sunny.
P.S. I have basic understanding of linux.
Configuration of device is
450 Mhz ARM9,
64 MB RAM,
256 MB NAND
480x272 resolution.
Since you already have Linux up and running on your board you most likely won't need to have a deep understanding of the kernel. It will need to be modified, however, to include the following additional Android specific features. This may be as easy as applying some patches but it could be more involved.
Low Memory Killer
Android Logger
Android Shared Memory Subsystem (Ashmem)
Android Power Management (Wakelocks)
Binder IPC
In user space, Android uses its own display software called Surface Manager so you won't be using the Nano-X Window System (formerly known as Microwindows).
For an overview of what will likely be involved in a port, I would give the Android Porting Guide a read.
Websites on porting Android to other ARM based devices that may include helpful tips:
Beagleboard (Cortex)
Rowboat (I tried this one and it works)
Embinux
Zoom OMAP (Cortex)
OMAPpedia
Nokia Internet Tablet (ARM9E)
NITdroid
Neo 1973 (ARM9TDMI)
Benno Leslie's Blog
Intel Bulverde Evaluation Board (XScale)
NemusTech Blog
Sharp Zaurus SL-C760 (XScale)
EU Edge Blog
Online groups that may be able to help:
Android Porting
Android Internals
Android Platform
To start porting Android, a basic understanding of the changes to the linux kernels is required. Also, you'll need to understand which drivers besides the Linux are required.
linuxfordevices describes what was changed to the Linux kernel for the sake of Android. They also provide handy links like a diff of the changes they made....
On Android architecture, I found the youtube presentation Android Architecture]1 helpful.
I expect some issues in the display resolution. Android applications expect a number of standard resolutions. As a first step, I suggest to limit display to the next smaller size and then improve on this once it is up and running.
Since I've looked into Adroid for use in e-readers, I'm very interested in the porting myself. For this reason, I have registered for a (web based) training on android hardware (porting). I have looked for books etc. on the subject, but the books I found were much more on using Android and writing applications.
Have a look at these books as well:
Android - A Programmers Guide
Professional Android Application Development