Hello,
It seems that the linuxBIOS mailing list also manages FILO, so I post this here, please let me know if I'm wrong.
I'm trying to boot on an USB key using Filo and an OHCI host, but without success for now. I don't know if this is supposed to work (apparently yes). If not, is there a means to achieve USB key boot without the BIOS?
Here is the description of the problem: USB key used: 0ea0:6828 Ours Technology, Inc. OTI-6828 Flash Disk Please not that this key boots right using the BIOS (but I would like to avoid using the BIOS), and is correctly recognized by linux (I noticed some similarities between the linux USB driver and the filo USB driver) PCI USB controllers (from lspci): 00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3) 00:0b.1 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3)
Apparently, the host doesn't manage to give an address to the key (it tries 2, 3, 4, and so on, and reboots after a while). Here is what I get by setting USB debugging in filo: FILO version 0.5 (remy@localhost) Tue Jul 24 18:48:58 CEST 2007 LinuxLabs USB bootloader ohc_init: ohc_init num_controllers=0 ohci=121ec0 ohc_init: Found OHCI at fc165a30 ohc_reset: Resetting OHCI ohc_reset: USB HC reset_hc usb-fc165a30: ctrl = 0x600 ;Starting OHCI OHCI controller usb-fc165a30 state control: 0x00000683 RWE RWC HCFS=operational CBSR=3 cmdstatus: 0x00000000 SOC=0 intrstatus: 0x00000044 RHSC SF intrenable: 0x80000003 MIE WDH SO hcca frame #0000 roothub.a: 01000208 POTPGT=1 NPS NDP=8 roothub.b: 00000000 PPCM=0000 DR=0000 roothub.status: 00000000 roothub.portstatus [0] = 0x00000100 PPS roothub.portstatus [1] = 0x00000100 PPS roothub.portstatus [2] = 0x00000100 PPS roothub.portstatus [3] = 0x00010101 CSC PPS CCS roothub.portstatus [4] = 0x00000100 PPS roothub.portstatus [5] = 0x00000100 PPS roothub.portstatus [6] = 0x00000100 PPS roothub.portstatus [7] = 0x00000100 PPS poll_usb: poll_usb1 i=0 poll_o_root_hub1 v=00000100 port = fc165a84, controller = 0 poll_o_root_hub: poll_o_root_hub1 v=00000100 port = fc165a88, controller = 0 poll_o_root_hub: poll_o_root_hub1 v=00000100 port = fc165a8c, controller = 0 poll_o_root_hub: poll_o_root_hub1 v=00010101 port = fc165a90, controller = 0 poll_o_root_hub: poll_o_root_hub2 v=00010101 poll_o_root_hub21 v=00010101 Connection on port fc165a90 New USB device, setting address 2 dma_to_td: can not find td RET URB:[ 0] dev: 0,ep: 0-O,type:CTRL,flags: 0,len:0/0,stat:-115(ffffff8d) ohci.c: cmd(8): 00 05 02 00 00 00 00 00 configure_device: Fetching device descriptor length dma_to_td: can not find td RET URB:[ 0] dev: 2,ep: 0-I,type:CTRL,flags: 0,len:0/8,stat:-115(ffffff8d) ohci.c: cmd(8): 80 06 00 01 00 00 08 00 ohci.c: data(0/8): stat:-115 configure_device: Fetching device descriptor dma_to_td: can not find td RET URB:[ 0] dev: 2,ep: 0-I,type:CTRL,flags: 0,len:0/18,stat:-115(ffffff8d) ohci.c: cmd(8): 80 06 00 01 00 00 12 00 ohci.c: data(0/18): stat:-115 OHCI controller usb-fc165a30 state control: 0x00000693 RWE RWC HCFS=operational CLE CBSR=3 cmdstatus: 0x00000000 SOC=0 intrstatus: 0x00000044 RHSC SF intrenable: 0x80000003 MIE WDH SO ed_controlhead 01ff84f0 hcca frame #0000 roothub.a: 01000208 POTPGT=1 NPS NDP=8 roothub.b: 00000000 PPCM=0000 DR=0000 roothub.status: 00000000 roothub.portstatus [0] = 0x00000100 PPS roothub.portstatus [1] = 0x00000100 PPS roothub.portstatus [2] = 0x00000100 PPS roothub.portstatus [3] = 0x00100103 PRSC PPS PES CCS roothub.portstatus [4] = 0x00000100 PPS roothub.portstatus [5] = 0x00000100 PPS roothub.portstatus [6] = 0x00000100 PPS roothub.portstatus [7] = 0x00000100 PPS dma_to_td: can not find td RET URB:[ 0] dev:127,ep: 1-I,type:CTRL,flags: 0,len:0/1,stat:-115(ffffff8d) ohci.c: cmd(8): a1 fe 00 00 00 00 01 00 ohci.c: data(0/1): stat:-115 poll_o_root_hub: poll_o_root_hub1 v=00000100 port = fc165a94, controller = 0 poll_o_root_hub: poll_o_root_hub1 v=00000100 port = fc165a98, controller = 0 poll_o_root_hub: poll_o_root_hub1 v=00000100 port = fc165a9c, controller = 0 poll_o_root_hub: poll_o_root_hub1 v=00000100 port = fc165aa0, controller = 0 poll_usb: poll_usb1 i=0 poll_o_root_hub1 v=00000100 port = fc165a84, controller = 0 poll_o_root_hub: poll_o_root_hub1 v=00000100 port = fc165a88, controller = 0 poll_o_root_hub: poll_o_root_hub1 v=00000100 port = fc165a8c, controller = 0 poll_o_root_hub: poll_o_root_hub1 v=00100103 port = fc165a90, controller = 0 poll_o_root_hub: poll_o_root_hub2 v=00100103 poll_o_root_hub21 v=00100103 Connection on port fc165a90 New USB device, setting address 3 dma_to_td: can not find td RET URB:[ 0] dev: 0,ep: 0-O,type:CTRL,flags: 0,len:0/0,stat:-115(ffffff8d) ohci.c: cmd(8): 00 05 03 00 00 00 00 00 configure_device: Fetching device descriptor length ... and so on (same logs for address 3, 4, etc.)
The USB key seems to be alternatively powered on and off during this process (so I guess the "New USB device" detected is the right one -- and the only one connected anyway).
I'm not familiar at all with USB, so I don't know how to debug this, nor what's wrong here. Note also that I'm using the regular BIOS of the MB (modified by adding an ISA ROM to the BIOS image, which contains FILO), and that I successfully boot using the IDE device.
Any help would be much appreciated.
Thanks in advance,
Remy
Hi Remy,
On Fri, Jul 27, 2007 at 07:41:59PM +0200, Remy Bruno wrote:
USB key used: 0ea0:6828 Ours Technology, Inc. OTI-6828 Flash Disk Please not that this key boots right using the BIOS (but I would like to avoid using the BIOS), and is correctly recognized by linux (I noticed some similarities between the linux USB driver and the filo USB driver) PCI USB controllers (from lspci): 00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3) 00:0b.1 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3)
There are three types of USB controllers:
USB 1.1 specifies two of them; UHCI and OHCI. Intel and VIA are UHCI, most others are OHCI.
USB 2.0 specifies only one; EHCI.
EHCI controllers are not backwards-compatible.
In order to still be able to use USB 1.1-only devices with EHCI controllers, all EHCI controllers must also provide one USB 1.1 PCI device for each USB 2.0 port.
FILO does not support EHCI, so all USB devices will be talking to USB 1.1 hosts.
The USB memory is most likely a USB 2.0 device.
But the OTI chipset may not function properly if it is not connected to a USB 2.0 host. That's all too common.
I'm not familiar at all with USB, so I don't know how to debug this, nor what's wrong here.
Start in Linux; make sure there is no EHCI driver in the kernel, only the OHCI driver, and see if the USB memory still works.
If it does - there is nothing wrong with the OTI chipset and there is in fact a bug in FILO. (Also quite possible.)
Then usbsnoop in the Linux system would be used to see what packets go out to the OHCI controller, and then that would be compared with what FILO is doing.
EHCI support in FILO would be nice! :)
//Peter
Hi Peter,
Yes, my key is USB1-only able (works with usb-ohci and without ehci). I will try usbsnoop, thank you!
BTW, I realized that the PCI device 00:0b.1 is the EHCI controler and 00:0b.0 is the OHCI controller. Lilo tries the 00:0b.0, which is thus the right one.
Bye, Remy
Le vendredi 27 juillet à 20:00, Peter Stuge a écrit:
Hi Remy,
On Fri, Jul 27, 2007 at 07:41:59PM +0200, Remy Bruno wrote:
USB key used: 0ea0:6828 Ours Technology, Inc. OTI-6828 Flash Disk Please not that this key boots right using the BIOS (but I would like to avoid using the BIOS), and is correctly recognized by linux (I noticed some similarities between the linux USB driver and the filo USB driver) PCI USB controllers (from lspci): 00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3) 00:0b.1 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3)
There are three types of USB controllers:
USB 1.1 specifies two of them; UHCI and OHCI. Intel and VIA are UHCI, most others are OHCI.
USB 2.0 specifies only one; EHCI.
EHCI controllers are not backwards-compatible.
In order to still be able to use USB 1.1-only devices with EHCI controllers, all EHCI controllers must also provide one USB 1.1 PCI device for each USB 2.0 port.
FILO does not support EHCI, so all USB devices will be talking to USB 1.1 hosts.
The USB memory is most likely a USB 2.0 device.
But the OTI chipset may not function properly if it is not connected to a USB 2.0 host. That's all too common.
I'm not familiar at all with USB, so I don't know how to debug this, nor what's wrong here.
Start in Linux; make sure there is no EHCI driver in the kernel, only the OHCI driver, and see if the USB memory still works.
If it does - there is nothing wrong with the OTI chipset and there is in fact a bug in FILO. (Also quite possible.)
Then usbsnoop in the Linux system would be used to see what packets go out to the OHCI controller, and then that would be compared with what FILO is doing.
EHCI support in FILO would be nice! :)
//Peter
-- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
* Remy Bruno remy.bruno@trinnov.com [070727 19:41]:
Hello,
It seems that the linuxBIOS mailing list also manages FILO, so I post this here, please let me know if I'm wrong.
I'm trying to boot on an USB key using Filo and an OHCI host, but without success for now. I don't know if this is supposed to work (apparently yes). If not, is there a means to achieve USB key boot without the BIOS?
Can you try with the FILO builtin into etherboot and see if you get a different result with that?
Thank you!
-
Peter Stuge -
Remy Bruno -
Stefan Reinauer