|
| From: | Stuart Hughes |
| Subject: | Re: [Ltib] Getting started with LTIB |
| Date: | Tue, 24 Nov 2009 17:34:10 +0000 |
| User-agent: | Thunderbird 2.0.0.16 (X11/20080707) |
Hi Naveen, The attached documentation is somewhat out of date and not all sections are applicable here, in particular the toolchain selection in not normally handled in this way, but that should be clear from the example template you copy from. Further it assumes that you have CVS write permissions in some sections, which you do not. However, if you "read between the lines" the attached documents should help you. These documents are also available in plain text format in the doc directory (LtibReleaseProcess,LtibBestPractices) of the LTIB sources. Hope this helps. Regards, Stuart Naveen Krishna Ch wrote:
Hi All,I have just started with LTIB and want to buid images for a custom board.Its a ARM based processor board.Do i need to add a platform if so, How can i proceed.I m not clear with the documentation on the web. Can any one help me with soem pointers or Docs that i can use directly. Thanks in advance -- Shine bright, (: Naveen Krishna Ch :)
Copyright © Freescale Semiconductor, Inc. 2004-2005. All rights reserved. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the file doc/COPYING
Here is a quick note on various techniques and best practices for maintaining LTIB BSP.
A BSP exists for a target and some time has gone by. Now you want to re-release that BSP, possibly adding new kernels, toolchains bootloaders etc. What should you do?
After the last release of this BSP, the release team should have merged back from their branch into the trunk of CVS. If this has not happened, you must do this first.
Now that some time has gone by and you are adding something new not so much fixing a bug (even though that may be an indirect consequence) you should be working to start with on the HEAD of the trunk of CVS.
Once you have added the new stuff and have it basically working, you should re-branch and follow the release process documented in LtibReleaseProcess
Lets say you have new toolchain and a new kernel that you want to upgrade people to. Here's what to do:
In the patch below, here's an example showing how I added a new toolchain to the tqm823l platform:
$ cvs diff -r 1.31 -r 1.32 config/platform/tqm823l/main.lkc
Index: config/platform/tqm823l/main.lkc
===================================================================
RCS file: /cm/vault/ltib/ltib/config/platform/tqm823l/main.lkc,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- config/platform/tqm823l/main.lkc 24 May 2006 15:41:29 -0000 1.31
+++ config/platform/tqm823l/main.lkc 27 Jul 2006 12:47:30 -0000 1.32
@@ -54,6 +54,8 @@
bool "ppc-823 gcc-3.3.2/glibc-2.3.2 soft-float" if GLIBC || LIBC_NONE
config TOOLCHAIN2
bool "gcc-3.3.5/uclibc-0.9.2" if UCLIBC || LIBC_NONE
+ config TOOLCHAIN3
+ bool "gcc-4.0.2/glibc-2.3.6 soft float" if GLIBC || LIBC_NONE
config TOOLCHAIN_CUSTOM
bool "custom"
endchoice
@@ -62,11 +64,13 @@
string
default mtwk-lnx-powerpc-823-gcc-3.3.2-glibc-2.3.2-0.28-7.i686.rpm if TOOLCHAIN1
default ppc-uclibc-tc-20050308-2.i686.rpm if TOOLCHAIN2
+ default tc-fsl-x86lnx-823-4.0.2-2.i386.rpm if TOOLCHAIN3
config TOOLCHAIN_PATH
string
default "/opt/mtwk/usr/local/powerpc-823-linux/gcc-3.3.2-glibc-2.3.2" if TOOLCHAIN1
default "/opt/mtwk/usr/local/uclibc/ppc_nofpu" if TOOLCHAIN2
+ default "/opt/freescale/usr/local/gcc-4.0.2-glibc-2.3.6-2/powerpc-823-linux" if TOOLCHAIN3
string "Supply your toolchain path" if TOOLCHAIN_CUSTOM
config CUSTOM_TOOLCHAIN_PREFIX
@@ -77,7 +81,7 @@
config TOOLCHAIN_PREFIX
string
- default "powerpc-823-linux-" if TOOLCHAIN1
+ default "powerpc-823-linux-" if TOOLCHAIN1 || TOOLCHAIN3
default "powerpc-linux-uclibc-" if TOOLCHAIN2
default CUSTOM_TOOLCHAIN_PREFIX if TOOLCHAIN_CUSTOM
Here is an example that shows the addition of a new kernel to a target.
First, here's the patch of the main.lkc file. I've snipped it back to remove the hunks we're not interested in:
$ cvs diff -r 1.2 -r1.3 config/platform/qs875s/main.lkc
Index: config/platform/qs875s/main.lkc
===================================================================
RCS file: /sources/ltib/ltib/config/platform/qs875s/main.lkc,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- config/platform/qs875s/main.lkc 27 Feb 2007 14:43:16 -0000 1.2
+++ config/platform/qs875s/main.lkc 6 Mar 2007 17:20:39 -0000 1.3
@@ -121,6 +121,8 @@
bool "2.4.27 (Analogue Micro Ltd)"
config KERNEL3
bool "2.6.16 (Analogue Micro Ltd)"
+ config KERNEL4
+ bool "kernel-8xx"
config KERNEL_DIR_BUILD
bool "Local Linux directory build"
help
@@ -135,6 +137,7 @@
string
default "kernel-2.4.27-875" if KERNEL1
default "kernel-2.6.16-875" if KERNEL3
+ default "kernel-8xx" if KERNEL4
default "kernel26-dir-build" if KERNEL_DIR_BUILD
source ../../userspace/kernel_dir_build.lkc
@@ -153,6 +156,7 @@
string "kernel config"
default "linux-2.4.x-am_adder_87x.config" if KERNEL1
default "linux-2.6.16-am_adder_87x.config" if KERNEL3 || KERNEL_DIR_BUILD
+ default "linux-8xx-am_adder_87x.config" if KERNEL4
config PKG_KERNEL_WANT_CF
depends ! KERNEL_NONE
Here's an explanation:
In addition to changing this main.lkc for this example I needed do the following:
Before you check-in changes to LTIB CVS that reference new content (e.g. toolchains, source tarballs and patches), you must uploaded the to the GPP using this link: http://www.bitshrine.org/cgi-bin/gpp_upload.cgi
In order to use this link you must be a trusted developer with a password. Until that has been arranged, please send patches to the LTIB public mailing list
Having added your changes to main.lkc (leaving the old stuff in place), and added any new config files, run:
./ltib --configure
Make the changes you need to your overall configuration so that the BSP works with your updates as you require. Your configuration points will now have been captured in:
If you want to make your new overall configuraton the new default, move the config/platform/<target>/defconfig.dev to config/platform/<target>/defconfig and check-in the update.
If you have updated your new Linux configuration file, you should move this from the '.dev' name to a version without the '.dev'. Normally this will be a new file, so you need to 'cvs add' it before checking it in to cvs.
Imagine you're a poor user using CVS. Your config is setup and you're working on (and happy with) a certain toolchain and kernel. If someone changes the meaning of TOOLCHAIN1 or KERNEL1, when you do a cvs update, you'll be subjected to a situation whereby your current configuration is invalid. Worse still the old selections you WANTED have disappeared. How rude....
This situation would likely lead to frustration by users and lots of extra support traffic.
There are always exceptions, but please discuss first on the LTIB list if you are thinking that your case is an exception.
Converted on Tue Nov 24 17:23:19 2009 UTC
Copyright © Freescale Semiconductor, Inc. 2004-2005. All rights reserved. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the file doc/COPYING
This page gives a brief overview of how to make an LTIB binary BSP release. The specific example shown (for clarity) is for the mpc7448taiga, you should make substitutions for your own new platform as appropriate.
If instead you just want to mark a release in CVS, but not make an iso image, you should skip the sections:
Instead, the following actions should be taken:
If this is a release that will be sent to external parties, CVS should have already been branched as described below
Imagine you have made your iso release and people have found bugs and you want to fix them and possibly issue a new "maintenance release iso". Here's what you should do:
These don't have to be followed, but I think are helpful and good practice.
$ cvs add config/platform/mpc7448taiga $ cvs add config/platform/mpc7448taiga/* $ cvs add dist/lfs-5.1/u-boot/u-boot-fsl-mpc7448.spec $ cvs add dist/lfs-5.1/kernel/kernel-2.6.11-mpc7448.spec $ cvs commit
#MakingBranch
Once you have your BSP basically working and you want to be protected from new development updates on the CVS trunk you should make a branch in CVS. All further minor releases should be made on this branch. The branch name should be the same as the release tag name with 'rel' replaced with 'branch', the 'rc1' should also be dropped. Here is an example:
#### make sure you are up to date and commit all your work so far $ cvs up -dP $ cvs commit #### tag the trunk in cvs $ cvs rtag mpc7448taiga-5-3-1-bp ltib #### make the branch using your tag as the point to branch $ cvs rtag -b -r mpc7448taiga-5-3-1-bp branch-mpc7448taiga-5-3-1 ltib
This say make a branch rooted at the tag 'mpc7448taiga-5-3-1-bp', the name of the branch is 'branch-mpc7448taiga-5-3-1'.
If want to work further on maintenance updates to this release, you need to use this branch. To do this, updated your working copy to use the head of this branch:
cvs up -r branch-mpc7448taiga-5-3-1
./ltib -m config
./ltib -f
Before you even contemplate making a BSP as a release, you should be boot the image on board and run without any problems. Ideally do some more thorough testing.
You need to save any updated or new configuration files so that they will get captured in CVS. Here is an example:
$ cp config/platform/mpc7448taiga/.config config/platform/mpc7448taiga/defconfig $ cp config/platform/mpc7448taiga/linux_2.6.11_mpc7448_taiga_def.config.dev config/platform/mpc7448taiga/linux_2.6.11_mpc7448_taiga_def.config
You now need to upload your sources/patches to the GPP. To do this point your browser at: http://www.bitshrine.org/cgi-bin/gpp_upload.cgi
And upload each file not already in the GPP.
$ cvs commit
LTIB supports making a binary iso release. The default action of running this is:
Here is an example:
./ltib -m release Please enter the cvs tag name for this release, or if you just type enter, the timestamp rel-mpc7448taiga-1122556078 will be used rel-mpc7448taiga-5-3-1-rc1
The above command created the iso image "ltib-mpc7448taiga-20050728.iso"
You should copy your iso image to another machine and mount it and test it:
mount ltib-mpc7448taiga-20050728.iso /mnt/cdrom -o loop
/mnt/cdrom/install
By default, LTIB will get install in the dirctory 'ltib' in the current working directory.
cd ltib ./ltib
Once you have been through -rc1, -rc2, -rcn and have a good release that you want to publish more widely.
Converted on Tue Nov 24 17:21:29 2009 UTC
| [Prev in Thread] | Current Thread | [Next in Thread] |