Issues with ASRock E350M1

[Marshall Buschman]

Hello:

I was instructed to send mail to you by Carebear from #coreboot.
I have some issues to report based on the "Golden Image" I received from 
him, which was created for the ASRock E350M1.

The first is with hard drive detection - there is a reliability problem 
here - only once out of every 5 to 12 times the machine posts will it 
detect the hard drive successfully.
The hard drive is a Corsair F120 SSD. I do have another, smaller 16GB 
Kingston SSD I can test with.

The second problem is that on booting, GRUB (I do not have the version 
on hand -- whatever gentoo is shipping as stable at this point) behaves 
very, very strangely with my USB keyboard.
I should point out that it does not work 100% correctly on another 
machine under Fedora's grub, so this may bear further testing with 
another keyboard.

The following video demonstrates the issue - this is very reproduceable 
(I gave exactly this input on the keyboard: "<down>, e, hello there, 
test, one, two, three", and only once. You can hear the clicking of my 
keyboard.)
http://www.lucidmachines.com/coreboot/weird-usb-in-grub.avi

I will be traveling until May 31st, and so unable to reply to mail until 
then, but I do look forward to working with you all on this.

Thank you!
-Marshall Buschman

[Scott Duplichan]

Marshall Buschman wrote:

]Hello:
]
]I was instructed to send mail to you by Carebear from #coreboot.
]I have some issues to report based on the "Golden Image" I received from 
]him, which was created for the ASRock E350M1.
]
]The first is with hard drive detection - there is a reliability problem 
]here - only once out of every 5 to 12 times the machine posts will it 
]detect the hard drive successfully.
]The hard drive is a Corsair F120 SSD. I do have another, smaller 16GB 
]Kingston SSD I can test with.

I am not sure if your image is using the AHCI interface or IDE
interface. It really doesn't matter, there is a problem to debug either
way. You need to find someone to debug using the Corsair F120 SSD, or
debug it yourself. Is the problem for powerup only or both powerup
and cold reset button?

]The second problem is that on booting, GRUB (I do not have the version 
]on hand -- whatever gentoo is shipping as stable at this point) behaves 
]very, very strangely with my USB keyboard.
]I should point out that it does not work 100% correctly on another 
]machine under Fedora's grub, so this may bear further testing with 
]another keyboard.

I also have USB keyboard problems, but my problem is different. For
each key I press, it repeats a couple dozen times. I solve the problem
by adding a 'break' to usb-hid.c:

for (;;) {
        struct keyevent data;
        int ret = usb_poll_intr(pipe, &data);
        if (ret)
            break;
        handle_key(&data);
        break; <==================

With this change, I am able to type well enough to get windbg started,
which is all I needed at the time. But typing is very sluggish. I
believe the sluggishness is due to use of 8254 periodic interrupt
polling to service the keyboard.

Thanks,
Scott

[Kevin O'Connor]

On Fri, May 27, 2011 at 02:11:14AM -0500, Scott Duplichan wrote:
> I also have USB keyboard problems, but my problem is different. For
> each key I press, it repeats a couple dozen times. I solve the problem
> by adding a 'break' to usb-hid.c:
> for (;;) {
>     struct keyevent data;
>     int ret = usb_poll_intr(pipe, &data);
>     if (ret)
>         break;
>     handle_key(&data);
>     break; <==================

Can you generate and send a log with debug level set to 8 and the
dprintf in usb-hid.c:handle_key() changed to 8?  Getting timestamps on
the log (as with tools/readserial.py) would also help.
> With this change, I am able to type well enough to get windbg started,
> which is all I needed at the time. But typing is very sluggish. I
> believe the sluggishness is due to use of 8254 periodic interrupt
> polling to service the keyboard.

Yeah - since the loop was disabled there's no longer a queue on USB
key events.  This means any keys pressed faster than 55ms are dropped.

-Kevin

[Scott Duplichan]

Kevin O'Connor wrote:

]> I also have USB keyboard problems, but my problem is different. For
]> each key I press, it repeats a couple dozen times. I solve the problem
]> by adding a 'break' to usb-hid.c:
]> 
]>     for (;;) {
]>         struct keyevent data;
]>         int ret = usb_poll_intr(pipe, &data);
]>         if (ret)
]>             break;
]>         handle_key(&data);
]>         break; <==================
]
]Can you generate and send a log with debug level set to 8 and the
]dprintf in usb-hid.c:handle_key() changed to 8?  Getting timestamps on
]the log (as with tools/readserial.py) would also help.
]
]> With this change, I am able to type well enough to get windbg started,
]> which is all I needed at the time. But typing is very sluggish. I
]> believe the sluggishness is due to use of 8254 periodic interrupt
]> polling to service the keyboard.
]
]Yeah - since the loop was disabled there's no longer a queue on USB
]key events.  This means any keys pressed faster than 55ms are dropped.

