In the previous episode, I was wondering if the SPI-NOR flash can
be memory mapped, so that it can be seen by the JFFS2 driver.
I'm still unable to access the flash directly. I can indirectly
copying some of it to a buffer by issuing a command to the SPI
controller (`sf read`).
The reference manual of the processor claims it should be
possible to memory map it, but does not seem to delve into the
needed details. Could the information be in yet-another
document?
Also, I have been told that the processor is executing from flash
(See also 'XIP') which implies in my opinion that the flash
should be in fact available as memory mapping.
But this is just intuition, and I wouldn't be surprised if
someone proved me wrong.
Some facts that caught my attention:
1. By using objdump to disassemble the u-boot ELF, I can notice
that the text section starts at 40100000. I might read this
incorrecty, but 100000 is the offset in flash of the u-boot
partition. Then 40000000 should be the start of the memory
mapping.
2. Reading from 40000000 via `md` (a U-Boot command that allows
to read from an arbitrary memory location) will trigger the
Synchronous Abort handler. Could this be due to a conflict
for which I can not read whlie executing?
The good news is that I've found way to force arbitrary flash and
partitions offsets in the JFFS2 driver: if The CMD_MTDPARTS
configuration is turned off, the JFFS2 driver will supply its own
(quoting) "'Static' version of command line mtdparts_init() routine",
which will allow for a (quoting) "Single partition on a single device
configuration.".
Even if the code quality is questionable, it has the great
advantage of allowing the injection of constants, which means I
can supply manually the memory area where the flash is mapped.
And since I don't know how to reach the memory-mapped flash, I can
simply leverage the `sf read` command to load the JFFS2 partition in a
static buffer, inject the buffer address in the JFFS2 static
partition/device, and effectively load the filesystem content without
involving the memory mapping.
Following this plan, a few days ago I managed to list the content
of the file system. Today I fixed a little bug that crashed
u-boot during the loading of a file. The bug is trivial (a
pointer assigned to a signed integer, resulting to an overflow on
our 64-bits architecture). I should probably send a patch
upstream, if it applies.
