[U-Boot] [PATCH v2 14/38] spi: Add support for memory-mapped flash
Bin Meng
bmeng.cn at gmail.com
Fri Oct 18 02:32:05 UTC 2019
Hi Simon,
On Fri, Oct 18, 2019 at 10:22 AM Simon Glass <sjg at chromium.org> wrote:
>
> Hi,
>
> On Thu, 17 Oct 2019 at 08:28, Simon Glass <sjg at chromium.org> wrote:
> >
> > Hi Vignesh,
> >
> > On Wed, 16 Oct 2019 at 04:28, Vignesh Raghavendra <vigneshr at ti.com> wrote:
> > >
> > > Hi Simon,
> > >
> > > On 12/10/19 10:03 AM, Bin Meng wrote:
> > > > Hi Simon,
> > > >
> > > > On Sat, Oct 12, 2019 at 11:08 AM Simon Glass <sjg at chromium.org> wrote:
> > > >>
> > > >> Hi Bin,
> > > >>
> > > >> On Wed, 9 Oct 2019 at 07:55, Bin Meng <bmeng.cn at gmail.com> wrote:
> > > >>>
> > > >>> Hi Simon,
> > > >>>
> > > >>> On Wed, Sep 25, 2019 at 10:12 PM Simon Glass <sjg at chromium.org> wrote:
> > > >>>>
> > > >>>> On x86 platforms the SPI flash can be mapped into memory so that the
> > > >>>> contents can be read with normal memory accesses.
> > > >>>>
> > > >>>> Add a new SPI flash method to find the location of the SPI flash in
> > > >>>> memory. This differs from the existing device-tree "memory-map" mechanism
> > > >>>> in that the location can be discovered at run-time.
> > > >>>>
> > >
> > > Whats is the usecase? Why can't spi_flash_read() be used instead?
> > > Flash + Controller driver can underneath take care of using memory
> > > mapped mode to read data from flash right while making sure that access
> > > is within valid window?
> >
> > I can see spi_flash_read_dm() but it does not support returning a
> > pointer to the data, only reading it.
> >
> > Also I cannot find any documentation about any of this. I've been
> > looking in the doc/ directory.
> >
> > I found the spi_mem.h file but it doesn't mention the meaning of the
> > in and out buffer pointers so I don't know how to use them.
> >
> > Is there an API missing or just comments/documentation?
>
> Apart from this I have found that the ich_spi driver does not work for
> APL since it apparently only supports 'hardware sequencing'. I did try
> getting software sequencing to work, but no dice.
>
> In addition, I found that enabling SPI flash, etc. added about 6KB of code!
>
> So I think it might be best to have two SPI drivers for x86 - one for
> software sequencing and one for hardware?
So if this is true, I think we can create Kconfig options (HW_SEQ and
SW_SEQ) for ICH SPI driver, and select either one in the SoC Kconfig
file.
But I see from the Linux kernel driver, it has:
300static int intel_spi_init(struct intel_spi *ispi)
301{
302 u32 opmenu0, opmenu1, lvscc, uvscc, val;
303 int i;
304
305 switch (ispi->info->type) {
306 case INTEL_SPI_BYT:
307 ispi->sregs = ispi->base + BYT_SSFSTS_CTL;
308 ispi->pregs = ispi->base + BYT_PR;
309 ispi->nregions = BYT_FREG_NUM;
310 ispi->pr_num = BYT_PR_NUM;
311 ispi->swseq_reg = true;
312
313 if (writeable) {
314 /* Disable write protection */
315 val = readl(ispi->base + BYT_BCR);
316 if (!(val & BYT_BCR_WPD)) {
317 val |= BYT_BCR_WPD;
318 writel(val, ispi->base + BYT_BCR);
319 val = readl(ispi->base + BYT_BCR);
320 }
321
322 ispi->writeable = !!(val & BYT_BCR_WPD);
323 }
324
325 break;
326
327 case INTEL_SPI_LPT:
328 ispi->sregs = ispi->base + LPT_SSFSTS_CTL;
329 ispi->pregs = ispi->base + LPT_PR;
330 ispi->nregions = LPT_FREG_NUM;
331 ispi->pr_num = LPT_PR_NUM;
332 ispi->swseq_reg = true;
333 break;
334
335 case INTEL_SPI_BXT:
336 ispi->sregs = ispi->base + BXT_SSFSTS_CTL;
337 ispi->pregs = ispi->base + BXT_PR;
338 ispi->nregions = BXT_FREG_NUM;
339 ispi->pr_num = BXT_PR_NUM;
340 ispi->erase_64k = true;
341 break;
So for INTEL_SPI_BXT (which is for ApolloLake I believe)
ispi->swseq_reg is not set to true which means it uses hardware
sequencer, which seems to contradict with what you found.
Regards,
Bin
More information about the U-Boot
mailing list