[ELDK] Kernel Panic on init

[Wolfgang Denk]

Dear Glenn,

please don't top-post / full-quote.

In message <A2307CF1934C804DAD90E71B11FF6DF211E2F4B131 at SWEC9981.w-intra.net> you wrote:
> 
> I am using ELDK 4.1 because it came with the coLinux distribution

But that's _old_.

> from DENX. Since it compiled the kernel, I figured it would not be a
> problem. Since I am also not going to be doing anything which
> requires the latest and greatest I figured it was OK.

As long as you just use it to compile the kernel you might even
succeed.  But then you need a root file system, and here you will most
likely into problems.

> Looking back I did miss the first line of the log: Using Xilinx
> Virtex440 machine description, but that is it.

Indeed - my faulet.  I missed the kernel command line entry (probably
because it was so unexpectedly short).

> My initramfs comes from a directory. I have the kernel
> configuration pointing to this place. I believe this is working since
> if I delete the /dev/console file I get the "Warning: unable to open
> an initial console." message. I have other files in the initramfs,
> but if I am understanding Linux booting correctly, the hello_world.c
> as the init program should only need itself and the console device. I
> did try the ELDK ramdisk_image as the root file system (initrd) and
> it behaved the same way.

I don't think this is a good way to bring up Linux.  You should always
start with a known to be working root file system image.  One of the
easiest ways is to use a root file system mounted over NFS - this may
look complicated at first, but then you can for example simply use
wireshark on the network and track each and every file access into the
root file system, which is a great help if the system hangs early.

In your case, using a "hello world" type program may be fatal.  If it
is the "classical" implementation it expects to have standard file
descriptors (stdin, stdout, stderr) pre-opened by some runtime
environment, which simply does not exist for the init process.  So
unless you explicitly open /dev/console in your program and direct
output to that device this cannot work.

> If you believe my next best step is to upgrade to ELDK V5.2.1, I
> will give that a try. That is what I am looking for, the next best
> logical step.

In situations like this I always try to set up a system with as few
as possible unknown components in it.  Use a known to be working (with
your kernel version) tool chain (i. e. a more recent one), and use a
known to be working root file system.  Then use a configuration that
provides as much information as possible - like by mounting over NFS
where you can trace the boot process.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Security is mostly a superstition. It does not  exist  in  nature...
Life is either a daring adventure or nothing."         - Helen Keller