Hello Kevin,

I decided to try and debug this myself. The attached patch is what I
came up with. Within the limitations of typing abilities, it is now
perfect. No sluggishness and no dropped keys. The head == next check
was failing when it should have passed. The reason is that the
toggleCarry bit is often set in endpoint descriptor dword #2, at least
on AMD hardware. Hopefully this change is compatible with qemu, Intel,
and other OHCI controllers.

Thanks,
Scott

Mask toggleCarry and Halted flags in endpoint descriptor dword #2 so that
the remaining head pointer field is valid for comparing with the next
pointer.

Signed-off-by: Scott Duplichan

--- seabios-0.6.2-original\src\usb-ohci.c	Mon Feb 28 21:10:57 2011
+++ seabios-0.6.2\src\usb-ohci.c	Sun May 29 02:47:30 2011
@@ -501,7 +501,7 @@

struct ohci_pipe *pipe = container_of(p, struct ohci_pipe, pipe);
     struct ohci_td *tds = GET_FLATPTR(pipe->tds);
-    struct ohci_td *head = (void*)GET_FLATPTR(pipe->ed.hwHeadP);
+    struct ohci_td *head = (void*)(GET_FLATPTR(pipe->ed.hwHeadP) &
0xffffffff0);
     struct ohci_td *tail = (void*)GET_FLATPTR(pipe->ed.hwTailP);
     int count = GET_FLATPTR(pipe->count);
     int pos = (tail - tds + 1) % count;

