[coreboot] [LinuxBIOS] FILO with the USB

Fridel Fainshtein fainshf at gmail.com
Tue Apr 1 14:37:28 CEST 2008


Anyway, working output is as in the attached file. I use Kingston
DataTraveler 512M

On Sun, Mar 30, 2008 at 3:24 AM,  <joe at smittys.pointclark.net> wrote:
> Quoting Fridel Fainshtein <fainshf at gmail.com>:
>
>
> > Observing the UHCI code I can see the following issue (see usb.c and uhci.c):
>  >
>  > 1) uhc_init(dev);
>  > ...
>  > 2) uhci_init();
>  >
>  Hmm....
>
> >
>  > The first function uses " frame_list[num_controllers] ".
>  > The second function initializes the frame_list by init_framelist(i);
>  >
>  Depend on the value of (i), correct?
>
> >
>  > May be if the order will be different it will works. I am not sure,
>  > though. It is 3 o'clock, may be I just dreaming.
>  >
>  Thanks for the insite Fridel, I will look into this deeper.
>
>
> >
>  >> > Fridel's code, in patch form and with the non-USB bits removed.
>  >>
>  >>  Well,
>  >>  I tested this patch and it does nothing for UHCI :-( It might work
>  >>  great for OHCI but someone else will need to test it.
>  >>
>  >>  > It should fall back, but not everything does that properly. Just for
>  >>  > checking the basic functioning, any old USB 1.1 device (keyboard, mouse,
>  >>  > hub) will do to at least see that it was recognized and configured.
>  >>  >
>  >>  > IIRC, the sequence is:
>  >>  > 1. detect that a device is connected to the port
>  >>  > 2. enable the port
>  >>  > 3. Assign a USB ID with a setup packet
>  >>  > 4. query for device type and strings
>  >>  > 5. If a suitable block device, load the payload.
>  >>  >
>  >>  > 5 used to be a stream object (like in the old LinuxBIOS code) handed to
>  >>  > a copy of the the ELF loader. the read method set up the request and
>  >>  > called into the USB polling loop. I'm guessing that's
>  >>  >
>  >>  > One potential issue there is that control of the physical port between
>  >>  > UHCI or OHCI (for 1.1) and EHCI (for 2.0) is determined by a bit in a
>  >>  > register. I'm not sure what happens if it's set wrong, but I suspect it
>  >>  > could look like your debug output.
>  >>  >
>  >>  > was this exact setup working before r54? One possability is that the USB
>  >>  > code always had a bug that wasn't visible when allocations were quietly
>  >>  > double the requested size.
>  >>
>  >>  So I tried a low speed device (old usb mouse) and it did something
>  >>  different, it still errored out of course (because it is not a drive)
>  >>  but I think it was working the way it is supposed to??? Anyways I also
>  >>  tried a USB 2.0 flash drive with no success. I think what is happening
>  >>  here is, it is not falling back to low speed UHCI......see
>  >>  attachment....I don't know where to go from here....
>  >>
>
>  Thanks - Joe
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: USB_output.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080401/41f36766/attachment.txt>


More information about the coreboot mailing list