[uClibc]Re: Strange busybox/uClibc problem

Paul Komarek komarek at andrew.cmu.edu
Tue Jun 25 18:26:35 UTC 2002


On Tue, 25 Jun 2002, Paul Komarek wrote:

>
> The message below was originally (and erroneously) posted by me to the
> busybox mailing list.  At the end of the problem report, I mention that
> things work fine when I replace uClibc with glib-2.1.3. Also, I'm now on
> the uClibc and busybox mailing lists, so there is no need to forward to
> me.
>
> On Sat, 22 Jun 2002, Paul Komarek wrote:
>
> >
> > I am not (yet) on this mailing list -- the CMU mail admins claim my inbox
> > is disturbing gravitational fields due to excessive mass.  Please cc me on
> > any responses.
> >
> > I have a problem when booting a Soekris net4501 (AMD Elan SC520) using
> > busybox (compiled against uClibc).  The problem occurs in init.c, but I
> > hesitate to claim the problem is in init.c.
> >
> > The problem is that init stops at strange places:
> >
> >   VFS: Mounted root (nfs filesystem).
> >   Freeing unused kernel memory: 220k freed
> >   serial console detected.  Disabling virtual terminals.
> >   init started:  BusyBox v0.60.3 (2002.06.22-05:44+0000) multi-call binary
> >
> > And that's it.  If I comment out init.c:311, then I get further (using
> > message( CONSOLE, "Hello, world\n") to track my progress.
> >
> > init_main() calls check_memory() calls check_free_memory():
> >
> > static int check_free_memory(void)
> > {
> >     ...
> >     u = info.mem_unit;
> >     if (u==0) u=1;                   <------- Line 311, remove
> >     ...
> > }
> >
> > If I also comment out init.c:851, I make further progress.
> >
> > init_main() calls parse_inittab() calls new_init_action():
> >
> > static void new_init_action(int action, char *command, char *cons)
> > {
> >     ....
> >     if (*cons == '\0')          <----------- Line 851, remove
> >         cons = console;
> >     ....
> > }
> >
> > When repeating these tests to write this email, I didn't fiddle further
> > with my inittab and such.  I did more tests earlier, but never got things
> > working right (never got getty to work right, using my own and sample
> > configs).
> >
> > I have this problem whether I do shared or static libs, and for kernels
> > 2.4.17, 2.4.19-pre10, and 2.4.19-pre10-ac2 (you can see the desperation
> > setting in... ;-).  The problem has occurred when netbooting or booting
> > from a CF card.  I'm watching the output from a serial console, but I
> > personally don't think that's part of the problem.  I have used a snapshot
> > of uClibc from about June 19th, and another from June 22nd.  As you might
> > guess, I haven't really taken the cross product of all these options.  If
> > you want to know exactly what I've done, I'll be happy to enumerate the
> > tests.  Of course, I'd be happy to provide most any information anyone
> > things will help (kernel config, etc).
> >
> > I've made other net4501 boards work with a modified Red Hat 7.2
> > distrobution, using a pared-down glibc and custom rh kernel 2.4.17-0.18,
> > without any real troubles.
> >
> > Please let me know if it would be appropriate to post or cross-post to the
> > uClibc list.
> >
> > -Paul Komarek
>
> I found a machine with gcc for i386 installed, and tested busybox with
> static linking (and tinylogin with static linking) against glibc-2.1.3.
> Everything works as expected (well, I haven't made getty work right for me
> yet, but that' probably a PEBKAC situation =-).  I'm going to repost my
> above message on the uClibc list now.
>
> -Paul Komarek

I was suggest by one person that I clarify the cpu architecture involved:

1) the Soekris net4501 uses an AMD Elan SC520.  The Elan target in kernel
the recent 2.4 kernels doesn't seem to work with it, and Configure.help
states that the Elan target is for the SC400/SC410.

2) I have successfully used i386 libs with this board (using glibc instead
of uClibc)

3) My uClibc toolchain-wrappers (the DEVEL directory) is name
i386-linux-uclibc, which I'd hoped indicated that I was targeting i386.
However, I didn't set CROSS to anything in Config, and my host machine
uses gcc-i686.

Since #3 looks like it could explain all my woes, I'm going to get the
necessary cross-compiler built, and retry uClibc with that.

-Paul Komarek





More information about the uClibc mailing list