Hi Magnus,
On Thu, 10 Jul 2025 at 20:09, Magnus Damm <magnus.damm@xxxxxxxxx> wrote:
> On Tue, Jul 8, 2025 at 10:27 PM Wolfram Sang
> <wsa+renesas@xxxxxxxxxxxxxxxxxxxx> wrote:
> > > Removing this breaks the direct-mapped FLASH ROM, which may affect
> > > userspace, and prevents using XIP (but I understand no one cares about
> > > the latter anymore).
> >
> > What is the gain of using rpc-if vs. memory-mapped?
>
> Correct me if I'm wrong, but I believe the "SPI Multi I/O Bus
> Controller" on RZ/A1 is an on-chip device used to interface to the
> on-board SPI flash memories, like Spansion S25FK512S-16 on the Genmai
> board. Depending on the board design and the SoC variant there could
> be a single or two SPI memories in parallel and they may be used in
> QSPI mode as well. There is also HyperFlash support in some newer
> SoCs. This device may by the way often be used to boot the SoC using
> some Mask ROM code.
Indeed.
> The on-chip hardware device (driven by rpc-if under Linux) lets the
> device driver programmer access the external memory either by setting
> up SPI master transfers to read or write the memory, or setting up the
> so-called memory mapped mode. In the memory mapped mode the SPI master
> may be programmed with information such as which flash command
> sequence that should be performed for read accesses. The memory mapped
> mode also has a single physical memory window that automatically
> translates read accesses by the CPU to statically initialized SPI
> master read requests.
True.
> What Geert refers to as direct-mapped FLASH ROM is probably Linux
> performing read-only access to the memory window that is part of the
> "SPI Multi I/O Bus Controller". The configuration has either been set
> up by the Mask ROM (which happens in case the device boots from the
> serial flash) or perhaps the boot loader.
Also correct.
> While the memory mapped read-only mode is kind of cool, for my use
> case the rpc-if driver (either in the kernel or in U-Boot) is used to
> access the flash in various ways. Using MTD under Linux seems like a
> pretty good standard way of for instance programming the flash memory.
MTD is indeed the standard way to access FLASH via a file system...
But to run kernel code from FLASH, it must be direct-mapped.
With traditional NOR FLASH, this is easy.
With FLASH behind an SPI bus, you need hardware support that translates
address bus reads to SPI read commands, which is what the RPC-IF can
do transparently, once configured.
> Also the memory-mapped region is fed into the rpc-if device driver as
> part of the device resources but I don't know exactly how it is being
You mean the "dirmap" register block? That is indeed used for reading
from FLASH by the Linux rpc-if driver. Note that it is limited in
size, so on large FLASHes it serves as a small window to the full FLASH
memory, and must be moved explicitly when needed.
Obviously the window must be fixed for XIP mode.
> utilized. And exactly how the "mtd-rom" device node works with XIP is
> beyond me, but I would be happy to learn if someone could explain.
"mtd-rom" is just simple glue for a direct-mapped memory device.
If you want to combine XIP mode and MTD writing, the driver needs
to be aware of that.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
