So, I kept instrumenting init/main.c (rev 14xx) and have discovered that the kernel_execve in run_init_process is simply not doing the right thing in exec'ing the new program, regardless of whether it's /sbin/init (busybox), /bin/sh (busybox), or /bin/mysh (my simple program that just loops and outputs a message periodically).  The sys_open of /dev/console in init_post does work properly, as I verified the ability to write to fd=0 and fd=1 (after sys_dup) with simple messages.  I put in the same instrumentation in init/main.c in rev 1161 and the new program is exec'ed as expected.  I even verified that the argv and envp are the same:

static void run_init_process(char *init_filename)
{
char **pp;
        argv_init[0] = init_filename;
printk(KERN_INFO "run_init_process kernel_execve entered init_filename=%s\n", i\
nit_filename);
for (pp = argv_init; *pp; pp++) printk(KERN_INFO "argv=%s\n", *pp);
for (pp = envp_init; *pp; pp++) printk(KERN_INFO "envp=%s\n", *pp);
        kernel_execve(init_filename, argv_init, envp_init);
printk(KERN_INFO "run_init_process kernel_execve returns in error\n");
}

The result in both situations is:

argv=/sbin/init                                                                
argv=3                                                                         
envp=HOME=/                                                                    
envp=TERM=linux            

I don't know how to verify whether the shared libraries are working properly, but visual inspection indicates that things are right (in the staged root).  So, I'm lost as to why the exec fails to transfer execution to the new program.

Perhaps someone with a running system can suggest to me where I can put some more printk's to figure out why things don't work.  Without a working system, I'm in the catch-22 situation of not being able to tell (easily) how the code should flow to debug it.





On 8/1/07, Peter Lu <plu777@gmail.com> wrote:
Hi,

I have

bootargs=console=ttyS0,115200n8 root=1f01 rootfstype=jffs2 ro 3

Good to hear that your system runs without any LCD despite one being configured.  So you're likely right about my unfounded hypothesis.




On 8/1/07, Brad House < brad@mainstreetsoftworks.com > wrote:
> Thanks for the explanation.  I'm not sure how to double-check the
> directory tree contents in the rootfs.arm_nofpu.jffs2 without being in
> the running Linux itself (u-boot has "ls" but not "ls -l" while
> jffs2dump displays inodes), but I'll assume the device_table.txt
> translates to the correct nodes in /dev.  It makes sense that nodes are
> pre-created to eliminate unnecessary flash writes on (every) boot-up.
>
> So, the question remains as to why /dev/console doesn't open correctly.
> I still suspect the LCD configuration stuff re-arranges console
> initialization, since this build option (done outside of the normal
> .config) did not exist in rev 1161.  I wish there were a "no LCD"
> option, to reflect my hardware set-up.

What bootargs are you using?
I assume you have at least "console=ttyS0,115200n8" in there, right?

I really think you're barking up the wrong tree with the LCD theory.
I have the samsung (#3) selected in my kernel, but no LCD display
at all, no issues booting that kernel (granted, I boot only via
an external CF card, don't use jffs2, but I think your failure
is occurring before that is relevant anyhow).

-Brad

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
gumstix-users mailing list
gumstix-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gumstix-users