Re: quanta q71l not booting with 4.13

[Patrick Venture <venture@google.com>]

On Tue, May 15, 2018 at 9:22 AM, Vernon Mauery
<vernon.mauery@linux.intel.com> wrote:
> On 15-May-2018 07:26 AM, Patrick Venture wrote:
>>
>> Hi;
>>
>> So, i have a couple theories to test but before I ran them down I
>> figured I'd just ask here.  The quanta-q71l won't boot if the BMC is
>> running the 4.13 kernel from openbmc.  I'm theorizing that the spi mux
>> is flipped somehow (maybe a default pin value is getting flipped) or
>> something else is preventing the host from reading its flash.
>>
>> Has anyone experienced anything like this on their platform?
>
>
> The 4.13 kernel has a bunch of new stuff that has to be worked out in device
> tree to make pins and clocks and resets work. We had trouble getting our
> hosts booting as well when we first migrated to 4.13. We had to fix a few
> things in our device tree to get the espi clock working. I think it also
> included a patch that Jae sent to this list for the clock and reset driver.
> This may be an entirely different issue, but that was our story.
>
> +                       espi: espi@1e6ee000 {
> +                               compatible = "aspeed,ast2500-espi-slave";
> +                               reg = <0x1e6ee000 0x100>;
> +                               interrupts = <23>;
> +                               status = "disabled";
> +                               clocks = <&syscon ASPEED_CLK_GATE_ESPICLK>;
> +                               pinctrl-names = "default";
> +                               pinctrl-0 = <&pinctrl_espi_default>;
> +                       };
> +
>
> I think we also had trouble with the host video showing up after the host
> powered on, this was also dependent on some clock control settings in the
> dts. But Ed tells me this is a AST2400, so video is not your problem.

Thanks, although we have video :D on the ast2400, thanks.  I'll take a
look at the other dts between 4.10 & 4.13 and see what other changes
were made to see if anything matches what I expect (including the
patch you've included).

>
> --Vernon