I'm writing up some notes on building Android from scratch and replacing the kernel in an Android build from one built locally, and I realized that's it a bit of a chore to extract the kernel config that got used. I thought, it may make sense to provide an way in android-build to control what gets used - which would make finding this information easier since if would one of the configs that gets passed to the build like TARGET_PRODUCT. Thoughts?
On Thu, 15 Sep 2011 15:08:26 -0500, Zach Pfeffer zach.pfeffer@linaro.org wrote:
I'm writing up some notes on building Android from scratch and replacing the kernel in an Android build from one built locally, and I realized that's it a bit of a chore to extract the kernel config that got used. I thought, it may make sense to provide an way in android-build to control what gets used - which would make finding this information easier since if would one of the configs that gets passed to the build like TARGET_PRODUCT. Thoughts?
Hi,
We could (fairly easily I imagine) make the actual config an artefact of the build. Then you could go to any build, grab the config, and so build the same thing locally.
Passing it in would be ok, but I'm not sure we would want to make every build have the config specified as well as everything else? The only way that it would be universal would be if you had to specify this on every config, which seems to duplicate information inside the tree.
Providing the config that was used as an artefact would be universal. I guess we even have a choice between providing the full .config, and just the name of the defconfig, if that's how the Android build system selects them.
Thanks,
James
On 15 September 2011 15:58, James Westby james.westby@linaro.org wrote:
On Thu, 15 Sep 2011 15:08:26 -0500, Zach Pfeffer zach.pfeffer@linaro.org wrote:
I'm writing up some notes on building Android from scratch and replacing the kernel in an Android build from one built locally, and I realized that's it a bit of a chore to extract the kernel config that got used. I thought, it may make sense to provide an way in android-build to control what gets used - which would make finding this information easier since if would one of the configs that gets passed to the build like TARGET_PRODUCT. Thoughts?
Hi,
We could (fairly easily I imagine) make the actual config an artefact of the build. Then you could go to any build, grab the config, and so build the same thing locally.
Passing it in would be ok, but I'm not sure we would want to make every build have the config specified as well as everything else? The only way that it would be universal would be if you had to specify this on every config, which seems to duplicate information inside the tree.
Providing the config that was used as an artefact would be universal. I guess we even have a choice between providing the full .config, and just the name of the defconfig, if that's how the Android build system selects them.
It just does it by name.
Thinking more about this.
Replacing a kernel is a pretty normal operation. I think if we just generated a script that had the relevant paths from the build and posted that on the build page then that would streamline this operation. Something like:
git clone git://git.linaro.org/people/jstultz/android.git cd android git checkout linaro-android-3.0
wget --no-check-certificate https://android-build.linaro.org/jenkins/job/linaro-android_toolchain-4.6-li...
tar -jxvf android-toolchain-eabi-linaro-4.6-2011.08-18-2011-09-12_08-38-17-linux-x86.tar.bz2
make ARCH=arm CROSS_COMPILE=$PWD/android-toolchain-eabi/bin/arm-eabi- defconfig android_omap4_defconfig && make ARCH=arm CROSS_COMPILE=$PWD/android-toolchain-eabi/bin/arm-eabi- uImage
Most of those values come out of the build system and you can find most of them, but have a script would be just one more way we're making it easier to work with these builds.
Thanks,
James
On Thu, 15 Sep 2011 16:13:32 -0500, Zach Pfeffer zach.pfeffer@linaro.org wrote:
It just does it by name.
Thinking more about this.
Replacing a kernel is a pretty normal operation. I think if we just generated a script that had the relevant paths from the build and posted that on the build page then that would streamline this operation. Something like:
Sorry, let me clarify something, this is with the intent of building an updated kernel to put back in the image, for the purpose of testing a new kernel without rebuilding the whole image?
git clone git://git.linaro.org/people/jstultz/android.git cd android git checkout linaro-android-3.0
wget --no-check-certificate https://android-build.linaro.org/jenkins/job/linaro-android_toolchain-4.6-li...
tar -jxvf android-toolchain-eabi-linaro-4.6-2011.08-18-2011-09-12_08-38-17-linux-x86.tar.bz2
make ARCH=arm CROSS_COMPILE=$PWD/android-toolchain-eabi/bin/arm-eabi- defconfig android_omap4_defconfig && make ARCH=arm CROSS_COMPILE=$PWD/android-toolchain-eabi/bin/arm-eabi- uImage
Most of those values come out of the build system and you can find most of them, but have a script would be just one more way we're making it easier to work with these builds.
That looks like something that would be fairly easy to generate.
I generally prefer producing data, and then have scripts to act on that data (e.g. in linaro-image-tools,) but this looks ok.
Would you want e.g. the kernel repo to be the one from the build, or to always be jstultz's?
If this is something you want you can spin up a blueprint for this work. Paul, would you be interested in completing this one?
Thanks,
James
On 16 September 2011 08:53, James Westby james.westby@linaro.org wrote:
On Thu, 15 Sep 2011 16:13:32 -0500, Zach Pfeffer zach.pfeffer@linaro.org wrote:
It just does it by name.
Thinking more about this.
Replacing a kernel is a pretty normal operation. I think if we just generated a script that had the relevant paths from the build and posted that on the build page then that would streamline this operation. Something like:
Sorry, let me clarify something, this is with the intent of building an updated kernel to put back in the image, for the purpose of testing a new kernel without rebuilding the whole image?
Yeah.
git clone git://git.linaro.org/people/jstultz/android.git cd android git checkout linaro-android-3.0
wget --no-check-certificate https://android-build.linaro.org/jenkins/job/linaro-android_toolchain-4.6-li...
tar -jxvf android-toolchain-eabi-linaro-4.6-2011.08-18-2011-09-12_08-38-17-linux-x86.tar.bz2
make ARCH=arm CROSS_COMPILE=$PWD/android-toolchain-eabi/bin/arm-eabi- defconfig android_omap4_defconfig && make ARCH=arm CROSS_COMPILE=$PWD/android-toolchain-eabi/bin/arm-eabi- uImage
Most of those values come out of the build system and you can find most of them, but have a script would be just one more way we're making it easier to work with these builds.
That looks like something that would be fairly easy to generate.
I generally prefer producing data, and then have scripts to act on that data (e.g. in linaro-image-tools,) but this looks ok.
Would you want e.g. the kernel repo to be the one from the build, or to always be jstultz's?
The one from the build.
If this is something you want you can spin up a blueprint for this work. Paul, would you be interested in completing this one?
Yup. Done: https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-gen-ker...
I also spun up:
https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-gen-scr...
For rebuilding the entire image and:
https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-gen-scr...
For making downloading a programming builds easy.
Thanks,
James
On Fri, 16 Sep 2011 10:19:49 -0500, Zach Pfeffer zach.pfeffer@linaro.org wrote:
https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-gen-scr...
For making downloading a programming builds easy.
That one should be done as an addition to the existing linaro-fetch-image tools in linaro-image-tools. That way there will be a one-stop-shop for fetching and programming linaro platform images, with GUI and command line interfaces.
Thanks,
James
On 16 September 2011 10:39, James Westby james.westby@linaro.org wrote:
On Fri, 16 Sep 2011 10:19:49 -0500, Zach Pfeffer zach.pfeffer@linaro.org wrote:
https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-gen-scr...
For making downloading a programming builds easy.
That one should be done as an addition to the existing linaro-fetch-image tools in linaro-image-tools. That way there will be a one-stop-shop for fetching and programming linaro platform images, with GUI and command line interfaces.
I'm not so sure. I'm just looking for a script that contains:
wget --no-check-certificate https://android-build.linaro.org/jenkins/job/linaro-android_panda-11.09-rele...
wget --no-check-certificate https://android-build.linaro.org/jenkins/job/linaro-android_panda-11.09-rele...
wget --no-check-certificate https://android-build.linaro.org/jenkins/job/linaro-android_panda-11.09-rele...
bzr branch lp:linaro-image-tools
./linaro-image-tools/linaro-android-media-create --mmc /dev/sdc --dev panda --system system.tar.bz2 --userdata userdata.tar.bz2 --boot boot.tar.bz2
...verbatim. Maybe with an argument for the SD card.
Thanks,
James
On Fri, 16 Sep 2011 11:02:34 -0500, Zach Pfeffer zach.pfeffer@linaro.org wrote:
On 16 September 2011 10:39, James Westby james.westby@linaro.org wrote:
On Fri, 16 Sep 2011 10:19:49 -0500, Zach Pfeffer zach.pfeffer@linaro.org wrote:
https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-gen-scr...
For making downloading a programming builds easy.
That one should be done as an addition to the existing linaro-fetch-image tools in linaro-image-tools. That way there will be a one-stop-shop for fetching and programming linaro platform images, with GUI and command line interfaces.
I'm not so sure. I'm just looking for a script that contains:
Ok, but Alexander is keen to see this integration with the linaro-fetch-image tools, and I think it would lead to an improved experience as well.
Thanks,
James
On 16 September 2011 11:17, James Westby james.westby@linaro.org wrote:
On Fri, 16 Sep 2011 11:02:34 -0500, Zach Pfeffer zach.pfeffer@linaro.org wrote:
On 16 September 2011 10:39, James Westby james.westby@linaro.org wrote:
On Fri, 16 Sep 2011 10:19:49 -0500, Zach Pfeffer zach.pfeffer@linaro.org wrote:
https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-gen-scr...
For making downloading a programming builds easy.
That one should be done as an addition to the existing linaro-fetch-image tools in linaro-image-tools. That way there will be a one-stop-shop for fetching and programming linaro platform images, with GUI and command line interfaces.
I'm not so sure. I'm just looking for a script that contains:
Ok, but Alexander is keen to see this integration with the linaro-fetch-image tools, and I think it would lead to an improved experience as well.
Sounds like we need to all have a chat. I don't think it has to be an either or thing.
Thanks,
James
Hello,
Just my 2 cents.
On Thu, 15 Sep 2011 16:13:32 -0500 Zach Pfeffer zach.pfeffer@linaro.org wrote:
On 15 September 2011 15:58, James Westby james.westby@linaro.org wrote:
On Thu, 15 Sep 2011 15:08:26 -0500, Zach Pfeffer zach.pfeffer@linaro.org wrote:
I'm writing up some notes on building Android from scratch and replacing the kernel in an Android build from one built locally, and I realized that's it a bit of a chore to extract the kernel config that got used.
How is it chore? You get uImage out of boot.tar.bz2 and run scripts/extract-ikconfig from kernel tree on it, voila.
As long as we have CONFIG_IKCONFIG_PROC in defconfig, we're ok, and every (open) kernel in the world has to have that option on. Btw, I was really astonished to find out that Ubuntu doesn't have that option set. Horror! My noname cheap tablet doesn't conceal its kernel config from me, and Ubuntu does.
I thought, it may make sense to provide an
way in android-build to control what gets used - which would make finding this information easier since if would one of the configs that gets passed to the build like TARGET_PRODUCT. Thoughts?
Hi,
We could (fairly easily I imagine) make the actual config an artefact of the build. Then you could go to any build, grab the config, and so build the same thing locally.
Passing it in would be ok, but I'm not sure we would want to make every build have the config specified as well as everything else? The only way that it would be universal would be if you had to specify this on every config, which seems to duplicate information inside the tree.
Providing the config that was used as an artefact would be universal. I guess we even have a choice between providing the full .config, and just the name of the defconfig, if that's how the Android build system selects them.
It just does it by name.
Thinking more about this.
Replacing a kernel is a pretty normal operation.
It's normal operation for those who know how to do that. And giving people who don't know a script doesn't help at all, because very next question will be "I get error running your script, wazzup?", next one will be "I made some random changes to defconfig and it no longer boots", etc, etc.
I think if we just generated a script that had the relevant paths from the build and posted that on the build page then that would streamline this operation. Something like:
git clone git://git.linaro.org/people/jstultz/android.git cd android git checkout linaro-android-3.0
wget --no-check-certificate https://android-build.linaro.org/jenkins/job/linaro-android_toolchain-4.6-li...
tar -jxvf android-toolchain-eabi-linaro-4.6-2011.08-18-2011-09-12_08-38-17-linux-x86.tar.bz2
make ARCH=arm CROSS_COMPILE=$PWD/android-toolchain-eabi/bin/arm-eabi- defconfig android_omap4_defconfig && make ARCH=arm CROSS_COMPILE=$PWD/android-toolchain-eabi/bin/arm-eabi- uImage
Most of those values come out of the build system and you can find most of them, but have a script would be just one more way we're making it easier to work with these builds.
I am usually proponent of providing more information about builds (and introspection into systems in general), but that seems a bit too much/misplaced to me. First of all, kernel is of course a bit special, but there're thousand other components in Android which might be good to replace, so what about providing 1K scripts to handle that? With that in mind, for me, threshold for how many such scripts to provide is at 0, not 1.
Secondly, kernel, while special, is still integral component of Android, so our job is to provide the best kernel and its config, and those who need to tweak/replace it, need to already know how to do that, or learn their way thru it. And that knowledge is not Android-specific, as argued above, and as argued above, providing "shortcuts" for that would be more of disservice. YMMV ;-)
Thanks,
James
On 16 September 2011 10:55, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
Hello,
Just my 2 cents.
On Thu, 15 Sep 2011 16:13:32 -0500 Zach Pfeffer zach.pfeffer@linaro.org wrote:
On 15 September 2011 15:58, James Westby james.westby@linaro.org wrote:
On Thu, 15 Sep 2011 15:08:26 -0500, Zach Pfeffer zach.pfeffer@linaro.org wrote:
I'm writing up some notes on building Android from scratch and replacing the kernel in an Android build from one built locally, and I realized that's it a bit of a chore to extract the kernel config that got used.
How is it chore? You get uImage out of boot.tar.bz2 and run scripts/extract-ikconfig from kernel tree on it, voila.
Sure, and that's a valid usecase, but I'm really just looking for a script that has all the links already in it that someone could run or run with minor modification.
As long as we have CONFIG_IKCONFIG_PROC in defconfig, we're ok, and every (open) kernel in the world has to have that option on. Btw, I was really astonished to find out that Ubuntu doesn't have that option set. Horror! My noname cheap tablet doesn't conceal its kernel config from me, and Ubuntu does.
John, Andy, Angus, Bernhard, Mathieu would you turn on CONFIG_IKCONFIG_PROC in your configs?
I thought, it may make sense to provide an
way in android-build to control what gets used - which would make finding this information easier since if would one of the configs that gets passed to the build like TARGET_PRODUCT. Thoughts?
Hi,
We could (fairly easily I imagine) make the actual config an artefact of the build. Then you could go to any build, grab the config, and so build the same thing locally.
Passing it in would be ok, but I'm not sure we would want to make every build have the config specified as well as everything else? The only way that it would be universal would be if you had to specify this on every config, which seems to duplicate information inside the tree.
Providing the config that was used as an artefact would be universal. I guess we even have a choice between providing the full .config, and just the name of the defconfig, if that's how the Android build system selects them.
It just does it by name.
Thinking more about this.
Replacing a kernel is a pretty normal operation.
It's normal operation for those who know how to do that. And giving people who don't know a script doesn't help at all, because very next question will be "I get error running your script, wazzup?", next one will be "I made some random changes to defconfig and it no longer boots", etc, etc.
Sure, that's actually okay. That would be a good email because people would be working with our stuff and we could help them out etc.
I think if we just generated a script that had the relevant paths from the build and posted that on the build page then that would streamline this operation. Something like:
git clone git://git.linaro.org/people/jstultz/android.git cd android git checkout linaro-android-3.0
wget --no-check-certificate https://android-build.linaro.org/jenkins/job/linaro-android_toolchain-4.6-li...
tar -jxvf android-toolchain-eabi-linaro-4.6-2011.08-18-2011-09-12_08-38-17-linux-x86.tar.bz2
make ARCH=arm CROSS_COMPILE=$PWD/android-toolchain-eabi/bin/arm-eabi- defconfig android_omap4_defconfig && make ARCH=arm CROSS_COMPILE=$PWD/android-toolchain-eabi/bin/arm-eabi- uImage
Most of those values come out of the build system and you can find most of them, but have a script would be just one more way we're making it easier to work with these builds.
I am usually proponent of providing more information about builds (and introspection into systems in general), but that seems a bit too much/misplaced to me. First of all, kernel is of course a bit special, but there're thousand other components in Android which might be good to replace, so what about providing 1K scripts to handle that? With that in mind, for me, threshold for how many such scripts to provide is at 0, not 1.
Sure, but we'd just do the kernel.
Secondly, kernel, while special, is still integral component of Android, so our job is to provide the best kernel and its config, and those who need to tweak/replace it, need to already know how to do that, or learn their way thru it. And that knowledge is not Android-specific, as argued above, and as argued above, providing "shortcuts" for that would be more of disservice. YMMV ;-)
I don't think so. The script would have all the commands in it so it would help people make this leap while lowering the burden on our team to answer each email with the steps that would be in the scripts.
Thanks,
James
-- Best Regards, Paul
Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
Hello Zach,
On Fri, 16 Sep 2011 11:08:48 -0500 Zach Pfeffer zach.pfeffer@linaro.org wrote:
[]
Sure, but we'd just do the kernel.
Secondly, kernel, while special, is still integral component of Android, so our job is to provide the best kernel and its config, and those who need to tweak/replace it, need to already know how to do that, or learn their way thru it. And that knowledge is not Android-specific, as argued above, and as argued above, providing "shortcuts" for that would be more of disservice. YMMV ;-)
I don't think so. The script would have all the commands in it so it would help people make this leap while lowering the burden on our team to answer each email with the steps that would be in the scripts.
Ok, if you think it's worth to develop and maintain support for such script, then sure, it can be done. But I agree with James that it would rather be blueprinted, so good attention can be paid to its implementation and testing.
On Thu, 2011-09-15 at 16:13 -0500, Zach Pfeffer wrote:
git clone git://git.linaro.org/people/jstultz/android.git cd android git checkout linaro-android-3.0
Minor nit here, going forward I think we want to point folks to the tree here: git://android.git.linaro.org/kernel/linaro-android.git
Since at some point I'm likely to move the linaro-android kernel away from my people repo.
thanks -john
On 16 September 2011 14:10, john stultz johnstul@us.ibm.com wrote:
On Thu, 2011-09-15 at 16:13 -0500, Zach Pfeffer wrote:
git clone git://git.linaro.org/people/jstultz/android.git cd android git checkout linaro-android-3.0
Minor nit here, going forward I think we want to point folks to the tree here: git://android.git.linaro.org/kernel/linaro-android.git
Since at some point I'm likely to move the linaro-android kernel away from my people repo.
Oh definitely. If you want to move it now I can update the manifest. Just send me the git and the branch.
thanks -john
On Fri, 2011-09-16 at 14:13 -0500, Zach Pfeffer wrote:
On 16 September 2011 14:10, john stultz johnstul@us.ibm.com wrote:
On Thu, 2011-09-15 at 16:13 -0500, Zach Pfeffer wrote:
git clone git://git.linaro.org/people/jstultz/android.git cd android git checkout linaro-android-3.0
Minor nit here, going forward I think we want to point folks to the tree here: git://android.git.linaro.org/kernel/linaro-android.git
Since at some point I'm likely to move the linaro-android kernel away from my people repo.
Oh definitely. If you want to move it now I can update the manifest. Just send me the git and the branch.
git://android.git.linaro.org/kernel/linaro-android.git linaro-android-3.0
thanks -john
On 16 September 2011 14:27, john stultz johnstul@us.ibm.com wrote:
On Fri, 2011-09-16 at 14:13 -0500, Zach Pfeffer wrote:
On 16 September 2011 14:10, john stultz johnstul@us.ibm.com wrote:
On Thu, 2011-09-15 at 16:13 -0500, Zach Pfeffer wrote:
git clone git://git.linaro.org/people/jstultz/android.git cd android git checkout linaro-android-3.0
Minor nit here, going forward I think we want to point folks to the tree here: git://android.git.linaro.org/kernel/linaro-android.git
Since at some point I'm likely to move the linaro-android kernel away from my people repo.
Oh definitely. If you want to move it now I can update the manifest. Just send me the git and the branch.
git://android.git.linaro.org/kernel/linaro-android.git linaro-android-3.0
http://review.android.git.linaro.org/#change,228,patchset=1
And thanks for being awesome!
thanks -john
-
James Westby -
john stultz -
Paul Sokolovsky -
Zach Pfeffer