Re: [coreboot] [LinuxBIOS] FILO with the USB

[Corey Osgood]

Sorry to be a pain, but any progress with this?

Thanks,
Corey
> OK, thank you.
> My employer approved the submission. I"ll do it soon.
>
> On Nov 26, 2007 1:24 AM, Corey Osgood <[EMAIL PROTECTED]> wrote:
> > Fridel Fainshtein wrote:
> > > OK,
> > >
> > > supposing FILO USB works
> > > How do I submit the corrections?
> >
> > http://www.linuxbios.org/Development_Guidelines#How_to_contribute
> >
> > In short form:
> > cd to the filo-0.5/ folder
> > svn add * -R (if you've created any new files, be sure to move files
> >
> > you don't want added first)
> > 3) svn diff > clever_patchname.patch
> > 4) edit the patch, add a short description of what the patch does (which
> > goes into the svn commit log) and a Signed-off-by: line, per the
> > guidelines linked to above.
> >
> > Thanks!
> > -Corey

[LinuxBIOS] FILO with the USB

[Fridel Fainshtein]

Hello Corey,

I am sorry too for the late reply.
My employer generally allows to submit GPL staff. However, it seams that he
refuses that I submit something.
I tried to get an official permit a month ago and still failed to get
something.
May be in the future I"ll get one and may be not. Who knows.

Sorry

On Tue, Jan 15, 2008 at 7:13 AM, Corey Osgood 
wrote:
> Sorry to be a pain, but any progress with this?
>
> Thanks,
> Corey
> > OK, thank you.
> > My employer approved the submission. I"ll do it soon.
> >
> > On Nov 26, 2007 1:24 AM, Corey Osgood <[EMAIL PROTECTED]> wrote:
> > > Fridel Fainshtein wrote:
> > > > OK,
> > > >
> > > > supposing FILO USB works
> > > > How do I submit the corrections?
> > >
> > > http://www.linuxbios.org/Development_Guidelines#How_to_contribute
> > >
> > > In short form:
> > > cd to the filo-0.5/ folder
> > > svn add * -R (if you've created any new files, be sure to move
>
> files
> > > you don't want added first)
> > > 3) svn diff > clever_patchname.patch
> > > 4) edit the patch, add a short description of what the patch does
>
> (which
> > > goes into the svn commit log) and a Signed-off-by: line, per the
> > > guidelines linked to above.
> > >
> > > Thanks!
> > > -Corey

[LinuxBIOS] FILO with the USB

[Peter Stuge]

Hi Fridel,

On Sat, Feb 16, 2008 at 12:15:14AM +0200, Fridel Fainshtein wrote:
> My employer generally allows to submit GPL staff. However, it seams
> that he refuses that I submit something.
> I tried to get an official permit a month ago and still failed to get
> something.

As I'm sure your employer knows, the GPL requires distribution also
of source code for your modifications under certain conditions.
Please do send a patch rather than forking if they apply in your
case.

Best regards

//Peter

[LinuxBIOS] FILO with the USB

[Fridel Fainshtein]

http://fainshf.googlepages.com/grub_bt0_bt1_3.tgz

On Tue, Jan 15, 2008 at 8:13 AM, Corey Osgood  wrote:
> Sorry to be a pain, but any progress with this?
>
> Thanks,
>  Corey
> > OK, thank you.
> > My employer approved the submission. I"ll do it soon.
> >
> > On Nov 26, 2007 1:24 AM, Corey Osgood <[EMAIL PROTECTED]> wrote:
> > > Fridel Fainshtein wrote:
> > > > OK,
> > > >
> > > > supposing FILO USB works
> > > > How do I submit the corrections?
> > >
> > > http://www.linuxbios.org/Development_Guidelines#How_to_contribute
> > >
> > > In short form:
> > > cd to the filo-0.5/ folder
> > > svn add * -R (if you've created any new files, be sure to move files
> > >
> > > you don't want added first)
> > > 3) svn diff > clever_patchname.patch
> > > 4) edit the patch, add a short description of what the patch does (which
> > > goes into the svn commit log) and a Signed-off-by: line, per the
> > > guidelines linked to above.
> > >
> > > Thanks!
> > > -Corey

