Libpayload USB support

[bifferos]

It seems OHCI and EHCI support is commented out in:

https://svn.coreboot.org/coreboot/trunk/payloads/libpayload/drivers/usb/usbi...

And the files aren't there if you try to comment it back in.  So 
using FILO, it seems it's  necessary to use UHCI if I want the new 
USB stack, if requiring OHCI, I have to switch to the old (obsolete) 
USB stuff.  Switching back to the old FILO USB stack requires a 
code fix.  Looking at:
https://svn.coreboot.org/filo/trunk/filo/fs/blockdev.c

It seems that parse_device_name() always returns DISK_NEW_USB
and not DISK_USB, regardless of which USB stack was selected
in make menuconfig so subsequent call to devopen() will always 
fail to find a device.

I'm mainly posting this to try to understand what's going on,
and if I missed something.  It seems very few people are using
USB with FILO.  I really had to struggle to find the device
name I'm supposed to specify to boot from USB (uda), so 
I'd propose to put that in the README.

I can submit a patch for both of these, but I'm unsure how far 
it gets us!

regards,
Biff.

[Patrick Georgi]

Am 05.02.2010 12:23, schrieb bifferos:
> It seems OHCI and EHCI support is commented out in:
>
> https://svn.coreboot.org/coreboot/trunk/payloads/libpayload/drivers/usb/usbi...
>
> And the files aren't there if you try to comment it back in.

OHCI and EHCI don't exist at this time. There's an OHCI driver available
as patch on the list, but it has licensing issues (it's GPL, while
libpayload is BSD-licensed)
> So 
> using FILO, it seems it's  necessary to use UHCI if I want the new 
> USB stack, if requiring OHCI, I have to switch to the old (obsolete) 
> USB stuff.

Are you sure that it even works? The old USB code was a non-functional
mess, which is why I implemented the new code in the first place.

Patrick

[bifferos]

--- On Fri, 5/2/10, Patrick Georgi  wrote:
> > It seems OHCI and EHCI support is commented out in:
> >
> > https://svn.coreboot.org/coreboot/trunk/payloads/libpayload/drivers/usb/usbi...
> >
> > And the files aren't there if you try to comment it
>
> back in.
> OHCI and EHCI don't exist at this time. There's an OHCI
> driver available
> as patch on the list, but it has licensing issues (it's
> GPL, while
> libpayload is BSD-licensed)

Thanks, that makes sense.  I can see why you don't want to 
merge it.
> > using FILO, it seems it's  necessary to use UHCI
>
> if I want the new
> > USB stack, if requiring OHCI, I have to switch to the
>
> old (obsolete)
> > USB stuff.
>
> Are you sure that it even works?

No, not at all, but it seems to read back a descriptor or two,
which is a start.  I don't have to use FILO, all I am looking
for is a way of getting a boot of Linux from my bootloader off 
a USB device, but I have two problems:

(1) I need to boot from an OHCI device
(2) I don't have VGA display hardware (only serial console)

(2) Seems to rule out solutions involving the more advanced 
payloads like SeaBIOS, maybe someone can correct me if I'm 
wrong, so I ended up with FILO.

I don't know too many other solutions to this problem.  OFW 
seems a little heavy-weight for this, and I'd prefer a C 
solution if possible.

regards,
Biff.

[Patrick Georgi]

Am 05.02.2010 13:35, schrieb bifferos:
> (1) I need to boot from an OHCI device
> (2) I don't have VGA display hardware (only serial console)
>
> (2) Seems to rule out solutions involving the more advanced 
> payloads like SeaBIOS, maybe someone can correct me if I'm 
> wrong, so I ended up with FILO.

SeaBIOS has no mass storage driver either (and no chance of using
libpayload, except for our usb-optionrom project, which isn't complete yet)

You can try the GPL'd OHCI driver at
http://www.coreboot.org/pipermail/coreboot/2009-October/052810.html

It won't be a problem in your special scenario (FILO is GPL as well).
I guess there will be an official OHCI driver at some point, but until
then, you should be able to get things running with the patch.

Patrick

[Joseph Smith]

On 02/05/2010 07:35 AM, bifferos wrote:
> --- On Fri, 5/2/10, Patrick Georgi  wrote:
> > > It seems OHCI and EHCI support is commented out in:
> > >
> > > https://svn.coreboot.org/coreboot/trunk/payloads/libpayload/drivers/usb/usbi...
> > >
> > > And the files aren't there if you try to comment it
> >
> > back in.
> > OHCI and EHCI don't exist at this time. There's an OHCI
> > driver available
> > as patch on the list, but it has licensing issues (it's
> > GPL, while
> > libpayload is BSD-licensed)

I don't understand why libpayload is BSD and not GPL? It just doe not 
make very much sense.

[bifferos]

--- On Fri, 5/2/10, Joseph Smith  wrote:
> I don't understand why libpayload is BSD and not GPL? It
> just doe not 
> make very much sense.

It makes perfect sense to me.  This allows OEMs to make closed-source
payloads for coreboot, something which may have a positive affect on
Coreboot uptake.

regards,
Biff.

[Joseph Smith]

On 02/05/2010 10:07 AM, bifferos wrote:
> --- On Fri, 5/2/10, Joseph Smith  wrote:
> > I don't understand why libpayload is BSD and not GPL? It
> > just doe not
> > make very much sense.
>
> It makes perfect sense to me.  This allows OEMs to make closed-source
> payloads for coreboot, something which may have a positive affect on
> Coreboot uptake.

Ok, but I don't see how closed-source can ever be a good thing for 
coreboot. Especially when we boast about our code being open-source for 
the world to see that it has no security concerns....

To me it sounds like an easy spot for an OEM to slip in what ever they 
want...

[Patrick Georgi]

Am 05.02.2010 16:12, schrieb Joseph Smith:
> Ok, but I don't see how closed-source can ever be a good thing for
> coreboot. Especially when we boast about our code being open-source for
> the world to see that it has no security concerns....
>
> To me it sounds like an easy spot for an OEM to slip in what ever they
> want...

Payloads aren't linked to coreboot, so they can be licensed however the
developer wants in any case, and OEMs can do whatever they want at that
place.

libpayload is just a service to payload developers, and I'd prefer to
have payloads use a known, working and auditable set of library calls
and drivers over whatever hacks OEMs come up with.

Besides: There are open source licenses that the GPL is incompatible
with, but BSD can be combined with pretty much everything. This choice
is not just to allow closed payloads.

Patrick

[Joseph Smith]

On 02/05/2010 10:26 AM, Patrick Georgi wrote:
> Am 05.02.2010 16:12, schrieb Joseph Smith:
> > Ok, but I don't see how closed-source can ever be a good thing for
> > coreboot. Especially when we boast about our code being open-source for
> > the world to see that it has no security concerns....
> >
> > To me it sounds like an easy spot for an OEM to slip in what ever they
> > want...
>
> Payloads aren't linked to coreboot, so they can be licensed however the
> developer wants in any case, and OEMs can do whatever they want at that
> place.
>
> libpayload is just a service to payload developers, and I'd prefer to
> have payloads use a known, working and auditable set of library calls
> and drivers over whatever hacks OEMs come up with.
>
> Besides: There are open source licenses that the GPL is incompatible
> with, but BSD can be combined with pretty much everything. This choice
> is not just to allow closed payloads.

Don't get me wrong, I love libpayload. I just get frustrated with all 
the crazy licensing conflicts.... it can lead to good code going to 
waste, I have seen it before, and I will probably see it again.