Hello!
On 12/12/2019 05:29 PM, Chris Brandt 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
MCU?
> just named "QSPI".
I thought QSPI stands for quad SPI?
>>>>> 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.
I don't think this is a very good idea (and where to place such a driver,
in drives/memory/?... With the separate driver files, you can only build the
needed driver, SPI or HyperFash (or both -- which would be the only choice
with your approach?).
> Note that the MMC/SDHI is the same HW but can act like 2 different peripherals.
Hm, not sure I understand... Isn't MMC and SD driven by the same subsystem?
> We also have USB that can be either host or peripheral.
I know...
>>>>> 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... :-/
The BSP driver was initially written for H3/M3 SoCs and did work there...
But on V3H this driver fails...
> Is that why this "RPC" patch series is taking so long?
> It's a fairly simple piece of hardware.
No. I didn't really use our BSP drivers as a base, so basically had to
write the HyperFLash part from scratch and fix the issues as they appeared...
> 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.
No. :-) It was worked on during all these months... I just finally decided
to stop, take a deep breath, and post what patches I had accumulated, without
the whole driver suite working first... I'm sorry it took so long....
> 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.
Ah! My HyperFlash driver is ready, just the HyperBus core needs some
fixing (I have a draft patch for that)...
>>> 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?
Yes, it covers only RPC-IF (as described in the gen3 manual).
> That's what I'm trying to understand.
>
> My understanding is that HyperFlash uses standard CFI commands, so all
The CFI command set driver needed some changes too (e.g. using the status
register to determine if a command is done).
> 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.
The 1st one prepares the values to be written in either SPI mode or direct
read mode registers. Then you can call "transfer" or "direct mao read" which
would write out the register values into either set...
> 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.
I'd leave this question to Boris, else I never complete this msg. :-)
> Chris
MBR, Sergei
