[riot-notifications] [RIOT-OS/RIOT] cpu/sam0_common: implement QSPI peripheral, add support to mtd_spi_nor (#15300)
notifications at github.com
Sun Jan 31 01:46:56 CET 2021
@iosabi commented on this pull request.
> + *
+ * @param[in] bus QSPI device to initialize
+void qspi_init(qspi_t bus);
+ * @brief Configure the QSPI peripheral settings
+ * @pre The @p bus has been acquired with @ref qspi_acquire
+ * @param[in] bus QSPI device to configure
+ * @param[in] mode QSPI mode @see qspi_mode_t
+ * @param[in] flags QSPI Configuration Options
+ * @param[in] clk_hz QSPI frequency in Hz
+void qspi_configure(qspi_t bus, qspi_mode_t mode, uint32_t flags, uint32_t clk_hz);
Reading the datasheet it seems that you can only read, but it is not very clear. The nRF52840 has registers for configuring the READ, WRITE and ERASE opcodes, but I can't quite tell if the chip handles writes or not. QN9080 says it only handles reads and actually XIP is not recommended because it is too slow.
I think this is another example of code that shouldn't go into the qspi cpu driver: sending commands to enabled/disable the xip mode in the flash chip (looking at your code I understand you mean no-opcode mode). Some chips use 0xa5 for entering this mode and 0xff to exit, but this depends on the flash chip, not the cpu, and it varies a bit across manufacturers. For this what's needed is a way to set the dummy bytes to send (probably in the flags, or similar).
The XIP mount memory region is normally a window of certain fixed size and address; but you could have a different base flash address if the flash is larger than the window. I don't see this feature in the samd5x, but nrf52840 has the XIPOFFSET register for this purpose. I think that when configuring the memory mapping (`xip_mount` in your branch) the caller should pass the configuration: command (if any), whether an command is needed, the flash base address; and the driver would return the memory address corresponding to the requested base address. If windowing is supported you would set that in the xipoffset register for example, but if there are alignment requirements for this offset or having an offset is not supported the driver could return an address into the fixed region (like `AHB_XIP+base_address` or `AHB_XIP + base_address % min_alignment` while setting the offset to another register). The caller in this example would be a qspi_nor driver, which is different from a qspi_flash driver for example but the same across CPUs. I'd imagine that the qspi_nor driver can send commands to enable the XIP mode in the flash (depending on the flash) and then tell the qspi.h interface to do xip_mount with no opcode; or don't set the XIP mode in the flash if not supported and then tell the qspi.h to do xip_mount using certain opcode for reads.
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the notifications