Re: [Ltib] Upgrading Linux Kernel on EP885 Board

[Stuart Hughes]

Hi Sagar,

There is no EP885 platform in the public LTIB release, if you want an 
upgrade you'd be best to go back to the vendor who supplied this.

To answer your questions:

1/ the board level dependencies are whether or not that platform is 
actively supported in the mainline kernel.  Your best bet to find out is 
to ask your vendor.  The other thing to bear in mind is your bootloader. 
  After 2.6.16 PowerPC changed to using flat device trees and so the 
boot semantics are different (as on the kernel/u-boot list for more 
information).

2/ I don't know if you had any "special patches" for your 2.4 kernel, 
but I suspect all the features in 2.4 and more are in the later 2.6 kernels.

3/ So far as documentation goes, there's information on the mechanics of 
adding a new kernel in the attached doc (this is also in the 
distribution under the doc directory in plain text).

The closest platform in public CVS is qs875s (875 adder board), this has 
a 2.6.16 kernel.

Regards, Stuart

sagar kadam wrote:
> Hi Stuart,
>
>     I have been using EP885 Board (Embedded Planet)with Linux 
> version2.4.22 which came along with the BSP for that board.Now I am 
> thinking to upgrade the kernel to 2.6 i.e. the latest one or a bit of 
> lower one but with 2.6.xx series.I googled a lot, also on the ltib 
> related sites but didn't get something relevant to this board with the 
> required kernel.
>      Can you help me out in this with some solutions to my following 
> questions.
> 1> What are the board level dependencies in the kernel which I will 
> require to take care.
> 2> Will these dependencies directly port from 2.4.xx to 2.6.xx . If yes 
> how and  if no why ?
> 3> Is there any documentation available, related to this kind of 
> scenario? If yes where?
>      I will be grateful to you, if you wil provide me some clue with 
> this, and also I will let you know if I succeed in this by the mean time.
>       Thanking you in anticipation
>
>    
>      
>
>
>
>
> --
> BR,
> Sagar Kadam
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> LTIB home page: http://bitshrine.org
>
> Ltib mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/ltib

---

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

Table of Contents

• Introduction
• How to upgrade a BSP (i.e. not-maintenance).
  • Scenario
  • Which CVS should I use
  • Principles
  • What should I do to add a new toolchain and kernel?
    • General principles
    • Example: adding a new toolchain
    • Example: adding a new kernel
  • Remember to upload the content to the GPP or send a patch
  • Pre-selecting the new stuff
  • Why is this important
  • Conclusion
    • Dos
    • Donts
    • Exceptions

Introduction

Here is a quick note on various techniques and best practices for maintaining
LTIB BSP.

How to upgrade a BSP (i.e. not-maintenance).

Scenario

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?

Which CVS should I use

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

Principles

1. If we've released something before the selections of kernel/bootloader/toolchain should still be available to users
2. Don't knowingly break older stuff.
3. Newer is not always better (to everyone). Some people really need to have the old stuff available to them (even if it's not the default).

What should I do to add a new toolchain and kernel?

General principles

Lets say you have new toolchain and a new kernel that you want to
upgrade people to.  Here's what to do:

• ADD the new toolchain as the next one in the selection list.
• LEAVE the old toolchain tokens in place

Example: adding a new toolchain

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

Example: adding a new kernel

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:

• Hunk '@@ -121,6 +121,8 @@' shows the new menu prompt under the kernel choice list selection "kernel-8xx"

• Hunk '@@ -135,6 +137,7 @@' Shows that the new kernel (#4) will select the spec file who's base name is "kernel-8xx" as the rpm spec file that will be used in order to build the kernel. It is this spec file that references the source tarball and patches that belong to this kernel

• Hunk '@@ -153,6 +156,7 @@' Shows that the new kernel (#4) will select the new linux .config file "linux-8xx-am_adder_87x.config"

In addition to changing this main.lkc for this example I needed do the
following:

• Create (maybe based on a copy) the file: config/platform/qs875s/linux-8xx-am_adder_87x.config

• Create (maybe based on a copy) the file: dist/lfs-5.1/kernel/kernel-8xx.spec.in

Remember to upload the content to the GPP or send a patch

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

Pre-selecting the new stuff

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:

• config/platform/<target>/defconfig.dev
• config/platform/<target>/<linux_config_name>.dev

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.

Why is this important

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.

Conclusion

Dos

• Add new stuff
• Update the defconfig

Donts

• Remove old stuff

Exceptions

There are always exceptions, but please discuss first on the LTIB list
if you are thinking that your case is an exception.

---

Converted on Mon Jun 1 08:01:30 2009 UTC