[LinuxBIOS] FILO with the USB

[Corey Osgood]

Sorry, I've been meaning to get back to you on this. Assuming this is the
same version you sent me, you haven't added yourself (or your company, if
they own the copyright) to any of the copyright notices. If you'd like to
send me that info, I'd be happy to make the adjustments and post a patch.
We'd then need you to give one final sign-off (as per the coding guidelines,
it just verifies that you wrote the code), and we can merge the code.

-Corey

On Fri, Mar 28, 2008 at 1:36 PM, Fridel Fainshtein 
wrote:
> http://fainshf.googlepages.com/grub_bt0_bt1_3.tgz
>
> On Tue, Jan 15, 2008 at 8:13 AM, Corey Osgood 
> wrote:
> > Sorry to be a pain, but any progress with this?
> >
> > Thanks,
> >  Corey
> > > OK, thank you.
> > > My employer approved the submission. I"ll do it soon.
> > >
> > > On Nov 26, 2007 1:24 AM, Corey Osgood <[EMAIL PROTECTED]> wrote:
> > > > Fridel Fainshtein wrote:
> > > > > OK,
> > > > >
> > > > > supposing FILO USB works
> > > > > How do I submit the corrections?
> > > >
> > > > http://www.linuxbios.org/Development_Guidelines#How_to_contribute
> > > >
> > > > In short form:
> > > > cd to the filo-0.5/ folder
> > > > svn add * -R (if you've created any new files, be sure to move
>
> files
> > > > you don't want added first)
> > > > 3) svn diff > clever_patchname.patch
> > > > 4) edit the patch, add a short description of what the patch does
>
> (which
> > > > goes into the svn commit log) and a Signed-off-by: line, per the
> > > > guidelines linked to above.
> > > >
> > > > Thanks!
> > > > -Corey

[LinuxBIOS] FILO with the USB

[Fridel Fainshtein]

The changes were made by me, Fridel Fainshtein, for Radware. In the
code, some of my comments are marked by fainshf.

The changes were made mainly in purpose to  1) have an ability to boot
using USB (with grub and without), 2) have an ability to boot from
SATA and IDE independently, 3) boot memtest using FILO even from USB,
4) fix bugs. One of the changes is not relevant to the community
(bt0/bt1), please remove it.

I can prove my ownership of the changes. That is why I send the code only now.
I hope the code will help. Sorry, I have just no time to prepare the
patch as needed.
I can do it but not in the nearest future.

Thank a lot FILO authors.

On Fri, Mar 28, 2008 at 8:42 PM, Corey Osgood  wrote:
> Sorry, I've been meaning to get back to you on this. Assuming this is the
> same version you sent me, you haven't added yourself (or your company, if
> they own the copyright) to any of the copyright notices. If you'd like to
> send me that info, I'd be happy to make the adjustments and post a patch.
> We'd then need you to give one final sign-off (as per the coding guidelines,
> it just verifies that you wrote the code), and we can merge the code.
>
> -Corey
>
> On Fri, Mar 28, 2008 at 1:36 PM, Fridel Fainshtein 
> wrote:
> > http://fainshf.googlepages.com/grub_bt0_bt1_3.tgz
> >
> > On Tue, Jan 15, 2008 at 8:13 AM, Corey Osgood
>
> wrote:
> > > Sorry to be a pain, but any progress with this?
> > >
> > > Thanks,
> > >  Corey
> > > > OK, thank you.
> > > > My employer approved the submission. I"ll do it soon.
> > > >
> > > > On Nov 26, 2007 1:24 AM, Corey Osgood <[EMAIL PROTECTED]> wrote:
> > > > > Fridel Fainshtein wrote:
> > > > > > OK,
> > > > > >
> > > > > > supposing FILO USB works
> > > > > > How do I submit the corrections?
> > > > >
> > > > > http://www.linuxbios.org/Development_Guidelines#How_to_contribute
> > > > >
> > > > > In short form:
> > > > > cd to the filo-0.5/ folder
> > > > > svn add * -R (if you've created any new files, be sure to move
>
> files
> > > > > you don't want added first)
> > > > > 3) svn diff > clever_patchname.patch
> > > > > 4) edit the patch, add a short description of what the patch does
>
> (which
> > > > > goes into the svn commit log) and a Signed-off-by: line, per the
> > > > > guidelines linked to above.
> > > > >
> > > > > Thanks!
> > > > > -Corey

