On Wed, Dec 11, 2019, Sergei Shtylyov wrote:
> > Since QSPI, HyperFlash and OctaFlash are all 'serial' Flash
> > technologies, I would be find with a driver name of "SBSC" ("Serial
> > Bus Space
> > Controller") which at least looks closer to what is in all the
> > hardware manuals.
>
> How about "Serial Flash Controller" instead?
I would like that better than "RPC". At least it describes what it is.
RPC seems like a stupid name to me (but maybe that's just because I know
how that name was chosen...)
https://www.cypress.com/news/cypress-simplifies-embedded-system-design-new-low-pin-count-hyperram-memory
"The HyperRAM and HyperFlash solution reduces pin count by at least 28 pins, ..."
As a side note, there is another HW block in Renesas that does the same
thing as the SPI-BSC that they use in the MCU devices. That one they
just named "QSPI".
> >>> This driver has been tested on an RZ/A1H RSK and RZ/A2M EVB.
> >>
> >> In the SPI mode only, I assume?
> >
> > Yes. At the moment, there are only requests from users for QSPI flash
> > access (RZ/A and RZ/G users).
>
> I keep being told by the management that we need HyperFlash too. :-) In
> our BSP development, our engineers went "same hardware, 2 drivers"
> way (with different "compatibles" per driver)...
My plan was same HW, same "compatibles", same driver...but the driver
would either register a SPI controller or a Hyperflash controller.
Note that the MMC/SDHI is the same HW but can act like 2 different peripherals.
We also have USB that can be either host or peripheral.
> >>> The testing mostly consisted of formatting an area as JFFS2 and
> >>> doing copying of files and such.
> >>
> >> Did the same (or at least tried to :-) and I must admit that
> >> writing doesn't work with any of the front ends... I still need to get
> this fixed.
>
> The last word from our BSP people was that JFFS2 doesn't work with the
> HyperFLash dedicated BSP driver... :-/
Is that why this "RPC" patch series is taking so long?
It's a fairly simple piece of hardware.
When I first saw the series on the mailing list, my plan was to just wait
and then add RZ/A1 and RZ/A2 support. But....it looks like it all died.
So, I thought I would at least put in my own driver for SPI flash now,
and then go back and add HyperFlash/OctaFlash once I get the chips
swapped out on one of my RZ/A2 boards.
> > However, the driver I posted is pretty simple and works. Does the
> > HyperFlash MTD
>
> There's no HF library, only front end driver.
> The real library covers both SPI and HF. The only difference between the
> two is the h/w setup (minor difference).
But is this "library" something specific to Renesas devices?
That's what I'm trying to understand.
My understanding is that HyperFlash uses standard CFI commands, so all
we need to do is register a CFI device in the driver, just like we
register a serial flash device.
(I guess I could go look at the sample code for our RTOS package and find out)
> > library that you are proposing have a very different API than just
> > 'send bytes' and 'receive bytes'?
>
> There's "prepare" and "transfer" APIs and also "direct map read" API.
I wonder what is the value of the "direct map read" (other than XIP in
RZ/A systems). If you really want to directly access the flash (no
buffering though the MTD layer), you need to register as a mtd-rom device,
and then you don't really need an API at all.
Chris
