Attention is currently required from: Joel Linn, Matt DeVillier.
Nicholas Chin has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/81368?usp=email )
Change subject: mb/hp: Add Pro 3500 series (Sandy/Ivy Bridge) ......................................................................
Patch Set 2:
(2 comments)
File src/mainboard/hp/pro_3500_series/Kconfig:
https://review.coreboot.org/c/coreboot/+/81368/comment/e6a8eace_a2c61867 : PS2, Line 37: # FIXME: check this
I unfortunately have no EHCI debugger so I can't test this
An EHCI debugger isn't necessary to determine this value, as all it does is indicate which EHCI controller in the chipset has its debug capable port physically routed to an accessible USB port. This can be done using the `util/find_usbdebug/find_usbdebug.sh` script. Basically, you run it, inserting a usb device into a usb port, and pressing any key (other than q for quit) to refresh the output. It will print out any device that it detects which is connected to an EHCI debug capable port. You can then move the device between ports until it shows up in the output, if at all. If it shows up under `PCI device 0000:00:1a.0`, then the index is 2; if it's under `PCI device 0000:00:1d.0`, then it's index 1. This mapping is defined by `src/southbridge/intel/common/usb_debug.c`.
On the 6 series chipsets (like what the 3500 has), any USB 1.1 low speed or full speed (generally things like keyboards and mice) or USB 2.0 High Speed devices (generally things like flash drives) should work with the script. Older chipsets couldn't work with USB 1.1 devices since those were handled by a UHCI controller, whereas the 6 series translates USB 1.1 traffic into USB 2.0 traffic and handles everything using the EHCI controller. USB 3.0 devices plugged into a USB 2.0 port should also work since USB 3.0 retains USB 2.0 signals for backwards compatibility.
Note that the script doesn't currently work with versions of lsusb 016 and newer, as the output format changed slightly.
Feel free to check and fix this if you want, otherwise just mark the Gerrit comment as resolved and note that you haven't checked it.
File src/mainboard/hp/pro_3500_series/early_init.c:
https://review.coreboot.org/c/coreboot/+/81368/comment/f6e90035_d0057521 : PS2, Line 18: FIXME: Unknown current: RCBA(0x350c)=0x350c
Can you point me in some direction/to some documentation about the usb configuration?
`struct southbridge_usb_port` is defined in `sb/intel/bd82x6x/pch.h`: ``` struct southbridge_usb_port { int enabled; int current; int oc_pin; }; ``` In particular, the current member defines an offset in the `currents[]` array in `sb/intel/bd82x6x/early_usb.c`: ``` const u32 currents[] = { USBIR_TXRX_GAIN_MOBILE_LOW, USBIR_TXRX_GAIN_DEFAULT, USBIR_TXRX_GAIN_HIGH, 0x20000f51, 0x2000094a, 0x2000035f, USBIR_TXRX_GAIN_DESKTOP_LOW, 0x20000357, 0x20000353 }; ``` The value that autoport found in the particular RCBA register doesn't match anything in the currents array. You can check the inteltool.log dump that autoport generated, for the actual value of that register. The address is the number inside `RCBA()` in the comment; there should be a section in inteltool.log for RCBA registers. Seems like autoport was intended to include the value after the `=` in the FIXME comment, but seems like that was overlooked and it's just reprinting the address.
Unfortunately those current registers don't seem to be documented in the public 6 series chipset datasheets, so coreboot's code is probably all there really is in terms of documentation that you're likely able to obtain. New values seem to just be added to that array as they are seen in logs from vendor firmware, such as commit 216ad2170c (sb/intel/bd82x6x: Add new USB currents)
-
Nicholas Chin (Code Review)