[LinuxBIOS] FILO with the USB

Quoting Corey Osgood :
> Sorry, I've been meaning to get back to you on this. Assuming this is the
> same version you sent me, you haven't added yourself (or your company, if
> they own the copyright) to any of the copyright notices. If you'd like to
> send me that info, I'd be happy to make the adjustments and post a patch.
> We'd then need you to give one final sign-off (as per the coding guidelines,
> it just verifies that you wrote the code), and we can merge the code.
>
> -Corey
>
> On Fri, Mar 28, 2008 at 1:36 PM, Fridel Fainshtein 
> wrote:
> > http://fainshf.googlepages.com/grub_bt0_bt1_3.tgz
> >
> > On Tue, Jan 15, 2008 at 8:13 AM, Corey Osgood 
> > wrote:
> > > Sorry to be a pain, but any progress with this?
> > >
> > > Thanks,
> > >  Corey
> > > > OK, thank you.
> > > > My employer approved the submission. I"ll do it soon.
> > > >
> > > > On Nov 26, 2007 1:24 AM, Corey Osgood <[EMAIL PROTECTED]> wrote:
> > > > > Fridel Fainshtein wrote:
> > > > > > OK,
> > > > > >
> > > > > > supposing FILO USB works
> > > > > > How do I submit the corrections?
> > > > >
> > > > > http://www.linuxbios.org/Development_Guidelines#How_to_contribute
> > > > >
> > > > > In short form:
> > > > > cd to the filo-0.5/ folder
> > > > > svn add * -R (if you've created any new files, be sure to move
> >
> > files
> > > > > you don't want added first)
> > > > > 3) svn diff > clever_patchname.patch
> > > > > 4) edit the patch, add a short description of what the patch does
> >
> > (which
> > > > > goes into the svn commit log) and a Signed-off-by: line, per the
> > > > > guidelines linked to above.
> > > > >
> > > > > Thanks!
> > > > > -Corey

Cool will this fix my problem also?

http://www.coreboot.org/pipermail/coreboot/2008-March/032682.html

Thanks - Joe

[LinuxBIOS] FILO with the USB

[Fridel Fainshtein]

It is UHCI. I worked with OHCI. So, I don't have answer.

