Graeme Russ <[email protected]> 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.
> [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
----
Cheers
--
Alexander Clouter
.sigmonster says: Your love life will be... interesting.
On Thu, Apr 29, 2010 at 1:37 AM, Alexander Clouter <[email protected]> wrote:
> Graeme Russ <[email protected]> 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
Graeme Russ wrote:
> On Thu, Apr 29, 2010 at 1:37 AM, Alexander Clouter <[email protected]> wrote:
>> Graeme Russ <[email protected]> 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