Got it:
This line in usb-uhci.c (reset_uhci()) broke it:
pci_config_writew(bdf, USBLEGSUP, USBLEGSUP_RWC);
According to the US15W datasheet, there is no register at this offset,
there does seem to be something there because it reads 0x0400 after that
write, but I don't think it's what SeaBIOS is thinking it is...
USB Keyboard is working. Woohoo!
On Mon, Aug 6, 2012 at 4:08 PM, Matthew Millman <inaxeon(a)gmail.com> wrote:
> Thanks for the response Kevin
>
> I've spent another day trying to get to the bottom of this one, still no
> luck.
>
> Attempt to 16 byte align: No difference.
>
> Errata: One point mentioned with regards to UHCI but its affect would be a
> complete disabling of the controller, not this _sort of_ working issue I
> see, and, coreboot already has code which applies the workaround.
>
> Registers: Nothing much interesting here either
>
> Before:
> Regs: USBCMD: c1 USBSTS: 0 USBINTR: 0 USBFRNUM: 2ab USBSOF: 40
> USBFLBASEAD: eaac USBPORTSC1: 1a7 USBPORTSC2: 80
>
> After:
> Regs: USBCMD: c1 USBSTS: 0 USBINTR: 0 USBFRNUM: 4b3 USBSOF: 40
> USBFLBASEAD: e2cc USBPORTSC1: 1a7 USBPORTSC2: 80
>
> The more I look the more I find out _OK_ everything is. I did try another
> experiment which had even more interesting results, I tacked some more data
> onto the end of the setup packet (a5 a5 a5 a5 33 33 33 33 66 66 66 66) -
> what did it do? It made an exact copy of it immediately after the first
> one, it always does this regardless of how much data is being sent, and
> always writes a 'mystery' 12 bytes after that.
>
> before:
>
> 1fbc44b0: 00 05 01 00 00 00 00 00 a5 a5 a5 a5 33 33 33 33
> 1fbc44c0: 66 66 66 66 ff ff ff ff ff ff ff ff ff ff ff ff
> 1fbc44d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 1fbc44e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>
> after:
>
> 1fbc44b0: 00 05 01 00 00 00 00 00 a5 a5 a5 a5 33 33 33 33
> 1fbc44c0: 66 66 66 66 00 05 01 00 00 00 00 00 a5 a5 a5 a5
> 1fbc44d0: 33 33 33 33 66 66 66 66 fd 03 00 00 00 00 00 00
> 1fbc44e0: 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff
>
> I think the setting of the ActLen to 7ff is just its way of zeroing the
> count when the transaction begins, perhaps it never gets incremented
> because the process which is meant to fetch the memory is broken.
>
> Current theory: Something is broken in the DMA process. I can't really see
> how a UHCI controller could ever do something this crazy.
>
> Next step, assuming no one has any ideas, start examining why Linux works
> OK, I had a quick look for quirks but couldn't spot anything, but
> realistically, that is going to be a significant effort to see through.
>
> Cheers
> Matt
>
> On Sun, Aug 5, 2012 at 4:44 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote:
>
>> On Sun, Aug 05, 2012 at 12:21:13PM +0100, Matthew Millman wrote:
>> > Hi
>> >
>> > I'm seeing a rather interesting problem with UHCI on Intel US15W and
>> > wondered if anyone else had seen anything like this before. I noticed it
>> > when I plugged in a USB keyboard, which caused a crash due to something
>> > corrupting the stack? it turns out that the stack has been trashed by
>> the
>> > UHCI controller via DMA?!
>> >
>> > When trying to transmit the 8 byte address setup packet, the hardware
>> > doesn't quite seem to be doing as it's told. SeaBIOS sets up the UHCI
>> TDs
>> > exactly as per the spec - no problems there,
>> >
>> > Once the QH element is set, instead of transmitting the 8 bytes as
>> > described in the TD, it transmits a full 1023 bytes? (according to the
>> > returned TD) UHCI then goes ahead and overwrites another 35 bytes beyond
>> > the end of the buffer pointed to by the TD.
>> >
>> > Here's the 8 bytes of the setup packet (I've set everything after it to
>> > 0xFF):
>> >
>> > 1fbc1f95: 00 05 01 00 00 00 00 00 ff ff ff
>> > 1fbc1fa0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> > 1fbc1fb0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> > 1fbc1fc0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> > 1fbc1fd0: ff ff ff ff ff
>> >
>> > Here it is after the UHCI controller has been at it. The only code to
>> > execute between these two dumps is this:
>> >
>> > pipe->qh.element = (u32)&tds[0]; (in uhci_control())
>> >
>> > 1fbc1f95: 00 05 01 00 00 00 00 00 ff ff ff
>> > 1fbc1fa0: bf 00 05 01 00 00 00 00 00 ff ff ff fd 03 00 00
>> > 1fbc1fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> > 1fbc1fc0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> > 1fbc1fd0: ff ff ff ff ff
>> >
>> > TD Chain before:
>> > 1fbc4870: 84 48 bc 1f 00 00 80 1c 2d 00 e0 00 95 1f bc 1f
>> > 1fbc4880: 01 00 00 00 00 00 80 04 69 00 e8 ff 00 00 00 00
>> >
>> > TD Chain after:
>> > 1fbc4870: 84 48 bc 1f ff 07 80 1c 2d 00 e0 00 95 1f bc 1f
>> > 1fbc4880: 01 00 00 00 00 00 80 04 69 00 e8 ff 00 00 00 00
>>
>> My read of the spec says an actlen=0x07ff means a null transfer (not
>> 1023 bytes). However, given that the status is still active I don't
>> think it really matters what's in the td.
>>
>> > I'm wondering if I'm not the first person to have seen this. The problem
>> > (without detailed debugging) manifests its self exactly as described in
>> > this message:
>>
>> I haven't seen this type of report before. A couple of things you
>> could try: dump the USB controller registers as well (the controller
>> may have shutdown for a different reason), check to see if any other
>> transfer attempted to use 0x1fbc1fa0 in the past (perhaps the
>> controller has something stale cached), look for an errata for the
>> chipset, look through the linux code for the chipset to see if it is
>> working about something, try aligning the setup packet buffer to 16
>> bytes.
>>
>> -Kevin
>>
>
>
On Sun, Aug 05, 2012 at 12:21:13PM +0100, Matthew Millman wrote:
> Hi
>
> I'm seeing a rather interesting problem with UHCI on Intel US15W and
> wondered if anyone else had seen anything like this before. I noticed it
> when I plugged in a USB keyboard, which caused a crash due to something
> corrupting the stack? it turns out that the stack has been trashed by the
> UHCI controller via DMA?!
>
> When trying to transmit the 8 byte address setup packet, the hardware
> doesn't quite seem to be doing as it's told. SeaBIOS sets up the UHCI TDs
> exactly as per the spec - no problems there,
>
> Once the QH element is set, instead of transmitting the 8 bytes as
> described in the TD, it transmits a full 1023 bytes? (according to the
> returned TD) UHCI then goes ahead and overwrites another 35 bytes beyond
> the end of the buffer pointed to by the TD.
>
> Here's the 8 bytes of the setup packet (I've set everything after it to
> 0xFF):
>
> 1fbc1f95: 00 05 01 00 00 00 00 00 ff ff ff
> 1fbc1fa0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 1fbc1fb0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 1fbc1fc0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 1fbc1fd0: ff ff ff ff ff
>
> Here it is after the UHCI controller has been at it. The only code to
> execute between these two dumps is this:
>
> pipe->qh.element = (u32)&tds[0]; (in uhci_control())
>
> 1fbc1f95: 00 05 01 00 00 00 00 00 ff ff ff
> 1fbc1fa0: bf 00 05 01 00 00 00 00 00 ff ff ff fd 03 00 00
> 1fbc1fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 1fbc1fc0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 1fbc1fd0: ff ff ff ff ff
>
> TD Chain before:
> 1fbc4870: 84 48 bc 1f 00 00 80 1c 2d 00 e0 00 95 1f bc 1f
> 1fbc4880: 01 00 00 00 00 00 80 04 69 00 e8 ff 00 00 00 00
>
> TD Chain after:
> 1fbc4870: 84 48 bc 1f ff 07 80 1c 2d 00 e0 00 95 1f bc 1f
> 1fbc4880: 01 00 00 00 00 00 80 04 69 00 e8 ff 00 00 00 00
My read of the spec says an actlen=0x07ff means a null transfer (not
1023 bytes). However, given that the status is still active I don't
think it really matters what's in the td.
> I'm wondering if I'm not the first person to have seen this. The problem
> (without detailed debugging) manifests its self exactly as described in
> this message:
I haven't seen this type of report before. A couple of things you
could try: dump the USB controller registers as well (the controller
may have shutdown for a different reason), check to see if any other
transfer attempted to use 0x1fbc1fa0 in the past (perhaps the
controller has something stale cached), look for an errata for the
chipset, look through the linux code for the chipset to see if it is
working about something, try aligning the setup packet buffer to 16
bytes.
-Kevin
On 07/24/12 19:51, Alexey Korolev wrote:
> Hi,
>
> Win2003 falls to BSOD during early init stage of installer.
> It is ACPI related issue and it appears in any configuration. RAM size is 6GB
> Error code is :
> 0x000000A5 (0x02, 0xFFFFfADF6A446880, 0x1, 0xFFFFFADFAA34690)
>
> The things get broken after commit 2062f2bab81915c5c1f7af12a49ad8d4b3fd23fb (update dsdt resources at runtime)
>
> I've tried to debug this issue but haven't succeed yet.
>
> One strange thing here is that the code doesn't reach the _CRS method. We have added a debug output but nothing related to CRS was printed.
> May be you have any ideas why it may fail. I would much appreciate any help on this.
DBUG() didn't work for me with winxp (same code base as win2k3 iirc), so
no debug output is *not* an indicator for not reaching _CRS.
Is this win2k3 with latest service pack? I've used winxp with sp3 for
testing ...
cheers,
Gerd
On Thu, Jul 26, 2012 at 03:38:47PM +0000, Alexey Korolev wrote:
> HI,
>
> Current version of Seabios is causing blue screen on Windows2003 when 64bit PCI resource is present and occupies high memory.
>
> BSOD Error code is: 0x000000A5 (0x02, 0xFFFFfADF6A446880, 0x1, 0xFFFFFADFAA34690)
>
> The issue is localized, it is related to presence of 64bit resource in _CRS method.
>
> If we disable a 64bit region from _CRS the Win2003 load normally but this doesn't allow Windows to use 64bit resources.
>
> At the moment I have no idea how to fix this. Please help!
Unfortunately, it's very difficult to debug acpi issues on Windows.
Gerd's been on vacation this week - so, lets give him a chance to look
at it when he gets back. If it can't be resolved, we'll need to
revert the patch that broke Win2003.
> P/S
> Yet another issue is related to debug messages.
> If I add any DBUG call in acpi-dst it will cause BSOD on win2003 (win2008 works fine)
I've seen this as well (on WinXP - I don't have Win2003).
Unfortunately, I haven't been able to find out why the debug macro
fails on these older versions of Windows.
-Kevin
Hi
I'm seeing a rather interesting problem with UHCI on Intel US15W and
wondered if anyone else had seen anything like this before. I noticed it
when I plugged in a USB keyboard, which caused a crash due to something
corrupting the stack? it turns out that the stack has been trashed by the
UHCI controller via DMA?!
When trying to transmit the 8 byte address setup packet, the hardware
doesn't quite seem to be doing as it's told. SeaBIOS sets up the UHCI TDs
exactly as per the spec - no problems there,
Once the QH element is set, instead of transmitting the 8 bytes as
described in the TD, it transmits a full 1023 bytes? (according to the
returned TD) UHCI then goes ahead and overwrites another 35 bytes beyond
the end of the buffer pointed to by the TD.
Here's the 8 bytes of the setup packet (I've set everything after it to
0xFF):
1fbc1f95: 00 05 01 00 00 00 00 00 ff ff ff
1fbc1fa0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
1fbc1fb0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
1fbc1fc0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
1fbc1fd0: ff ff ff ff ff
Here it is after the UHCI controller has been at it. The only code to
execute between these two dumps is this:
pipe->qh.element = (u32)&tds[0]; (in uhci_control())
1fbc1f95: 00 05 01 00 00 00 00 00 ff ff ff
1fbc1fa0: bf 00 05 01 00 00 00 00 00 ff ff ff fd 03 00 00
1fbc1fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1fbc1fc0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
1fbc1fd0: ff ff ff ff ff
TD Chain before:
1fbc4870: 84 48 bc 1f 00 00 80 1c 2d 00 e0 00 95 1f bc 1f
1fbc4880: 01 00 00 00 00 00 80 04 69 00 e8 ff 00 00 00 00
TD Chain after:
1fbc4870: 84 48 bc 1f ff 07 80 1c 2d 00 e0 00 95 1f bc 1f
1fbc4880: 01 00 00 00 00 00 80 04 69 00 e8 ff 00 00 00 00
I'm wondering if I'm not the first person to have seen this. The problem
(without detailed debugging) manifests its self exactly as described in
this message:
http://comments.gmane.org/gmane.linux.bios/55336
Thanks!
Matt
Fred . wrote:
> I see.
> It should be added to an TODO list though.
> Or "things-you-work-on" list.
TODO is for things that existing project participants plan to do.
FireWire and TPM is not neccessarily planned by anyone. If you plan
to do it, then please just send a patch which introduces something
to the code, even if just documentation about current progress.
If "you" in "things-you-work-on" means existing project participants
then the same is true.
If someone was working on these features, there would be sign of that
in the repository or on the mailing list. Neither is true.
If you want to work on either of these features then I suggest to
send some patches to make your effort visible, even if you are still
nowhere near submitting final patches for inclusion.
Just like in every other open source project.
//Peter
Here are two simple fixes for the SCSI driver, so that the LSI adapter
is able to boot FreeDOS.
Paolo Bonzini (2):
lsi: do not reset on error
scsi: fix detection of QEMU
src/blockcmd.c | 2 +-
src/lsi-scsi.c | 2 --
2 files changed, 1 insertion(+), 3 deletions(-)
--
1.7.10.4
Fred . wrote:
> Add support for booting from IEEE 1394 (aka FireWire) interface.
Same here - noone is likely to do this until they want to have it
themselves. When someone is doing an implementation we can talk about
details.
//Peter