On Fri, Mar 28, 2008 at 10:29 PM,   wrote:
> Quoting Corey Osgood :
> > Sorry, I've been meaning to get back to you on this. Assuming this is the
> > same version you sent me, you haven't added yourself (or your company, if
> > they own the copyright) to any of the copyright notices. If you'd like to
> > send me that info, I'd be happy to make the adjustments and post a patch.
> > We'd then need you to give one final sign-off (as per the coding guidelines,
> > it just verifies that you wrote the code), and we can merge the code.
> >
> > -Corey
> >
> > On Fri, Mar 28, 2008 at 1:36 PM, Fridel Fainshtein 
> > wrote:
> > > http://fainshf.googlepages.com/grub_bt0_bt1_3.tgz
> > >
> > > On Tue, Jan 15, 2008 at 8:13 AM, Corey Osgood 
> > > wrote:
> > > > Sorry to be a pain, but any progress with this?
> > > >
> > > > Thanks,
> > > >  Corey
> > > > > OK, thank you.
> > > > > My employer approved the submission. I"ll do it soon.
> > > > >
> > > > > On Nov 26, 2007 1:24 AM, Corey Osgood <[EMAIL PROTECTED]> wrote:
> > > > > > Fridel Fainshtein wrote:
> > > > > > > OK,
> > > > > > >
> > > > > > > supposing FILO USB works
> > > > > > > How do I submit the corrections?
> > > > > > >
> > > > > >
> > > > > > http://www.linuxbios.org/Development_Guidelines#How_to_contribute
> > > > > >
> > > > > > In short form:
> > > > > > cd to the filo-0.5/ folder
> > > > > > svn add * -R (if you've created any new files, be sure to move
> > >
> > > files
> > > > > > you don't want added first)
> > > > > > 3) svn diff > clever_patchname.patch
> > > > > > 4) edit the patch, add a short description of what the patch does
> > >
> > > (which
> > > > > > goes into the svn commit log) and a Signed-off-by: line, per the
> > > > > > guidelines linked to above.
> > > > > >
> > > > > > Thanks!
> > > > > > -Corey
>
> Cool will this fix my problem also?
>
> http://www.coreboot.org/pipermail/coreboot/2008-March/032682.html
>
> Thanks - Joe

[LinuxBIOS] FILO with the USB

Quoting Fridel Fainshtein :
> It is UHCI.

Yes
> I worked with OHCI. So, I don't have answer.

What is the difference? They are both low speed USB 1.1 correct?

Thanks - Joe

[LinuxBIOS] FILO with the USB

[Fridel Fainshtein]

I believe that I solved the UHCI too because the bugs were not in the
USB driver only.
But I don't know, I have never tested UHCI.

On Sat, Mar 29, 2008 at 12:50 AM,   wrote:
> Quoting Fridel Fainshtein :
> > It is UHCI.
>
> Yes
> > I worked with OHCI. So, I don't have answer.
>
> What is the difference? They are both low speed USB 1.1 correct?
>
> Thanks - Joe

[LinuxBIOS] FILO with the USB

Quoting Fridel Fainshtein :
> I believe that I solved the UHCI too because the bugs were not in the
> USB driver only.
> But I don't know, I have never tested UHCI.
>
> On Sat, Mar 29, 2008 at 12:50 AM,   wrote:
> > Quoting Fridel Fainshtein :
> > > It is UHCI.
> >
> > Yes
> > > I worked with OHCI. So, I don't have answer.
> >
> > What is the difference? They are both low speed USB 1.1 correct?

Great, as soon as Corey finishes the patch I will be glad to test UHCI  
for you.

Thanks - Joe

[LinuxBIOS] FILO with the USB

[Corey Osgood]

Fridel's code, in patch form and with the non-USB bits removed, is attached.
Fridel, this is where we need your sign-off ;)
Yes, the coding style of the patch is a mess, but so is the rest of the
program (he actually cleaned his version up, so it looks bad against the
messy upstream). After this gets in, I'll start going over things with
indent to clean it up.

-Corey

On Fri, Mar 28, 2008 at 6:08 PM,  wrote:
> Quoting Fridel Fainshtein :
> > I believe that I solved the UHCI too because the bugs were not in the
> > USB driver only.
> > But I don't know, I have never tested UHCI.
> >
> > On Sat, Mar 29, 2008 at 12:50 AM,   wrote:
> > > Quoting Fridel Fainshtein :
> > > > It is UHCI.
> > >
> > > Yes
> > > > I worked with OHCI. So, I don't have answer.
> > >
> > > What is the difference? They are both low speed USB 1.1 correct?
>
> Great, as soon as Corey finishes the patch I will be glad to test UHCI
> for you.
>
> Thanks - Joe

[LinuxBIOS] FILO with the USB

