[Clfs-support] Cannot login on serial port (embedded ARM, busybox)

Sun Oct 16 14:00:25 PDT 2011

On Sat, Oct 15, 2011 at 9:05 PM, Lance Jump <lancej29 at gmail.com> wrote:

>
>
> On Sat, Oct 15, 2011 at 10:53 AM, Lance Jump <lancej29 at gmail.com> wrote:
>
>>
>>
>> On Sat, Oct 15, 2011 at 9:21 AM, Andrew Bradford <bradfa at gmail.com>wrote:
>>
>>> On Fri, Oct 14, 2011 at 6:40 PM, Lance Jump <lancej29 at gmail.com> wrote:
>>> > The board I have is the OpenRD client. It is based on the Marvell
>>> Kirkwood,
>>> > which is the same processor used in the PlugComputer.  I have a config
>>> file
>>> > for an older kernel (2.6.18).
>>>
>>> Can you try a CLFS build using 2.6.18 kernel source?  The procedure
>>> should be the same, just you'll end up with different headers and an
>>> older kernel than what the book says.
>>>
>>
>> That is a test can try. But some of my later experiments (after my email
>> yesterday) are leading e to believe that the problem is not actually in the
>> kernel (more on that later).
>>
>>>
>>> > The reason I wanted a working config from the CLFS build is so that I
>>> can
>>> > check non-hardware related things like devpts and tmpfs settings.  I
>>> > compared the one you sent to mine and found numerous non-hardware
>>> related
>>> > differences.
>>>
>>> My kernel config is not at all optimized to have "the right stuff" in
>>> it.  It's just the first config I had that worked well enough to boot.
>>>  I wouldn't consider it to be a great example, but it is a working
>>> example.
>>>
>>> > I think since the ${CLFS}-final has already been created at that point
>>> and
>>> > there are other things being fixed up for it, that doing it in -final
>>> makes
>>> > the most sense.
>>> >
>>> > I will try to get either the trac ticket or patch this weekend.  Does
>>> the
>>> > protocol require a trac ticket against which to submit the patch?
>>>
>>> If you just send a small-ish patch to -dev list, there's no need to
>>> open a trac ticket.  My stance (not necessarily anyone else's) is to
>>> open tickets when the change will take a long time, involve more than
>>> just me, or if I don't have the urge to fix it right now.  If you're
>>> fixing something you just found and it's small, just send a patch.
>>>
>>
>> After some of my experiments last night, I'm not sure of the right way to
>> fix this.  I am thinking that it might be just to remove the lines entirely.
>>
>>
>>>
>>> > I have done some more experimenting and found some interesting things.
>>> > First, with only console and null in /dev I get repeated "Can't open
>>> > /dev/tty1: No such file or directory" (tty1..6) messages.  When I
>>> create
>>> > these nodes, the messages go away.
>>>
>>> You shouldn't need to create these nodes.  mdev should be doing that
>>> for you.  Of course, mdev doesn't run till after mounting everything
>>> in the startup script, so we're back to one of your original problems
>>> :)
>>>
>>
>> Well, this is part of the experimental results.  Since every sysinit line
>> in inittab will be executed in sequence, I was able to do much of the
>> initialization that would normally be done by the startup script.  Here are
>> the lines:
>>
>> ::sysinit:/bin/rm -rf /dev
>> ::sysinit:/bin/mkdir /dev
>> ::sysinit:/bin/mount -t tmpfs -o mode=0755 none /dev
>> ::sysinit:/bin/mkdir /dev/pts
>> ::sysinit:/bin/mkdir /dev/shm
>> ::sysinit:/bin/mount -a
>> ::sysinit:/bin/echo "/sbin/mdev" > /proc/sys/kernel/hotplug
>> ::sysinit:/sbin/mdev -s
>>
>> This all appears to work since I can then see dozens (hundreds?) of
>> devices in /dev.  But scripts still don't run and the login behaves exactly
>> as before.  Note that the first I thing I do is to delete and create /dev so
>> it doesn't matter whether null or console were there -- they get created.
>> (This is why I am leaning towards removing their creation from the book.)
>>
>>
>>>
>>> > I can replace the sysinit line in inittab with just about anything else
>>> (for
>>> > example "mount -a" or "/bin/busybox --help" and it appears to do
>>> exactly
>>> > what is expected. In fact, I used the "mount -a" to locate missing
>>> mount
>>> > points in /dev (/dev/pts and /dev/shm).
>>> >
>>> > I can also use various commands other than getty for the other lines in
>>> > inittab and they do as expected. For example if I used "touch
>>> /tmp/test" it
>>> > creates or updates the file /tmp/test. I seem to be able to do most
>>> things,
>>> > but I just can seem to execute a script no matter how simple.  For
>>> example,
>>> > if I put the touch command in a script file and try to execute it, it
>>> does
>>> > nothing.
>>>
>>> I think your ash might not be built right if you can't run scripts.
>>> That's odd, especially if things like touch or mount work.  Are you
>>> changing the BusyBox config at all?
>>>
>>
>> I didn't make any changes to the busybox configuration -- I built it
>> exactly as in the book. However, I am starting to think that the problem is
>> in busybox (rather its configuration or related files) rather than the
>> kernel.  My previous experiments essentially show that the kernel works fine
>> and seems to do whatever is asked of it.  Since I didn't change busybox, it
>> may be related to the environment files such as in /etc or /root. For
>> example, Mike's earlier suggestion of securetty (which I tried without
>> success, but I mean something like it).
>>
>>>
>>> > Another interesting things is that device detection for things like USB
>>> mice
>>> > and thumb drives and SD cards all appears to work except that none of
>>> it is
>>> > ever mounted.  The drives are identified from driver messages as sda,
>>> sda1,
>>> > sdb... but nothing ever appears in the /dev directory.  By the way,
>>> this is
>>> > also an indication that the kernel believes the serial port to be the
>>> > console.
>>>
>>> mdev should be taking this info from the kernel and populating /dev for
>>> you.
>>>
>>
>> Yes, with the inittab "script" this appears to be the case.
>>
>> I started looking into the busybox source to see I can tell what is
>> happening.  I don't believe the issue is in busybox per se, but I am
>> thinking debug messages can help me find out where it going and where it is
>> going astray.  This is somewhat difficult without significant concentrated
>> time and a debugger, but I am running out of other promising things to try.
>> I'm sure the problem will turn out to be a typo on my part or something --
>> it's always a simple solution.
>>
>> I may have found something.  I put debug printf calls in the ash.c source
> to see if it was getting that far and what was happening if it did. It does
> get to ash and it appears to crash after the first call call to setjmp.  I
> removed that call and it got far enough to give me the "~ #" prompt.  But as
> soon as I entered a command, it went back to the "Please press Enter ..."
> message.  I followed it a bit further and found that it was crashing at
> another setjmp.  So, I searched for "Busybox setjmp" and found lots of
> references to setjmp being broken in ARM uClib.  Most were older, but few
> were more recent. A few made references to floating point configuration.
> Here are a couple:
>
>
> http://www.bettina-attack.de/jonny/view.php/projects/actiontec_dpcm_stuff/toolchain/
> http://lists.busybox.net/pipermail/uclibc/2002-February/023533.html
>
> I recall setting up for software floating point in the environment
> variables. I will go back and look at the uClib and kernel settings when I
> get a chance.  This looks promising...
>

