BusyBox, uClibc and M68KNOMMU (uclinux) debugging...

[Sachin Naik]

Hello,

I have 2.4.x version of uClinux kernel on a M68K-NOMMU
type of board. The processor is close to the standard
CPU32 type but has subtle differences. 

BusyBox and uClibc have been successfully built for
this board. I have created a Binary Flat Mode
(busybox) using the elf2flt option. I checked the
relocation entries for data/code. They all look good.

Now I run into problems when the first syscall
ioctl()made from uClibc_main -> uClibc_init ->
_stdio_init -> ioctl(). 

The kernel call returns and then I get some kind of
either corruption or signals that is preventing from
continuing with the further execution of user mode
code. It is hard to pin-point the corruption and can
vary depending upon the system timer, debug console
activity etc.

The problem shows in different formats such as signals
or some looping and also depends upon where
breakpoints are inserted in the user code prior to
entering the kernel.

My suspicion is that either I am missing some patch in
the kernel or uClibc for system call that is causing
this problem.

Manual debugging in the flat mode executable without
symbols and altered function/data addresses is a bit
tough. I have been doing that for the past 2/3 days
and not making progress.

My options to load and debug BusyBox (/sbin/init) as
an ELF executable will make debugging lot easier.

What are my options to load BusyBox just ONCE and run
it from the elfloader on a Non-MMU board ?  

Essentially I am having problems bootstrapping BusyBox
with init.

Anyone has had similar problems before ? I have
limited options in load programs etc.

- I bind my BusyBox in a CRAMFS image. Burn all this
as a single kernel image to flash and then debug it.
Got JTAG debug support.

--SNick


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com