Prev: [RFC PATCH 2/4] Mobile security processor driver
Next: [RFC PATCH 0/4] Mobile security processor driver
From: Graeme Russ on 28 Apr 2010 19:20
On Thu, Apr 29, 2010 at 1:37 AM, Alexander Clouter <alex(a)digriz.org.uk> wrote:
> Graeme Russ <graeme.russ(a)gmail.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(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Graeme Russ on 30 Apr 2010 13:00
Graeme Russ wrote:
> On Thu, Apr 29, 2010 at 1:37 AM, Alexander Clouter <alex(a)digriz.org.uk> wrote:
>> Graeme Russ <graeme.russ(a)gmail.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.
>
>>>
>> 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
>

Success!!!

I feel _really_ stupid about the cause of the problem.... I hadn't set up
the interrupt mapping of the serial ports in my board initialisation
routines in U-Boot. Once I mapped IRQ4 to UART0 it all sprang to life ;)

Big thanks to everyone for helping and a big thanks to all the linux and
GNU developers for creating such a wonderful 'toy' ;)

Graeme
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: [RFC PATCH 2/4] Mobile security processor driver
Next: [RFC PATCH 0/4] Mobile security processor driver