Re: [Ltib] Questions regarding Usage Scenarios

[Stuart Hughes]

Hi Bob,

1-2/ Definitely use Savannah as your baseline.  Although at times this
lags in some respects, often the BSP ISO release images are older than
the Savannah CVS.  The real deciding factor though is that if you use
Savannah for a custom BSP you will be able to get some support.
Furthermore, if you have a local tree (as you mention in 2) you will
have a way of synchronising when there are updates at Savannah (whether
CVS or later git).  If you use an ISO snapshot, there's no way to know
if/when this might be updated.

3/ An ISO image generated from LTIB contains all the source/patches
referenced in the default configuration.  Optionally, there's a
"--fullbsp" flag that can be given that will pull in all the sources for
all the packages (this is of course has a much larger footprint).

Fundamentally to have your "own BSP" in LTIB means having/maintaining:

a) A toolchain.  Often there is already one available that you can use.

b) A Linux kernel source tree and config file (maybe just some patches
against a standard kernel.org, or even just a vanilla kernel)

c) Maintaining a directory e.g.: config/platform/mcf5329micro/
This may contain as few files as:
   * defconfig          : the default LTIB configuration
   * main.lkc           : your config settings to select the kernel
   * kernel-xxx.spec.in : listing the source+patches for the kernel
   * linux-xxx.config   : your kernel config (not always needed)


My advice would be that if it's at all possible to have your platform
represented in Savannah CVS with the kernel source/patches uploaded to
the GPP.  This would mean the burden of support/releases would be much
less for you.  Some other users have already submitted their own BSP
abstractions and have them in Savannah (cobra5475, mpc82xx, phy3250).

WARNING: for MMUless platforms only a sub-set of packages are available.
This is because there is no 'fork' in MMUless (there is vfork) and so
packages need adaptation or may fundamentally not be easy to port to a
MMUless environment.  Therefore if something is in LTIB and not uClinux,
this may well be because this works only for platforms with MMU (there's
guards in the package selection see "depends CAP_HAS_MMU" in
config/userspace/packages.lkc).  So for MMU-full platforms, LTIB would
probably be the best choice, but for MMUless platforms uClinux-dist may
be a better choice.  The deciding factor would be if you want to use
LTIB because of it's structure (rpm packages, release ISOs etc) rather
than the package content.

Regards, Stuart


On Tue, 2009-02-10 at 21:20 -0500, Robert S. Grimes wrote:
> Hi,
> 
> We have designed a board for a Freescale Coldfire MCF5329 micro, and the
> hardware design was based on the Freescale/LogicPD evaluation board; the
> goal was to minimize changes necessary to run uClinux from the patches
> provided in an AppNote.  This effort started in January 2007, before I
> had heard of LTIB.
> 
> Now we want to update the kernel (from the 1/31/2007 uClinux) and use
> more packages (specifically, Nano-X/Microwindows), so it seems a good
> time to consider LTIB.  The goal is to create an ISO image of the new
> BSP for the client's board (which, by the way, is embedded in their
> instrument product line, and not sold separately - hence, the BSP is for
> their internal use).
> 
> All that being said, I'm not sure if I fully understand how to do this,
> but let me ask the questions I have, and see where the answers may
> lead...
> 
> 1. I got an ISO image from Freescale for their eval board, and it
> largely works (as expected).  Should I start from that, or should I work
> from Savannah CVS?  Pros and cons?
> 
> 2. The ultimate goal is to a stable BSP, with occasional updates due to
> new custom features, updated external packages, new kernels, etc.  We
> would want to manage our customizations using our Subversion repository,
> and occasionally make ISO images for archival purpose (e.g. formal
> releases).  Is this a good approach (i.e. revision control of only
> changes (patches), along with some identification of package versions,
> etc.)?
> 
> 3. Also with respect to the last scenario, does/can an ISO image include
> all source packages (i.e. tarballs) for all packages included in a
> build?
> 
> >From what I've read in the FAQ list and from my experiments, it seems my
> proposed approach is feasible, but I'm not convinced I fully understand
> the terminology, nor the inner workings, such that I lack the confidence
> to commit down this path without some guidance or reassurance...
> 
> Thanks!
> -Bob