[U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
Simon Glass
sjg at chromium.org
Tue Aug 11 05:24:16 CEST 2015
Hi Bin,
On 10 August 2015 at 21:17, Bin Meng <bmeng.cn at gmail.com> wrote:
> Hi Simon,
>
> On Tue, Aug 11, 2015 at 11:07 AM, Simon Glass <sjg at chromium.org> wrote:
>> Hi Bin,
>>
>> On 10 August 2015 at 20:53, Bin Meng <bmeng.cn at gmail.com> wrote:
>>> Hi Andrew,
>>>
>>> On Mon, Aug 10, 2015 at 7:32 PM, Andrew Bradford
>>> <andrew at bradfordembedded.com> wrote:
>>>> Hi Bin,
>>>>
>>>> On 08/09 10:52, Bin Meng wrote:
>>>>> Hi Andrew,
>>>>>
>>>>> On Sun, Aug 9, 2015 at 9:08 AM, Andrew Bradford
>>>>> <andrew at bradfordembedded.com> wrote:
>>>>> > Hi Simon,
>>>>> >
>>>>> > On 08/08 10:18, Simon Glass wrote:
>>>>> >> Hi,
>>>>> >>
>>>>> >> On 7 August 2015 at 06:44, Bin Meng <bmeng.cn at gmail.com> wrote:
>>>>> >> > On Fri, Aug 7, 2015 at 8:36 PM, Andrew Bradford
>>>>> >> > <andrew at bradfordembedded.com> wrote:
>>>>> >> >> From: Andrew Bradford <andrew.bradford at kodakalaris.com>
>>>>> >> >>
>>>>> >> >> Allow for configuration of FSP UPD from the device tree which will
>>>>> >> >> override any settings which the FSP was built with itself.
>>>>> >> >>
>>>>> >> >> Modify the MinnowMax and BayleyBay boards to transfer sensible UPD
>>>>> >> >> settings from the Intel FSPv4 Gold release to the respective dts files,
>>>>> >> >> with the condition that the memory-down parameters for MinnowMax are
>>>>> >> >> also used.
>>>>> >> >>
>>>>> >> >> Signed-off-by: Andrew Bradford <andrew.bradford at kodakalaris.com>
>>>>> >> >> ---
>>>>> >> >>
>>>>> >> >
>>>>> >> > Reviewed-by: Bin Meng <bmeng.cn at gmail.com>
>>>>> >> > Tested-by: Bin Meng <bmeng.cn at gmail.com>
>>>>> >> >
>>>>> >>
>>>>> >> Acked-by: Simon Glass <sjg at chromium.org>
>>>>> >> Tested on minnowmax:
>>>>> >> Tested-by: Simon Glass <sjg at chromium.org>
>>>>> >>
>>>>> >> I found that I need to remove two properties from the minnowmax.dts:
>>>>> >>
>>>>> >> - fsp,enable-xhci needs to be removed as this does not work in U-Boot
>>>>> >> at present and stops EHCI from working
>>>>> >> - fsp,mrc-debug-msg needs to be removed to prevent debug information
>>>>> >> being displayed
>>>>> >>
>>>>> >> I plan to apply this with these changes - please let me know if this
>>>>> >> doesn't suit.
>>>>> >
>>>>> > I'm OK with disabling xhci and the MRC debug output in the FSP.
>>>>> >
>>>>> > But if xhci is disabled then I believe when Linux boots that the USB 3.0
>>>>> > port on Minnow Max will only act as a USB 2.0 port. That u-boot doesn't
>>>>> > yet have working XHCI on E3800 means there is a tradeoff and I wasn't
>>>>> > sure which was a better choice.
>>>>>
>>>>> Does these xHCI ports on MinnowMax work fully on Linux kernel? If it
>>>>> works, I'd rather we keep fsp,enable-xhci in the U-Boot.
>>>>
>>>> I believe that the xhci port does work on Minnow Max in Linux but I do
>>>> not have a board so I'm unable to test, sorry.
>>>>
>>>
>>> OK, my test shows that ehci works fine in U-Boot on Bayley Bay.
>>>
>>> Hi Simon,
>>>
>>> What do you think regarding to xhci vs. ehci in U-Boot?
>>
>> The problem is that USB is then broken in U-Boot. I think it is better
>> to limit the speed for the moment until we have that fixed. It is
>> quite useful to be able to use a keyboard or USB stick in U-Boot.
>>
>> With my testing the bottom (blue) port works fine but the top port
>> does not. This happens regardless of the xhci setting.
>
> There are 3 ports on Intel Bayley Bay. One USB 3 (blue port) and two
> USB 2 ports. The board user guide explicitly mentions that the top USB
> 2 port does not work and needs PCB rework. For the other two ports,
> I've tested U-Boot EHCI stack and it works fine. Interesting to hear
> that MinnowMax also has some USB port issue. Maybe the board design is
> following Bayley Bay.
Maybe.
>
>>
>> So overall I think we are in a better position to go with ehci for
>> now, i.e. drop the fsp,enable-xhci property.
>
> OK, then could you please remove this for Bayley Bay as well? Also I
> think we need remove the MRC debug output as well.
Yes will do.
>
>>
>> I think there is a little tweak needed to support both ports, but I
>> haven't dug into it yet.
>>
>
> This is not possible. According to Intel E3800 datasheet, the xHCI and
> EHCI are mutually exclusive. We can either use xHCI, or EHCI.
I believe you can put the ports into a mode where both work, although
presumablly they are both either EHCI or xHCI. When I boot UEFI both
ports work.
Regards,
Simon
More information about the U-Boot
mailing list