Hi Simon, Wolfgang, On Sun, Aug 16, 2020 at 11:40 AM Simon Glass <[email protected]> wrote: > > Hi Wolfgang, > > On Fri, 14 Aug 2020 at 08:04, Wolfgang Wallner > <[email protected]> wrote: > > > > Hi Simon, > > > > Since commit 609b90a6a9c0 ("x86: spi: Rewrite logic for obtaining the SPI > > memory map") I have trouble accessing the SPI flash on my Apollo Lake board > > when booting with Coreboot and having U-Boot as the payload. > > > > Accessing the SPI flash returns -91 (EPROTOTYPE). > > > > My understanding of what happens is the following: > > > > - ich_spi_ofdata_to_platdata() calls ich_spi_get_basics(), the parameter > > 'can_probe' is hardcoded to true > > - There is no PCH device in my devicetree (there is also no PCH driver > > contained in my build) > > - As can_probe is true, ich_spi_get_basics() tries to find a PCH device > > and returns -EPROTOTYPE as it finds none > > > > As far as I see the PCH is not used in the code paths relevant to Apollo > > Lake. > > I think this behavior can not be triggered in a standalone U-Boot on Apollo > > Lake, > > as in this case arch_cpu_init_tpl() requires an LPC, which is below the PCH, > > and so a PCH has to be part of the devicetree anyway. In this case a PCH > > would > > be found in ich_spi_get_basics(), but it would not get used. > > > > As a quick workaround [1], I have set can_probe hardcoded to false, and with > > this change I can access the SPI flash again. > > > > Do you have any advice on how to fix this? > > How about making the value for can_probe depend on a check for > > ich_version == ICHV_APL? > > That might be OK I think. > > I am quite unhappy with how this has turned out. It seems like we > might be able to refactor it to reduce the number of cases.
Since this patch is viewed as only a workaround, would you propose a fix for this issue? Regards, Bin