[Kevin O'Connor]

On Sun, May 29, 2011 at 03:17:40AM -0500, Scott Duplichan wrote:
> I decided to try and debug this myself. The attached patch is what I
> came up with. Within the limitations of typing abilities, it is now
> perfect. No sluggishness and no dropped keys. The head == next check
> was failing when it should have passed. The reason is that the
> toggleCarry bit is often set in endpoint descriptor dword #2, at least
> on AMD hardware.

Thanks.  I slightly modified the patch and committed it.
> Hopefully this change is compatible with qemu, Intel,
> and other OHCI controllers.

I don't think there are any Intel OHCI controllers.  I tested it on
qemu and it looks fine.  If you're curious, testing on qemu looks
like:

qemu -L biosdir -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios -fda odin1440.img -device pci-ohci -device usb-kbd

-Kevin

Hello!

I can confirm that this is working properly now!

I would also like to say that my USB keyboard performs significantly  
better now in GRUB under SeaBIOS on my ASRock E350M1 than it does with  
the stock Intel BIOS on my main workstation (Core 2 Quad, Intel board)

Very impressive - Thanks!
-Marshall Buschman

Quoting Kevin O'Connor :
> On Sun, May 29, 2011 at 03:17:40AM -0500, Scott Duplichan wrote:
> > I decided to try and debug this myself. The attached patch is what I
> > came up with. Within the limitations of typing abilities, it is now
> > perfect. No sluggishness and no dropped keys. The head == next check
> > was failing when it should have passed. The reason is that the
> > toggleCarry bit is often set in endpoint descriptor dword #2, at least
> > on AMD hardware.
>
> Thanks.  I slightly modified the patch and committed it.
> > Hopefully this change is compatible with qemu, Intel,
> > and other OHCI controllers.
>
> I don't think there are any Intel OHCI controllers.  I tested it on
> qemu and it looks fine.  If you're curious, testing on qemu looks
> like:
>
> qemu -L biosdir -chardev stdio,id=seabios -device  
> isa-debugcon,iobase=0x402,chardev=seabios -fda odin1440.img -device  
> pci-ohci -device usb-kbd
>
> -Kevin
>
> SeaBIOS mailing list
> [e-mail]
> http://www.seabios.org/mailman/listinfo/seabios

Hello:

Thanks for the reply. I've spent the last week getting Coreboot under  
my control with help from CareBear.
I'm running a patched Coreboot (latest, as of 6/3/11), and SeaBIOS  
master (as of 6/3/11).

Coreboot is presenting the drives as IDE.

I've attached the logs of a successful and an unsuccessful boot, as  
well as my SeaBIOS configuration - the debug level has been set to 8  
-- debug output from Coreboot has been disabled, as this increases the  
overall boot time substantially.

Thank you!
-Marshall Buschman

Quoting Scott Duplichan :
> Marshall Buschman wrote:
>
> ]Hello:
> ]
> ]I was instructed to send mail to you by Carebear from #coreboot.
> ]I have some issues to report based on the "Golden Image" I received from
> ]him, which was created for the ASRock E350M1.
> ]
> ]The first is with hard drive detection - there is a reliability problem
> ]here - only once out of every 5 to 12 times the machine posts will it
> ]detect the hard drive successfully.
> ]The hard drive is a Corsair F120 SSD. I do have another, smaller 16GB
> ]Kingston SSD I can test with.
>
> I am not sure if your image is using the AHCI interface or IDE
> interface. It really doesn't matter, there is a problem to debug either
> way. You need to find someone to debug using the Corsair F120 SSD, or
> debug it yourself. Is the problem for powerup only or both powerup
> and cold reset button?
>
> ]The second problem is that on booting, GRUB (I do not have the version
> ]on hand -- whatever gentoo is shipping as stable at this point) behaves
> ]very, very strangely with my USB keyboard.
> ]I should point out that it does not work 100% correctly on another
> ]machine under Fedora's grub, so this may bear further testing with
> ]another keyboard.
>
> I also have USB keyboard problems, but my problem is different. For
> each key I press, it repeats a couple dozen times. I solve the problem
> by adding a 'break' to usb-hid.c:
> for (;;) {
>     struct keyevent data;
>     int ret = usb_poll_intr(pipe, &data);
>     if (ret)
>         break;
>     handle_key(&data);
>     break; <==================
>
> With this change, I am able to type well enough to get windbg started,
> which is all I needed at the time. But typing is very sluggish. I
> believe the sluggishness is due to use of 8254 periodic interrupt
> polling to service the keyboard.
>
> Thanks,
> Scott

[Kevin O'Connor]

On Thu, May 26, 2011 at 11:39:51PM -0500, Marshall Buschman wrote:
> Hello:
>
> I was instructed to send mail to you by Carebear from #coreboot.
> I have some issues to report based on the "Golden Image" I received
> from him, which was created for the ASRock E350M1.
>
> The first is with hard drive detection - there is a reliability
> problem here - only once out of every 5 to 12 times the machine
> posts will it detect the hard drive successfully.
> The hard drive is a Corsair F120 SSD. I do have another, smaller
> 16GB Kingston SSD I can test with.

Thanks for the report.  Can you send the seabios log - see the
directions at:

http://www.coreboot.org/SeaBIOS#Trouble_reporting

A log of a successful case and a failure case would be helpful.
> The second problem is that on booting, GRUB (I do not have the
> version on hand -- whatever gentoo is shipping as stable at this
> point) behaves very, very strangely with my USB keyboard.
> I should point out that it does not work 100% correctly on another
> machine under Fedora's grub, so this may bear further testing with
> another keyboard.
>
> The following video demonstrates the issue - this is very
> reproduceable (I gave exactly this input on the keyboard: "<down>,
> e, hello there, test, one, two, three", and only once. You can hear
> the clicking of my keyboard.)
> http://www.lucidmachines.com/coreboot/weird-usb-in-grub.avi

Okay - that's really odd.  Can you change the dprintf in
usb-hid.c:handle_key() to use a value of 8 instead of 9 and send the
log as above?  (If you need help with building SeaBIOS, let me know.)

Also, if you can use tools/readserial.py to capture the log (so that
we can see the relative timestamps), that would also help.

-Kevin