We agreed that bitfields are a Bad Idea[tm].
Change-Id: If4c4cb748af340e2721b89fea8e035da0632971f
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/480
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Peter Stuge <peter@stuge.se>
We agreed that bitfields are a Bad Idea[tm].
Change-Id: I1b2bcda28c52ad10bbe9429e04d126b555f7828a
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/478
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Peter Stuge <peter@stuge.se>
We agreed that bitfields are a Bad Idea[tm].
Change-Id: Ic04f151091c359912835b8b3db488d2d41bd4bbb
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/479
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Peter Stuge <peter@stuge.se>
So far it was empty and never published. It now exists and shuts down
all controllers (esp. EHCI which resets the port routers).
Change-Id: I81e355e8a05778d6397675417b085a094a6f48ee
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/397
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
EHCI can take over all ports (and then reroute devices to
companion controllers if needs be). We do that, and then never
reset it.
Consequence:
Systems with only USB1 HC drivers (OHCI/UHCI) never see any devices.
Change-Id: If1d91e9142a6618289b0b3f6b56587ec857158e3
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/396
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
We have fatal(), which is just as good.
Coccinelle script:
@@
expression E;
@@
-usb_fatal(E)
+fatal(E)
Change-Id: Iabecbcc7d068cc0f82687bf51d89c2626642cd86
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/395
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
The USB stack is pretty noisy. Reduce the output to a sane level.
Change-Id: I250949e5cf74a8c6d43822b2e7487143b2ae1c65
Signed-off-by: Mathias Krause <mathias.krause@secunet.com>
Reviewed-on: http://review.coreboot.org/393
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
OHCI works when USB_DEBUG is disabled, but not, when disabled.
This is because the controller requires some more time after a
schedule has finished.
Also improve compliance with the OHCI spec.
Change-Id: I4685cc485ff9c52b489fbaa352ab889671cff876
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/365
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Time for the brown paper bag: OHCI controllers are not happy when
told to send data, but with obviously wrong addresses. It helps
to write the addresses into the data structures.
Change-Id: Ic0967dc8939e64af119cfb89400a045a2c077171
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/306
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Some gcc versions seem to honor volatile at different places in a
struct declaration.
Change-Id: I0df2a3fb2eff4cee8cc1b8ac15d9cd9b86178752
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/155
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
I have observed two separate EHCI host bridges that do not tolerate
using C bit-fields to directly manipulate the portsc_t register. The
reason for this is that the EHCI spec says that port_enable must go
to 0 at the time that port_reset goes to 1. Naturally this cannot be
done using direct bit-field manipulation. Instead, we use a temporary
variable, change the bit-fields there, then atomically write the new
value back to the hardware.
Signed-off-by: Steven A. Falco <sfalco@coincident.com>
Change-Id: If138faee43e0293efa203b86f7893fdf1e811269
Reviewed-on: http://review.coreboot.org/101
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The Intel E6XX Atom processor reports an unknown USB controller type (in
addition to the standard EHCI and OHCI ones). Add a default case to
print a warning when an unknown controller type is detected.
Change-Id: I885d0ccec4c46fd212cceac599290e9bf85edbbb
Signed-off-by: Steven A. Falco <sfalco@coincident.com>
Reviewed-on: http://review.coreboot.org/100
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Other USB drivers set the bus_address field. EHCI should do this too.
Signed-off-by: Steven A. Falco <sfalco@coincident.com>
Change-Id: Ic4274c6744951ef7fa0cb135caf8b9f177d8bcaf
Reviewed-on: http://review.coreboot.org/99
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
The new build system uses quite a few more -W flags for the compiler by
default than the old one. And that's for the better.
Change-Id: Ia8e3d28fb35c56760c2bd0983046c7067e8c5dd6
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/72
Tested-by: build bot (Jenkins)
Reviewed-by: Uwe Hermann <uwe@hermann-uwe.de>
Interrupt transfer support is missing (ie. no keyboard),
bulk and control transfers work (ie. mass storage).
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5845 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
and 5. They're not found if only function 0 is checked. So if a device
exists at all, try all its functions. usb_controller_initialize() will
silently skip all device classes != 0C03.
(changed to continue to use 32bit accesses -pg)
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTEmbedded.de>
Acked-by: Patrick Georgi <patrick.georgi@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5774 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Improve scanning for USB controllers.
Limitations:
- OHCI doesn't support interrupt transfers yet (ie. no keyboards)
- xHCI just does initialization and device attach/detach so far
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5691 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Patrick Georgi <patrick.georgi@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5631 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Move controller specific data structures into private headers,
to avoid conflicts between controller drivers.
Factor out the USB PID ids, which are only exposed on UHCI. It's
of not much use on the other controllers.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5616 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
while others dislike them being extra commits, let's clean them up once and
for all for the existing code. If it's ugly, let it only be ugly once :-)
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5507 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
- support MMC2 devices
- make usb stack more solid
- drop some unused functions
- fix lowspeed/speed naming
- add support for "quirks"
- improve usbhid driver
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Joseph Smith <joe@settoplinux.org>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5299 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
- fix minor bug in serial driver.
- latest USB stack fixes
- fix dead store in options.c
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Patrick Georgi <patrick.georgi@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4239 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Rename the generated config file to libpayload-config.h to differenciate
it from other config.h files. Move the default location of the file to
$(src)/include so that LIBPAYLOAD_PREFIX= users can access the file
without staging it.
Signed-off-by: Jordan Crouse <jordan@cosmicpenguin.net>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3768 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
replaces it with two queues (input, output) where drivers (serial,
keyboard, video, usb) can attach.
The only things left with #ifdefs are initialization (at some point
the drivers must get a chance to register)
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Jordan Crouse <jordan.crouse@amd.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3679 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
560bytes/controller)
- no need for the client of libpayload to implement
usbdisk_{create,remove}, just because USB was compiled in.
- usb hub support compiles, and works for some trivial cases (no device
detach, trivial power management)
- usb keyboard support works in qemu, though there are reports that it
doesn't work on real hardware yet.
- usb keyboard is integrated in both libc-getchar() and curses, if
CONFIG_USB_HID is enabled
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Jordan Crouse <jordan.crouse@amd.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3662 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
memalign implementation (eg. the one I sent yesterday).
Features:
- UHCI controller driver
- UHCI root hub driver
- USB MSC (Mass Storage Class) driver
- skeleton of a USB HID driver
(requires better interrupt transfer handling, which is TODO)
- skeleton of a USB hub driver
(needs several blank spots filled in, eg. power management.
Again: TODO)
OHCI and EHCI are not supported, though OHCI support should be rather
easy as the stack provides reasonable abstractions (or so I hope). EHCI
will probably be more complicated.
Isochronous transfers (eg. webcams, audio stuff, ...) are not supported.
They can be, but I doubt we'll have a reason for that in the boot
environment.
The MSC driver was tested against a couple of USB flash drives, and
should be reasonably tolerant by now. But I probably underestimate
the amount of bugs present in USB flash drives, so feedback is welcome.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Jordan Crouse <jordan.crouse@amd.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3560 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Patrick Georgi