[Uwe Hermann]

On Fri, Mar 28, 2008 at 09:25:07PM -0400, Corey Osgood wrote:
> Fridel's code, in patch form and with the non-USB bits removed, is attached.
> Fridel, this is where we need your sign-off ;)
> Yes, the coding style of the patch is a mess, but so is the rest of the
> program (he actually cleaned his version up, so it looks bad against the
> messy upstream). After this gets in, I'll start going over things with
> indent to clean it up.

No patch attached.

Uwe.

[LinuxBIOS] FILO with the USB

Quoting Uwe Hermann :
> On Fri, Mar 28, 2008 at 09:25:07PM -0400, Corey Osgood wrote:
> > Fridel's code, in patch form and with the non-USB bits removed, is attached.
> > Fridel, this is where we need your sign-off ;)
> > Yes, the coding style of the patch is a mess, but so is the rest of the
> > program (he actually cleaned his version up, so it looks bad against the
> > messy upstream). After this gets in, I'll start going over things with
> > indent to clean it up.
>
> No patch attached.

Where is the patch?

Thanks - Joe

[LinuxBIOS] FILO with the USB

[Corey Osgood]

On Fri, Mar 28, 2008 at 10:12 PM,  wrote:
> Quoting Uwe Hermann :
> > On Fri, Mar 28, 2008 at 09:25:07PM -0400, Corey Osgood wrote:
> > > Fridel's code, in patch form and with the non-USB bits removed, is
>
> attached.
> > > Fridel, this is where we need your sign-off ;)
> > > Yes, the coding style of the patch is a mess, but so is the rest of the
> > > program (he actually cleaned his version up, so it looks bad against
>
> the
> > > messy upstream). After this gets in, I'll start going over things with
> > > indent to clean it up.
> >
> > No patch attached.
>
> Where is the patch?
>
> Thanks - Joe

What are you talking about? It's right here!

-Corey

[LinuxBIOS] FILO with the USB

> 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:
> detect that a device is connected to the port
> enable the port
> Assign a USB ID with a setup packet
> query for device type and strings
> 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

[LinuxBIOS] FILO with the USB

[Fridel Fainshtein]

Observing the UHCI code I can see the following issue (see usb.c and uhci.c):

1) uhc_init(dev);
...
2) uhci_init();

The first function uses " frame_list[num_controllers] ".
The second function initializes the frame_list by init_framelist(i);

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.

On Sat, Mar 29, 2008 at 7:56 PM,   wrote:
> > 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:
> > detect that a device is connected to the port
> > enable the port
> > Assign a USB ID with a setup packet
> > query for device type and strings
> > 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

[LinuxBIOS] FILO with the USB

Quoting Fridel Fainshtein :
> Observing the UHCI code I can see the following issue (see usb.c and uhci.c):
> 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:
> > > detect that a device is connected to the port
> > > enable the port
> > > Assign a USB ID with a setup packet
> > > query for device type and strings
> > > 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

[LinuxBIOS] FILO with the USB

[Fridel Fainshtein]

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

On Sun, Mar 30, 2008 at 3:24 AM,   wrote:
> Quoting Fridel Fainshtein :
> > Observing the UHCI code I can see the following issue (see usb.c and uhci.c):
> > 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:
> > > > detect that a device is connected to the port
> > > > enable the port
> > > > Assign a USB ID with a setup packet
> > > > query for device type and strings
> > > > 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

[LinuxBIOS] FILO with the USB

[Peter Stuge]

On Fri, Mar 28, 2008 at 05:50:56PM -0400, [e-mail] wrote:
> > It is UHCI.
>
> Yes
> > I worked with OHCI. So, I don't have answer.
>
> What is the difference? They are both low speed USB 1.1 correct?

They are different host controller interfaces.

They accomplish the same thing but are programmed differently.

One analogy is a VIA vs. Intel northbridge for the same CPU.

//Peter