Dear Glenn, please don't top-post / full-quote.
In message <[email protected]> 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: [email protected] "Security is mostly a superstition. It does not exist in nature... Life is either a daring adventure or nothing." - Helen Keller _______________________________________________ eldk mailing list [email protected] http://lists.denx.de/mailman/listinfo/eldk
