Re: [SeaBIOS] Issues with ASRock E350M1
I should mention that a 16gb Kingston SSD I have works just fine, as well as a 500gb traditional hard disk. Looks like this might be a problem with the disk itself. I know the Sandforce controllers do all kinds of smart things like compressing data to achieve greater throughput. I'll investigate and see what I can find. Quoting Kevin O'Connor ke...@koconnor.net: On Fri, Jun 03, 2011 at 11:55:47PM -0500, mbusch...@lucidmachines.com wrote: 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 The key part of the log is: bad: |1efd| powerup iobase=1420 st=7f |1efd| powerup iobase=1420 st=7f |1efd| ata_detect ata0-0: sc=ff sn=ff dh=ff good: |1efd| powerup iobase=1420 st=50 |1efd| powerup iobase=1420 st=50 |1efd| ata_detect ata0-0: sc=55 sn=aa dh=a0 The drive/controller is stating that the drive is not busy, but then the drive does not respond to register reads/writes. Thus SeaBIOS concludes that there is no drive present. Under normal circumstances, the drive will report busy until it is ready to respond to register accesses. -- debug output from Coreboot has been disabled, as this increases the overall boot time substantially. Can the failures be correlated to boot time? For example, if you enable/disable debugging in coreboot+seabios, can you get it to reliably fail or succeed? Also, what time of controller chip is this on? Another test - if you boot from another medium, does Linux detect your drive even when SeaBIOS doesn't? I'm not sure what can be done to handle a drive/controller that states it is ready but is not. I don't know how to distinguish that from a drive that isn't present. -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Issues with ASRock E350M1
Mystery solved - the drive's shipping firmware was causing this behavior - an upgrade to the latest firmware (2.0) resolves this. Thanks! -Marshall Buschman Quoting mbusch...@lucidmachines.com: I should mention that a 16gb Kingston SSD I have works just fine, as well as a 500gb traditional hard disk. Looks like this might be a problem with the disk itself. I know the Sandforce controllers do all kinds of smart things like compressing data to achieve greater throughput. I'll investigate and see what I can find. Quoting Kevin O'Connor ke...@koconnor.net: On Fri, Jun 03, 2011 at 11:55:47PM -0500, mbusch...@lucidmachines.com wrote: 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 The key part of the log is: bad: |1efd| powerup iobase=1420 st=7f |1efd| powerup iobase=1420 st=7f |1efd| ata_detect ata0-0: sc=ff sn=ff dh=ff good: |1efd| powerup iobase=1420 st=50 |1efd| powerup iobase=1420 st=50 |1efd| ata_detect ata0-0: sc=55 sn=aa dh=a0 The drive/controller is stating that the drive is not busy, but then the drive does not respond to register reads/writes. Thus SeaBIOS concludes that there is no drive present. Under normal circumstances, the drive will report busy until it is ready to respond to register accesses. -- debug output from Coreboot has been disabled, as this increases the overall boot time substantially. Can the failures be correlated to boot time? For example, if you enable/disable debugging in coreboot+seabios, can you get it to reliably fail or succeed? Also, what time of controller chip is this on? Another test - if you boot from another medium, does Linux detect your drive even when SeaBIOS doesn't? I'm not sure what can be done to handle a drive/controller that states it is ready but is not. I don't know how to distinguish that from a drive that isn't present. -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Issues with ASRock E350M1
Or not! It's back. Same issue as before. Quoting mbusch...@lucidmachines.com: Mystery solved - the drive's shipping firmware was causing this behavior - an upgrade to the latest firmware (2.0) resolves this. Thanks! -Marshall Buschman Quoting mbusch...@lucidmachines.com: I should mention that a 16gb Kingston SSD I have works just fine, as well as a 500gb traditional hard disk. Looks like this might be a problem with the disk itself. I know the Sandforce controllers do all kinds of smart things like compressing data to achieve greater throughput. I'll investigate and see what I can find. Quoting Kevin O'Connor ke...@koconnor.net: On Fri, Jun 03, 2011 at 11:55:47PM -0500, mbusch...@lucidmachines.com wrote: 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 The key part of the log is: bad: |1efd| powerup iobase=1420 st=7f |1efd| powerup iobase=1420 st=7f |1efd| ata_detect ata0-0: sc=ff sn=ff dh=ff good: |1efd| powerup iobase=1420 st=50 |1efd| powerup iobase=1420 st=50 |1efd| ata_detect ata0-0: sc=55 sn=aa dh=a0 The drive/controller is stating that the drive is not busy, but then the drive does not respond to register reads/writes. Thus SeaBIOS concludes that there is no drive present. Under normal circumstances, the drive will report busy until it is ready to respond to register accesses. -- debug output from Coreboot has been disabled, as this increases the overall boot time substantially. Can the failures be correlated to boot time? For example, if you enable/disable debugging in coreboot+seabios, can you get it to reliably fail or succeed? Also, what time of controller chip is this on? Another test - if you boot from another medium, does Linux detect your drive even when SeaBIOS doesn't? I'm not sure what can be done to handle a drive/controller that states it is ready but is not. I don't know how to distinguish that from a drive that isn't present. -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Issues with ASRock E350M1
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 ke...@koconnor.net: 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 SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Issues with ASRock E350M1
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 sc...@notabs.org:
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
seabios-config
Description: Binary data
seabios-good.gz
Description: GNU Zip compressed data
seabios-bad.gz
Description: GNU Zip compressed data
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Issues with ASRock E350M1
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 sc...@notabs.org
--- seabios-0.6.2-original\src\usb-ohci.c Mon Feb 28 21:10:57 2011
+++ seabios-0.6.2\src\usb-ohci.cSun 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)
0x0);
struct ohci_td *tail = (void*)GET_FLATPTR(pipe-ed.hwTailP);
int count = GET_FLATPTR(pipe-count);
int pos = (tail - tds + 1) % count;
usb-kb.patch
Description: Binary data
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Issues with ASRock E350M1
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 SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Issues with ASRock E350M1
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 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Issues with ASRock E350M1
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
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
