Re: [Ltib] Postmortem of bringing up Cirrus ARM on ltib and a couple of questions

[Stuart Hughes]

On Sun, 2008-08-17 at 22:45 -0700, Mr Junk wrote:
> Stuart, et al,
> 
> I hope my efforts provide some insight for others that may face  
> similar challenges.
> 
> While sorting most the the steps below (running ltib hundreds, maybe  
> thousands of times, tftping and nfsing, writing sd cards, etc) I had a  
> fever of 103.5 for almost 4 days and 102.3 for another 4.  Not the  
> best state to be in while attempting to bring up a new BSP on LTIB.   
> Alt least I had something to distract me from the immense pain that  
> went with the virus.

That sounds really bad.  Hope you're feeling better.

> 
> The entire first set of problems came from trying to use the cirrus  
> "4.1.1-920t" toolchain.  I really wanted to use that one.
> 
> Turns out the layout of that toolchain (although newer) would just not  
> work with ltib, no way.
> 
> I tried for days. but in the end had to give up and let that one go.
> 
> The symptom was a system where dynamically linked programs failed to  
> run.  Even rcS wouldn't run.
> 
> I keyed on to it when I statically linked all the packages and  
> suddenly things looked better.  I realized that none of the libs were  
> being copied over to my rootfs from the toolchain.
> 
> Then Stuart gave me an old base_libs.spec he had used with cirrus in  
> the past.  After trying that with the toolchain and having no success  
> I gave up and moved back to a 3.4.1 toolchain that I had found for the  
> ep9302.
> 
> I was getting closer.  I made a single change in Stuart's specfile to  
> extend a lib search one step deeper into the hierarchy, and viola,  
> suddenly the libs where now showing up in my rootfs.

Indeed.  The base_libs we put out works for many toolchains
(CodeSourcery, Freescale (which are cross-tool style). However if you
get a toolchain with some other layout, you'll need to write a variant
of base_libs.spec for that toolchain.  Better still if you can come up
with a superset of rules that covers the new toolchain in the common
base_libs.spec, that's ideal.  Over time we've added a lot into that
spec, originally it worked just with crosstool, now it'll work with
uClibc toolchains and even multi-libbed CS toolchains.  

NOTE: always check rootfs/lib for a reasonable set of shared libs.


> 
> Still no love on rcS executing, but the system would at lease come up  
> to the login.
> 
> I logged in and typed bash and lo behold things were suddenly working  
> better.  Now I could manually run rcS from the command line.
> 
> After lots of experimenting I found that sash had been enable in the  
> packages and it was pre-empting both ash and bash from being used to  
> start the system up.  It didn't seem to have the proper permissions to  
> run rcS and it's minions.
> 
> Turning off sash and linking sh to bash suddenly made the system work  
> properly.  As well, busybox's ash also worked properly.

sash is is only really useful for some MMUless boards and even then I
prefer msh from busybox which is functional with the exception of shell
functions (which ltib avoids in its startup script).


> 
> Now on to some packages.
> 
> Several key packages wouldn't compile and I found that fd.h from the  
> toolchain had a bug. . .I removed __user from the offending line and  
> all the packages wourld now compile, except a biggy.

Sometimes you'll need to do this with some toolchain/platform
combinations.

> 
> gdb compiles most of the way through and then just stops while trying  
> to generate some docs.
> 

Post some output of the failure, we may have a fix.

> When I figure that on out I will let you know.
> 
> Questions:
> 
> I have been looking for gcc as a package and can't seem to find it.  I  
> remember two years ago while working with the 8349 and ltib there was  
> a gcc package.
> 

On some BSPs we do allow gcc to be built.  However this is limited to
some platforms.  The reason is that we prefer to use pre-built libraries
from the cross toolchain on the target.  Also there are a lot of
constraints on versions of binutils/glibc etc when you do this, so we
only bother if the board might be one that wants to self-host gcc.  My
colleague who deals with the toolchain side if he's lurking on the list
might be able to give a more lucid explanation.

Bottom line: not all BSPs will let you build gcc (but you can add it).

> The reason I need it (unless someone enlightens me) is that I need to  
> build perl dbi for mysql.  First you run perl on the makefile and then  
> you need to compile with gcc.
> 
> I'm not sure there is a way to do that in a cross compile environment.
> 

I think you can cross compile.  I recall doing some other perl modules.

> If anyone has built DBD DBI for mysql and would put forth I would be  
> eternally grateful.
> 

I don't think I've done this particular module, but I will take a look
when I've got some free air and see if I can send an example.

> There is still a bit I need to learn an I'm hoping there are docs  
> somewhere that can help.
> 
> Stuart had mentioned how to add an alternate spec file for the  
> base_libs by messing with the pkg_map in the config/platform area for  
> the board, but it's now clear how to do that and how that is used to  
> make the change when you run ltib.
> 

Here's the content from the email I send earlier in case anyone missed
it.  If it's unclear what's going on or how to do this, please let me
know.

The pkg_map file doesn't affect the visible config system (mconf/lkc).
What it does is tie the logical package selection to the actual spec
file you want.

So, if you select "base libs", this turns on PKG_BASE_LIBS in the
output .config file.  LTIB then uses (by default)
config/userspace/pkg_map to look up which spec file to use for the given
package.  In this case you'll see:

PKG_BASE_LIBS                    = base_libs

If you want to override this, you can put a pkg_map file into
config/platform/target and set it to another value.  Take a look at some
of the other platforms to get an idea
(config/platform/mpc8548cds/pkg_map for example overrides the gdb
package).



> If anyone knows where the docs on doing that are located I would also  
> be very grateful.


The only stuff in really under the docs directory.  I don't have enough
time to put much into these.  I'm always happy to take contributions :-)

> 
> Now that I have things running well I'm quite afraid to make changes  
> that could bring it all down again.

Don't worry about that, just take a snapshot and make changes you need.
The main thing is as soon as you run into a block, send email to the
list with output, that's the quickest way for me to understand context.

Regards, Stuart