[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <y2zd66caabb1004281614qe5af7fa7i6d9d5ac957ea6520@mail.gmail.com>
Date: Thu, 29 Apr 2010 09:14:26 +1000
From: Graeme Russ <graeme.russ@...il.com>
To: Alexander Clouter <alex@...riz.org.uk>
Cc: linux-kernel@...r.kernel.org
Subject: Re: Request For Help - Embedded x86, Kernel 2.6.33 boots, Mounts
JFFS2 rootfs, Stops at init
On Thu, Apr 29, 2010 at 1:37 AM, Alexander Clouter <alex@...riz.org.uk> wrote:
> Graeme Russ <graeme.russ@...il.com> wrote:
>>
>> I've been working for a while now getting the x86 U-Boot port up to speed
>> to boot a linux kernel
>>
> ...ewww x86.
Yeah, nothing like a challange ;)
>
>> [snipped]
>>
>> [ 1.911896] Write protecting the kernel read-only data: 596k
>> [ 1.915842] kernel_execve(/sbin/init)
>>
>> (I've added a printk in kernel_execve() which gives me the last line)
>>
>> I initially had hot-plug support compiled into the kernel and was getting
>> a lot of kernel_execve(/sbin/hotplug) messages as well (plus a udev:
>> starting version 151 message which appear 100+ seconds and the above
>> messages), but I have since removed that and used mknod to create
>> /dev/ttyS0 directly
>>
>> I have also tried the following test script:
>>
>> #!/bin/bash
>> stty -F /dev/ttyS0 115200
>> cat hello > /dev/ttyS0
>>
>> but still no luck
>>
>> Does anyone have any advise on how I can debug this problem?
>>
> What does you /dev directory look like? You need to have at least the
> following:
> ----
> mknod console c 5 1
> mknod null c 1 3
> mknod ttyS0 c 4 64
> ----
>
tick, tick, tick
A little further background (should have included this last night but it
was late and I thought the problem must be trivial)...
I had originally mounted this root fs using NFS with (very) limited
success. After mounting and performing a few NFS requests (observed using
wireshark) the NFS activity would simply stop with 'server not responding'
messages. I turned on debugging in the 8139too and NFS drivers. With
debugging output enabled I was still getting 'server not responding'
messages, but (eventually) the boot sequence would continue. This even
resulted in logs in /var/log of the NFS share for the device (filled with
raw network packet data).
But no console...
What if I init with the following:
#!/bin/bash
echo hello > /hello.txt
and then rebooted and checked the root fs in U-Boot? How long will it
take for hello.txt to be flushed? Can I force the flush?
Regards,
Graeme
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists