Turning Minnowboard (v1) to life on vanilla kernel
Intel Minnowboard (v1) was one of the first Intel's attempts to create an open hardware (okay, to some extent, if we take all possible blobs into consideration) platform based on Intel CPU or SoC (in this case it's an Intel Atom E600 series with EG20T PCH).
Linus Walleij, who was actively maintaining the GPIO subsystem, once sent a patch to convert PCH UDC (USB Device Controller) driver to use GPIO descriptor interface. However, the original code looks strange and seems never worked. It means that VBUS detection mechanism wasn't supported by the kernel. His patch didn't change that, only improved to use modern data structures and APIs. That time I have promised him that I will check the schematics and test it at some point.
First part of the journey appears to be enabling IRQ on GPIO SCH controller, which is not quite usual in a sense of delivery to the OS. The (semi-)wrong assumption that the IRQ is shared with SCI, which is IRQ #9 for x86 case, brought up the wrong change ec689a8a8155 ("mfd: lpc_sch: Add support for Intel Quark X1000") in the kernel (yeah, sometimes product organizations focused on easier way to get job done, without deeper investigation involved). That change has been partially reverted in 922e8ce883e5 ("mfd: lpc_sch: Partially revert "Add support for Intel Quark X1000""). Thanks to Jan Kiszka from Siemens for pointing out to the issue and developing initial fix that landed in the kernel with 7a81638485c1 ("gpio: sch: Add edge event support").
So, are we done? Nope! The second part is to fix GPIO in the UDC driver to be in align with the schematics, according to which (see page 4 D5 and page 8 B1-C2) it uses pin 12 (starting from 0, a.k.a. GPIO_SUS7) on that GPIO controller to detect VBUS. Hence the promised change to the driver 049d3db625a6 ("usb: gadget: pch_udc: Provide a GPIO line used on Intel Minnowboard (v1)") and its updated version dfc03e0bae86 ("usb: gadget: pch_udc: Use PCI sub IDs instead of DMI").
Now we done, right? Not really. What about to test? Yes, the third part is to be sure that it indeed works. The astute reader already asks the question: Why do we need this at all? The board has separate connection for USB host and UDC, it should simply work!. Unfortunately no.
There are possibilities regarding to how UDC should behave when the host is connected. One is to power the device (in our case the board itself) by VBUS, in other words to be USB self-powered device. This is not implemented in case of Minnowboard (v1). So another possibility is to detect VBUS to see when we actually got the host connection. But this is broken on... PCB level and hence doesn't work.
Let's look again at the schematics. First of all on the page 8 B2-B3 the ~4:7 resistor divider (39 kOhm : 68 kOhm) is depicted. It's needed for the high voltage, which is +5v, to be converted to the chip level, which is +3.3v.
So far so good. However, if we go to the page 19 C4 we will see... bootstrap pull-up 10 kOhm to +3.3v (with above 68 kOhm it gives us ~1:7 divider).
Okay, let's assume we connected USB device to it which may consume up to 100 mA on the +5v line. By Ohm's law its resistance could be equal to 50 Ohm. In such case we will have 10 kOhm to +3.3v on one leg and 39 kOhm + 68 kOhm (like in parallel due to above "short circuit") on the other. It still gives us ~1:2.5 divider against +3.3v power rail. That's still well higher than the logical "1" threshold.
Which means that VBUS detection is always high! The bootstrap is dedicated to detect the B1 stepping of the Intel Atom E600 SoC (see page 19 D2-D3). What to do in such case? I don't know the good answer because electrically it's not gonna work. Yes, we may use some timer logic or so to let the BIOS detect that, but I decided just to ignore the bootstrap, so I simply unsoldered R229 from the board. I hope somebody may fix the BIOS to just always assume the B1 stepping if it's not done yet.
This entry was originally posted at https://andy-shev.dreamwidth.org/152628.html. Please comment there using OpenID.
Linus Walleij, who was actively maintaining the GPIO subsystem, once sent a patch to convert PCH UDC (USB Device Controller) driver to use GPIO descriptor interface. However, the original code looks strange and seems never worked. It means that VBUS detection mechanism wasn't supported by the kernel. His patch didn't change that, only improved to use modern data structures and APIs. That time I have promised him that I will check the schematics and test it at some point.
First part of the journey appears to be enabling IRQ on GPIO SCH controller, which is not quite usual in a sense of delivery to the OS. The (semi-)wrong assumption that the IRQ is shared with SCI, which is IRQ #9 for x86 case, brought up the wrong change ec689a8a8155 ("mfd: lpc_sch: Add support for Intel Quark X1000") in the kernel (yeah, sometimes product organizations focused on easier way to get job done, without deeper investigation involved). That change has been partially reverted in 922e8ce883e5 ("mfd: lpc_sch: Partially revert "Add support for Intel Quark X1000""). Thanks to Jan Kiszka from Siemens for pointing out to the issue and developing initial fix that landed in the kernel with 7a81638485c1 ("gpio: sch: Add edge event support").
So, are we done? Nope! The second part is to fix GPIO in the UDC driver to be in align with the schematics, according to which (see page 4 D5 and page 8 B1-C2) it uses pin 12 (starting from 0, a.k.a. GPIO_SUS7) on that GPIO controller to detect VBUS. Hence the promised change to the driver 049d3db625a6 ("usb: gadget: pch_udc: Provide a GPIO line used on Intel Minnowboard (v1)") and its updated version dfc03e0bae86 ("usb: gadget: pch_udc: Use PCI sub IDs instead of DMI").
Now we done, right? Not really. What about to test? Yes, the third part is to be sure that it indeed works. The astute reader already asks the question: Why do we need this at all? The board has separate connection for USB host and UDC, it should simply work!. Unfortunately no.
There are possibilities regarding to how UDC should behave when the host is connected. One is to power the device (in our case the board itself) by VBUS, in other words to be USB self-powered device. This is not implemented in case of Minnowboard (v1). So another possibility is to detect VBUS to see when we actually got the host connection. But this is broken on... PCB level and hence doesn't work.
Let's look again at the schematics. First of all on the page 8 B2-B3 the ~4:7 resistor divider (39 kOhm : 68 kOhm) is depicted. It's needed for the high voltage, which is +5v, to be converted to the chip level, which is +3.3v.
So far so good. However, if we go to the page 19 C4 we will see... bootstrap pull-up 10 kOhm to +3.3v (with above 68 kOhm it gives us ~1:7 divider).
Okay, let's assume we connected USB device to it which may consume up to 100 mA on the +5v line. By Ohm's law its resistance could be equal to 50 Ohm. In such case we will have 10 kOhm to +3.3v on one leg and 39 kOhm + 68 kOhm (like in parallel due to above "short circuit") on the other. It still gives us ~1:2.5 divider against +3.3v power rail. That's still well higher than the logical "1" threshold.
Which means that VBUS detection is always high! The bootstrap is dedicated to detect the B1 stepping of the Intel Atom E600 SoC (see page 19 D2-D3). What to do in such case? I don't know the good answer because electrically it's not gonna work. Yes, we may use some timer logic or so to let the BIOS detect that, but I decided just to ignore the bootstrap, so I simply unsoldered R229 from the board. I hope somebody may fix the BIOS to just always assume the B1 stepping if it's not done yet.
This entry was originally posted at https://andy-shev.dreamwidth.org/152628.html. Please comment there using OpenID.