Hi Bin,
On Sun, 20 Oct 2019 at 20:34, Bin Meng <bmeng...@gmail.com> wrote:
>
> Hi Simon,
>
> On Sat, Oct 19, 2019 at 10:44 AM Simon Glass <s...@chromium.org> wrote:
> >
> > Hi Bin,
> >
> > On Wed, 9 Oct 2019 at 07:10, Bin Meng <bmeng...@gmail.com> wrote:
> >>
> >> Hi Simon,
> >>
> >> On Wed, Sep 25, 2019 at 10:12 PM Simon Glass <s...@chromium.org> wrote:
> >> >
> >> > This provides access to SPI flash both through a read-only memory map and
> >> > with operations to erase and write flash. It supports 4KB or 64KB erase
> >> > sizes.
> >> >
> >>
> >> I read the SPI controller chapter in the datasheet of apollolake as
> >> well as some latest x86 desktop processors and believe they are
> >> compatible with the existing LPC SPI controller, the one used in ICH7
> >> and ICH9. In fact, in Linux, these SPI controllers are supported by
> >> the same intel-spi-pci.c driver (probe interface, PCI), and is
> >> actually using the same intel-spi.c core driver.
> >>
> >> So I think we should consider expanding the existing ICH SPI driver in
> >> U-Boot to support the PCI variants too.
> >
> >
> > As discussed elsewhere I'll give this another try.
> >>
> >>
> >> > This driver is used by Apollolake.
> >> >
> >> > Signed-off-by: Simon Glass <s...@chromium.org>
> >> > ---
> >> >
> >> > Changes in v2:
> >> > - Add the missing header file
> >> > - Add support for of-platdata for TPL
> >> >
> >> > drivers/mtd/spi/Kconfig | 9 +
> >> > drivers/mtd/spi/Makefile | 1 +
> >> > drivers/mtd/spi/intel_fast_spi.c | 360 +++++++++++++++++++++++++++++++
> >> > 3 files changed, 370 insertions(+)
> >> > create mode 100644 drivers/mtd/spi/intel_fast_spi.c
> >> >
> >
> >
> > [..]
> >
> >>
> >> > +static void fast_spi_early_init(struct udevice *dev)
> >> > +{
> >> > + struct fast_spi_platdata *plat = dev_get_platdata(dev);
> >> > + pci_dev_t pdev = plat->bdf;
> >> > +
> >> > + /* Clear BIT 1-2 SPI Command Register */
> >> > + //remove
> >> > + pci_x86_clrset_config(pdev, PCI_COMMAND, PCI_COMMAND_MASTER |
> >> > + PCI_COMMAND_MEMORY, 0, PCI_SIZE_8);
> >> > +
> >> > + /* Program Temporary BAR for SPI */
> >> > + pci_x86_write_config(pdev, PCI_BASE_ADDRESS_0,
> >> > + plat->mmio_base |
> >> > PCI_BASE_ADDRESS_SPACE_MEMORY,
> >> > + PCI_SIZE_32);
> >> > +
> >> > + /* Enable Bus Master and MMIO Space */
> >> > + pci_x86_clrset_config(pdev, PCI_COMMAND, 0, PCI_COMMAND_MASTER |
> >> > + PCI_COMMAND_MEMORY, PCI_SIZE_8);
> >> > +
> >> > + /*
> >> > + * Disable the BIOS write protect so write commands are allowed.
> >> > + * Enable Prefetching and caching.
> >> > + */
> >> > + pci_x86_clrset_config(pdev, SPIBAR_BIOS_CONTROL,
> >> > + SPIBAR_BIOS_CONTROL_EISS |
> >> > + SPIBAR_BIOS_CONTROL_CACHE_DISABLE,
> >> > + SPIBAR_BIOS_CONTROL_WPD |
> >> > + SPIBAR_BIOS_CONTROL_PREFETCH_ENABLE,
> >> > PCI_SIZE_8);
> >>
> >> I wonder why are these needed, IIUC we rely on FSP2 to initialize the
> >> SoC and I believe for SPI these are some basic settings and registers
> >> should have already be programmed to sane values, no?
> >
> >
> > Which part of the FSP2? This code is executed in TPL so no part of the FSP
> > has been executed yet. Even when we figure out how to run FSP-T (which will
> > run befor ethis code) I am not sure that the FSP will do this.
> >
>
> Per the FSP2 spec, such silicon specific initialization are covered by
> FSP-S. I am not sure if SPI specific registers are touched by FSP-T as
> well.
Yes it is possible. I suppose we will find out when we get FSP-S
support added. But it is a bridge too far for me at present.
Regards,
Simon
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
