Base requirements:
-must work on MacOS.
-must write all output files in out/.
-must behave sanely w.r.t. incremental builds.
If anyone has any experience in that domain, I'd love to hear about
it. Keep it short :)
JBQ
--
Jean-Baptiste M. "JBQ" Queru
Software Engineer, Android Open-Source Project, Google.
Questions sent directly to me that have no reason for being private
will likely get ignored or forwarded to a public forum with no further
warning.
We do this. Basically we key the kernel build out of the target
specific configuration Take a look at our changes - they're not perfect
in my view - but they work relatively cleanly.
Not sure about the MacOS part - but it gives you 2 out of 3 for sure.
For example for our 8660 target - the kernel is invoked here:
And it calls into this make file:
This code handles a few things we need to do (which may be relevant to
you). We compile the kernel modules and assemble some of them into the
system image with rest just left in out in the KERNEL_OBJ directory
(somewhere). The second thing we support is the building of dynamically
loaded kernel modules where the source is outside the kernel tree. One
final thing is that early on during bring up we sometimes use piggy to
load onto targets and we can switch that behavior on or off as needed.
Hope this somewhat satisfies your curiosity.
On 11/30/2011 3:49 PM, Jean-Baptiste Queru wrote:
> To satisfy my own curiosity, I'm wondering what it'd take to build the
> kernel as part of the platform build.
>
> Base requirements:
> -must work on MacOS.
> -must write all output files in out/.
> -must behave sanely w.r.t. incremental builds.
>
> If anyone has any experience in that domain, I'd love to hear about
> it. Keep it short :)
>
> JBQ
>
--
Dominic Binks: dbi...@codeaurora.org
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
JBQ
> --
> You received this message because you are subscribed to the "Android
> Building" mailing list.
> To post to this group, send email to android-...@googlegroups.com
> To unsubscribe from this group, send email to
> android-buildi...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-building?hl=en
This is not short, I apologize. But it is simple.
I have a solution that will meet your 3 requirements, and a bit more.
See the bottom of this email for instructions on getting the
pandaboard patch. See kernel.mk in the patch for all the added
functionality.
----------------
Believe it or not, building the kernel within Android is something I
have thought about since the Android 1.1 days. I am familiar with both
CAF's AndroidKernel.mk and with android-x86.org, albeit their older
solution.
This seemed like a good time to try and improve on their solutions.
Since I had a Pandaboard on my desk and my experience is with ARM
kernels, I did not attempt to integrate the android-x86 solution as
well. But I think that my solution could be extended without too much
effort.
Design goals:
1. Based on CAF AndroidKernel.mk
2. Remove the .mk from the kernel
3. Do not change any default behavior
4. Allow lots of per-device flexibility around kernel location, cross
compiler, etc.
5. Isolate the changes to a specific device. The important additions
(AndroidBoard.mk and kernel.mk) are generic (at least for ARM) and
could easily be copied to another device or moved into build/
Compromises:
1. In order to ensure correct kernel compilation, we have to always
call the kernel Makefile. So there will be extra output on the main
build window even if nothing needs to be done. Additionally, boot.img
is always regenerated. This compromise adds about 2 seconds to an
incremental no-change build on my machine.
Areas that need improvement:
1. Aligning BoardConfig.mk and device.mk changes with AOSP expectations.
2. No testing done for non-ARM architectures.
3. Kernel modules. Not recommended right now for more than
development/debugging. Kernel modules can be correctly installed to a
desired location (default system/lib/modules), but the Android build
system is not aware of them and so will not re-package system.img.
Additionally, it would be good to have the user / device config
specify exactly which kernel modules should get copied, and which
should be ignored. Right now all kernel modules are copied.
Instructions for getting the patch and using it.
----------------
cd $ANDROID_BUILD_TOP
cd device/ti/panda
git remote add gerrit-workaround git://github.com/finseteb/device_ti_panda.git
git fetch gerrit-workaround
git log gerrit-workaround/master..gerrit-workaround/master-kernelbuild
git cherry-pick a34aa876e94ffd63a4f4ec1d02dac69e765a021e
git cherry-pick c03fe14fd09e4e2e469d7a7a683e7ef6e21247e2
git reset HEAD~1
git diff
# Modify BoardConfig.mk to suite your environment
# Or put the values into buildspec.mk, env, or make cmdline.
cd -
source build/envsetup.sh
lunch full_panda-eng
# Do kernelclean first in case you had a local kernel build
m TARGET_BUILD_KERNEL=true -j8 kernelclean
m TARGET_BUILD_KERNEL=true -j8
-----------------
Finally, compiling the kernel on Mac OSX will work if you do the following
$ sudo sh -c 'curl http://www.swissdisk.com/~bcollins/macosx/elf.h >
/usr/include/elf.h'
Based on:
http://ben-collins.blogspot.com/2010/07/cross-compiling-linux-kernel-from-mac.html
-Eric
cd ~/android/system
git clone g...@github.com:jdkernel/lexikon_aosp_2.6.35.git
cd lexikon_aosp_2.6.35
make jdkernel_lexikon_stock_defconfig
export CCOMPILER=${HOME}/android/system/prebuilt/linux-x86/toolchain/
arm-eabi-4.4.0/bin/arm-eabi-
make ARCH=arm CROSS_COMPILE=$CCOMPILER -j8
cp ~/android/system/lexikon_aosp_2.6.35/arch/arm/boot/zImage ~/android/
system/device/htc/lexikon/prebuilt/zImage
cp ~/android/system/lexikon_aosp_2.6.35/drivers/net/wireless/bcm4329/
bcm4329.ko ~/android/system/device/htc/lexikon/prebuilt/bcm4329.ko
cd ~/android/system
. build/envsetup.sh
lunch full_lexikon-eng
make otapackage
> $ sudo sh -c 'curlhttp://www.swissdisk.com/~bcollins/macosx/elf.h>
> /usr/include/elf.h'
>
> Based on:http://ben-collins.blogspot.com/2010/07/cross-compiling-linux-kernel-...