[U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Bin Meng <bmeng.cn@gmail.com>]

Hi Andrew,

On Sun, Aug 9, 2015 at 9:08 AM, Andrew Bradford
<andrew@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@gmail.com> wrote:
>> > On Fri, Aug 7, 2015 at 8:36 PM, Andrew Bradford
>> > <andrew@bradfordembedded.com> wrote:
>> >> From: Andrew Bradford <andrew.bradford@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@kodakalaris.com>
>> >> ---
>> >>
>> >
>> > Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
>> > Tested-by: Bin Meng <bmeng.cn@gmail.com>
>> >
>>
>> Acked-by: Simon Glass <sjg@chromium.org>
>> Tested on minnowmax:
>> Tested-by: Simon Glass <sjg@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 enabled the MRC debug messages as it was helpful to me as there are a
> set of FSP UPD device tree properties which during my development turned
> out to boot enough for the MRC code in the FSP to run but which would
> not actually end up starting u-boot.  At least having the MRC debug
> message print out showed me that at least u-boot was operating enough to
> call into the FSP and that likely I had something misconfigured in the
> UPD memory settings.  Probably not showing these debug messages is the
> right choice, as if someone wants more debug output then they can also
> use the FSPv4 debug build that Intel now provides.
>

Yep, I found the FSP debug build is pretty useful. At least you can
guess what the FSP is trying to do with the hardware :-)

> Thanks for your help with this patch! :)
> -Andrew

Regards,
Bin