Okay, that was it. I found that UCLIBC_HAS_FP was set in the config file of
uClibc. I set the CLFS_FLOAT to "soft" and CLFS_FPU to empty, but these did
not appear to get used. The uClibc configuration comes from the copy of
clfs/config.arm.little, which has UCLIBC_HAS_FPU=y set. I didn't see
anything in book about needing to change that.

Anyway, I changed it in the uClibc build process with a conditional sed:

if [ "${CLFS_FLOAT}" == "soft" ]; then
   sed -i s/"UCLIBC_HAS_FPU=y"/"# UCLIBC_HAS_FPU is not set"/g .config
fi

I rebuilt everything and found that the startup script now runs. I have some
DHCP startup problems, but that is completely unrelated.  Anyway, I can now
log in.

How do you want to handle this issue?  Is it a failure on my part to
properly read the directions or should there have been a note about making
menuconfig in uClibc? Some other alternatives include having additional
template config files (w/o FPU), incorporating something like my sed lines
(above) or maybe having the default config.arm.little have FPU turned off.
This latter approach should at least build working systems whether or not
the CPU has floating point.

>
>>
>>> -Andrew
>>> _______________________________________________
>>> Clfs-support mailing list
>>> Clfs-support at lists.cross-lfs.org
>>> http://lists.cross-lfs.org/listinfo.cgi/clfs-support-cross-lfs.org
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.clfs.org/pipermail/clfs-support-clfs.org/attachments/20111016/925aae7c/attachment-0001.htm>