On Thu, Jun 11, 2020 at 3:30 PM Havard Skinnemoen <hskinnemoen@google.com>
wrote:

> @@ -57,18 +72,30 @@ static NPCM7xxState *npcm7xx_create_soc(MachineState
> *machine)
>  static void npcm750_evb_init(MachineState *machine)
>  {
>      NPCM7xxState *soc;
> +    DriveInfo *dinfo;
>
>      soc = npcm7xx_create_soc(machine);
>
> +    dinfo = drive_get(IF_MTD, 0, 0);
> +    if (dinfo) {
> +        npcm7xx_connect_flash(&soc->fiu[0], 0, "w25q256", dinfo);
>

Btw, this does not actually work. I initially tested it with the same flash
chip as gsj, which seems to work, but after switching to the Winbond model
(as per the npcm750 evb schematics) it looks like it reads incorrect data
in DIO mode.

While trying to figure out what's going wrong, I stumbled across this patch:

https://lists.gnu.org/archive/html/qemu-devel/2016-07/msg01586.html

which I don't understand. It looks like the winbond model wants one dummy
cycle after the address, since dummy cycles are modeled as byte transfers.
This doesn't seem to match the data sheet, which specifies 4 dummy cycles
in DIO mode (which is actually a special command byte transferred across
two data lines).

If the "continuous read mode command" is actually modeled as a single byte,
then it makes sense because that works out to 4 dummy cycles in DIO mode.
However, I don't understand how the flash controller model is supposed to
detect this situation, and I don't see any flash controller models that
support sending anything but dummy _bits_ between the address and data
phases.

Could you please clarify how this is supposed to work? Are there any
existing machines that use a w25 chip in DIO mode?

Havard