Milo,
My comments are inline below.
dave
----- Original Message -----
From: "Milo Hoffmann" lineage2005@gmail.com To: coreboot@coreboot.org Sent: Thursday, November 8, 2012 11:29:41 PM Subject: [coreboot] BIOS Savior (RD1-PMC4/8X) unavailable? Build my own?
Hello list,
I might be missing something here, but I've spent all day trying to find a vendor (anywhere) who actually carries the BIOS Savior model I've determined I need. I did find on the ioss website that they have stopped manufacturing (I believe that's what they were trying to say) the models I need. [1] I have a PLCC32 socket (holding an SST 49LF004B) and the ioss reference page [2][3] indicates an RD1-PMC4 or RD1-8X (not 8X2).
So... I started down the line of thought that I should be able to build my own, or come close enough to it with a switchable solution, for testing.
Digging around, I found the wiki page indicating that it was possible to build your own [4]. There was no PLCC example, so I searched a bit more and found this [5] thread and this [6] reference. The thread included a quick and dirty explanation of setup (provided that you have identical chips) along with other useful hints. The reference was less helpful unless I can get a 8Mb (1MB) flash chip that is otherwise identical to the SST49LF004B.
But, the thread also said I would need a "32pin PLCC-Plugin-Adapter" for which I have found a few part numbers but no US distributor (haven't looked international yet).
I have the datasheet for the SST49LF004B (and two known working chips) but don't know the rest of the equation.
The datasheet does not include the /CE pin from the quick and dirty explanation. I interpret it to mean the WE# (Write Enable) pin but am seeking confirmation from more informed folks.
Can anyone on the list confirm I could hook up two identical SST49LF004B, using the WE# pin, to a three wire switch and have a functioning switchable BIOS?
If you are switching between two flash devices you would want to be switching between the two CE# signals. Switching between the two WE# signals would only disable writing to one device, and reads would be sourced by both devices. You would need a separate pullup on each devices CE# signal so that when that devices CE# isn't being driven by the mother-boards CE# output that device would be disabled.
The devices don't necessarily need to be the same exact device, unless there is some other constraint (e.g. size, flash support,etc). You could have a SST49LF004B in one socket and a SST49LF002 or SST49LF008 in the other socket. They wouldn't necessarily even need to be the same brand. They would both need to be FWH flash devices though. Most chipsets have a strap that determines whether the ROM R/W cycles will go out on the LPC bus as FWH or LPC-memory cycles.
Is the more elegant solution to also find a PLCC Plug (like say, Winslow Adaptics W9302), two PLCC sockets and some board with which to stick them all together?
I would really like to return the 'spare' SST49LF004B back to it's board once I have a working coreboot firmware load. (I'm sure I'll be asking questions about that soon too. Still trying to get a QEMU coreboot working... hehehee...)
Thanks for any response.
Milo
References: [1] http://www.ioss.com.tw/eg/orderform0703.html [2] http://www.ioss.com.tw/web/English/RD1BIOSSavior/Select/RD1ModelSelectionGui... [3] http://www.ioss.com.tw/web/English/RD1BIOSSavior/SelectionSheet.html [4] http://www.coreboot.org/Developer_Manual/Tools/Dual_Flash [5] http://www.coreboot.org/pipermail/coreboot/2004-August/008798.html [EPIA flash questions] [6] http://www.coreboot.org/pipermail/coreboot/2003-September/005153.html [Homemade BIOS switch for EPIA boards (and others with 2MBit chips)]
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Thank you Dave and Andrew for your responses.
I started digging around and have gotten parts for such a creation and ran across this [1] thread which was of great help in confirming the design of the hack. Doesn't read like it until they get into the dual flash discussion but did have relevant information about the chips I'm working with.
Finding the PLCC plug turned out to be an adventure in frustration and I hope to have it in hand before the Thanksgiving holiday closes to run some tests while on a break.
I do hope to get some pictures (and maybe a parts list) during the build so I can share them on the wiki.
Thanks again and I will hopefully have a working switchable BIOS solution for my environment shortly. Then on to the gritty part of getting my northbridge initialization coding skills up to speed. Still need to get a working QEMU build done but the parts hunting and fact verifying of this hardware hack have been time consuming. :D
Milo
[1] http://www.coreboot.org/pipermail/coreboot/2009-July/051008.html
On Fri, Nov 9, 2012 at 11:51 AM, Dave Frodin dave.frodin@se-eng.com wrote:
Milo,
My comments are inline below.
dave
----- Original Message -----
From: "Milo Hoffmann" lineage2005@gmail.com To: coreboot@coreboot.org Sent: Thursday, November 8, 2012 11:29:41 PM Subject: [coreboot] BIOS Savior (RD1-PMC4/8X) unavailable? Build my own?
Hello list,
I might be missing something here, but I've spent all day trying to find a vendor (anywhere) who actually carries the BIOS Savior model I've determined I need. I did find on the ioss website that they have stopped manufacturing (I believe that's what they were trying to say) the models I need. [1] I have a PLCC32 socket (holding an SST 49LF004B) and the ioss reference page [2][3] indicates an RD1-PMC4 or RD1-8X (not 8X2).
So... I started down the line of thought that I should be able to build my own, or come close enough to it with a switchable solution, for testing.
Digging around, I found the wiki page indicating that it was possible to build your own [4]. There was no PLCC example, so I searched a bit more and found this [5] thread and this [6] reference. The thread included a quick and dirty explanation of setup (provided that you have identical chips) along with other useful hints. The reference was less helpful unless I can get a 8Mb (1MB) flash chip that is otherwise identical to the SST49LF004B.
But, the thread also said I would need a "32pin PLCC-Plugin-Adapter" for which I have found a few part numbers but no US distributor (haven't looked international yet).
I have the datasheet for the SST49LF004B (and two known working chips) but don't know the rest of the equation.
The datasheet does not include the /CE pin from the quick and dirty explanation. I interpret it to mean the WE# (Write Enable) pin but am seeking confirmation from more informed folks.
Can anyone on the list confirm I could hook up two identical SST49LF004B, using the WE# pin, to a three wire switch and have a functioning switchable BIOS?
If you are switching between two flash devices you would want to be switching between the two CE# signals. Switching between the two WE# signals would only disable writing to one device, and reads would be sourced by both devices. You would need a separate pullup on each devices CE# signal so that when that devices CE# isn't being driven by the mother-boards CE# output that device would be disabled.
The devices don't necessarily need to be the same exact device, unless there is some other constraint (e.g. size, flash support,etc). You could have a SST49LF004B in one socket and a SST49LF002 or SST49LF008 in the other socket. They wouldn't necessarily even need to be the same brand. They would both need to be FWH flash devices though. Most chipsets have a strap that determines whether the ROM R/W cycles will go out on the LPC bus as FWH or LPC-memory cycles.
Is the more elegant solution to also find a PLCC Plug (like say, Winslow Adaptics W9302), two PLCC sockets and some board with which to stick them all together?
I would really like to return the 'spare' SST49LF004B back to it's board once I have a working coreboot firmware load. (I'm sure I'll be asking questions about that soon too. Still trying to get a QEMU coreboot working... hehehee...)
Thanks for any response.
Milo
References: [1] http://www.ioss.com.tw/eg/orderform0703.html [2] http://www.ioss.com.tw/web/English/RD1BIOSSavior/Select/RD1ModelSelectionGui... [3] http://www.ioss.com.tw/web/English/RD1BIOSSavior/SelectionSheet.html [4] http://www.coreboot.org/Developer_Manual/Tools/Dual_Flash [5] http://www.coreboot.org/pipermail/coreboot/2004-August/008798.html [EPIA flash questions] [6] http://www.coreboot.org/pipermail/coreboot/2003-September/005153.html [Homemade BIOS switch for EPIA boards (and others with 2MBit chips)]
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
I'm unable to get the USB keyboard to work in payloads. I'm using it with libpayload, and configured libpayload to enable the USB_HID, USB_OHCI, USB_EHCI, USB_UHCI, USB_XHCI drivers.
I call usb_initialize() in the early part of my payload.
Calls to usbhid_havechar() just return 0. Calls to havechar() just return 0xFF.
The USB keyboard works fine with SeaBIOS, which I am using to load my payload as a boot option. I see no difference if I load my payload directly from coreboot.
Does anyone have any ideas as to what I'm missing?
Any suggestions or examples?
Thanks in advance, Dave
I'm unable to get the USB keyboard to work in payloads. I'm using it with libpayload, and configured libpayload to enable the USB_HID, USB_OHCI, USB_EHCI, USB_UHCI, USB_XHCI drivers.
I call usb_initialize() in the early part of my payload.
Calls to usbhid_havechar() just return 0.
When calling usbhid_havechar() directly, one should also call usb_poll() regularly.
Calls to havechar() just return 0xFF.
Suspicious, havechar is defined as havekey in libpayload.h, havekey() should return 0 or 1. However, havekey() calls usb_poll() and, thus, should work.
The USB keyboard works fine with SeaBIOS, which I am using to load my payload as a boot option. I see no difference if I load my payload directly from coreboot.
Does anyone have any ideas as to what I'm missing?
If you use an USB hub, you should also enable USB_HUB. If you have an OHCI controller, try the latest upstream version, OHCI was broken for some time.
Any suggestions or examples?
Well, the USB HID implementation is quite fragile when it comes to timing. usb_poll() should be called at least once every 200ms with no guaranty what happens when you fail to do so. Also, detaching devices (hot unplugging) is broken.
You should see some output from libpayload when it detects USB controllers / devices, did you?
With some modification (see below), libpayload's 'Hello World' example shows input from keyboards (works with UHCI / EHCI+hub for me).
Nico
Thanks in advance, Dave
diff --git a/payloads/libpayload/sample/hello.c b/payloads/libpayload/sample/hello.c index 677a96f..86113af 100644 --- a/payloads/libpayload/sample/hello.c +++ b/payloads/libpayload/sample/hello.c @@ -34,7 +34,13 @@
int main(void) { + usb_initialize(); + printf("Hello world!\n"); + while (1) { + if (havechar()) + putchar(getchar()); + } halt(); return 0; }
Thanks to everyone who sent feedback. Here's where I've gotten.
First I got a current libpayload. That made the biggest difference. Evidently something critical changed in the last month.
The USB keyboard specific stuff in my code is... usb_initialize(); if (havekey()) usb_key = getchar();
The havekey() function is still always returning 1. But now the call to getchar() is returning valid keystrokes.
The first time havekey() is called the following is output to the console...
00:12.2 4396:1002.2 EHCI controller * found device (0x0403:0x6014, USB 2.0), class: unsupported class ff 00:12.0 4397:1002.0 OHCI controller OHCI Version 1.0 00:13.2 4396:1002.2 EHCI controller 00:13.0 4397:1002.0 OHCI controller OHCI Version 1.0 * found device (0x045e:0x009d, USB 2.0) NOTICE: This driver defaults to using the first interface. This might be the wrong choice and lead to limited functionality of the device. Please report such a case to coreboot@coreboot.org as you might be the first. , class: HID Keyboard layout 'us'
The mainboard I'm currently debugging this on doesn't have a PS/2 keyboard controller. It just has a USB keyboard. I'm going to move over to another mainboard that has both to see what happens there.
Thanks again, Dave
----- Original Message -----
From: "Nico Huber" nico.huber@secunet.com To: "Dave Frodin" dave.frodin@se-eng.com Cc: coreboot@coreboot.org Sent: Monday, November 19, 2012 6:14:42 AM Subject: Re: [coreboot] Using USB keyboard in payloads
I'm unable to get the USB keyboard to work in payloads. I'm using it with libpayload, and configured libpayload to enable the USB_HID, USB_OHCI, USB_EHCI, USB_UHCI, USB_XHCI drivers.
I call usb_initialize() in the early part of my payload.
Calls to usbhid_havechar() just return 0.
When calling usbhid_havechar() directly, one should also call usb_poll() regularly.
Calls to havechar() just return 0xFF.
Suspicious, havechar is defined as havekey in libpayload.h, havekey() should return 0 or 1. However, havekey() calls usb_poll() and, thus, should work.
The USB keyboard works fine with SeaBIOS, which I am using to load my payload as a boot option. I see no difference if I load my payload directly from coreboot.
Does anyone have any ideas as to what I'm missing?
If you use an USB hub, you should also enable USB_HUB. If you have an OHCI controller, try the latest upstream version, OHCI was broken for some time.
Any suggestions or examples?
Well, the USB HID implementation is quite fragile when it comes to timing. usb_poll() should be called at least once every 200ms with no guaranty what happens when you fail to do so. Also, detaching devices (hot unplugging) is broken.
You should see some output from libpayload when it detects USB controllers / devices, did you?
With some modification (see below), libpayload's 'Hello World' example shows input from keyboards (works with UHCI / EHCI+hub for me).
Nico
Thanks in advance, Dave
diff --git a/payloads/libpayload/sample/hello.c b/payloads/libpayload/sample/hello.c index 677a96f..86113af 100644 --- a/payloads/libpayload/sample/hello.c +++ b/payloads/libpayload/sample/hello.c @@ -34,7 +34,13 @@
int main(void) {
- usb_initialize();
- printf("Hello world!\n");
- while (1) {
if (havechar())putchar(getchar());- } halt(); return 0;
}
Am 19.11.2012 18:19, schrieb Dave Frodin:
First I got a current libpayload. That made the biggest difference. Evidently something critical changed in the last month.
Nico improved the stack a lot, in particular the OHCI implementation (and then bug fixes pretty much everywhere).
00:12.2 4396:1002.2 EHCI controller
- found device (0x0403:0x6014, USB 2.0), class: unsupported class
ff 00:12.0 4397:1002.0 OHCI controller OHCI Version 1.0 00:13.2 4396:1002.2 EHCI controller 00:13.0 4397:1002.0 OHCI controller OHCI Version 1.0
- found device (0x045e:0x009d, USB 2.0)
All that stuff happens because havekey() is the first opportunity for the system to run usb_poll(), and then to enumerate the devices. If you want to control this better, just run usb_poll() separately.
NOTICE: This driver defaults to using the first interface. This might be the wrong choice and lead to limited functionality of the device. Please report such a case to coreboot@coreboot.org as you might be the first. , class: HID Keyboard layout 'us'
This only means that the device provides multiple interfaces. In USB you have to select one, and the HID driver simply defaults to the first. We didn't find a useful clue what to do in limited environments when encountering such a situation - ie. any standard that proposes that the first interface should provide a "typical keyboard".
Patrick
Patrick Georgi wrote:
This only means that the device provides multiple interfaces.
Dave, please send lsusb -v output for this keyboard.
In USB you have to select one, and the HID driver simply defaults to the first. We didn't find a useful clue what to do in limited environments when encountering such a situation - ie. any standard that proposes that the first interface should provide a "typical keyboard".
A composite device (multiple interfaces) will have various different indicators in the descriptors for which interface is the actual keyboard.
What happens currently if I have two different keyboards connected?
//Peter
Peter, Is this what you were wanting? dave,
Bus 003 Device 002: ID 045e:009d Microsoft Corp. Wireless Optical Desktop 3.0 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x045e Microsoft Corp. idProduct 0x009d Wireless Optical Desktop 3.0 bcdDevice 0.41 iManufacturer 1 iProduct 2 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 59 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 1 Keyboard iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.11 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 63 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 10 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 No Subclass bInterfaceProtocol 0 None iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.11 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 556 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 10
----- Original Message -----
From: "Peter Stuge" peter@stuge.se To: coreboot@coreboot.org Sent: Monday, November 19, 2012 11:05:23 AM Subject: Re: [coreboot] Using USB keyboard in payloads
Patrick Georgi wrote:
This only means that the device provides multiple interfaces.
Dave, please send lsusb -v output for this keyboard.
In USB you have to select one, and the HID driver simply defaults to the first. We didn't find a useful clue what to do in limited environments when encountering such a situation - ie. any standard that proposes that the first interface should provide a "typical keyboard".
A composite device (multiple interfaces) will have various different indicators in the descriptors for which interface is the actual keyboard.
What happens currently if I have two different keyboards connected?
//Peter
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Hi Dave!
Dave Frodin wrote:
Is this what you were wanting?
Exactly! Thanks! I'll explain the important parts:
Bus 003 Device 002: ID 045e:009d Microsoft Corp. Wireless Optical Desktop 3.0 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level)
bDeviceClass=0 says that the device as a whole does not follow any single USB device class specification, and that class is instead specified per-interface. USB devices can have multiple interfaces, which all work in paralell.
Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 59 bNumInterfaces 2
There are two interfaces in this device.
Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 1 Keyboard
The interface with bInterfaceNumber=0 is a HID class interface which implements the HID-specific "Boot Interface Subclass" and speaks using the HID Boot Subclass-specific "Keyboard" protocol. libpayload must use this interface for reading keystrokes.
Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 No Subclass bInterfaceProtocol 0 None
Tricky! The second interface, with bInterfaceNumber=1 is also a HID class interface, but no further information is provided as to how this interface actually works. The host software must explicitly know this device (as identified by vid:pid) in order to make any use of this second interface. libpayload can't use this for anything without explicit support for this keyboard.
//Peter
Am 17.11.2012 06:58, schrieb Dave Frodin:
I'm unable to get the USB keyboard to work in payloads. I'm using it with libpayload, and configured libpayload to enable the USB_HID, USB_OHCI, USB_EHCI, USB_UHCI, USB_XHCI drivers.
What chipset is it (ie. which driver is responsible)? Could you try to run a keyboard behind a USB hub on EHCI (and compile in EHCI and Hub support, of course).
Regards, Patrick
-
Dave Frodin -
Milo Hoffmann -
Nico Huber -
Patrick Georgi -
Peter Stuge