Add new manufacturer to allow DIO mode to work with the emulated flash (QEMU-45)

[a159x36]

According to the gd25q32 datasheet -
[http://www.elm-tech.com/en/products/spi-flash-memory/gd25q32/gd25q32.pdf](page 22)
The 0xdd DIO read command needs an extra byte (m0-m7) to allow continuous read mode. It's the same for winbond but I haven't checked any other devices. The idf does send this byte (or at least 4 bits of it - see SPI_FLASH_DIO_ADDR_BITLEN in components/spi_flash/private_include/spi_flash_defs.h) so DIO read won't work on the emulator without discarding it.
This fixes a problem I was having with the nvs_get flash read functions not working on the emulator but I don't know if it fixes all DIO mode problems.

[igrr]

Hi @a159x36, appreciate your PR. Would you mind adding a description, explaining the change? Does Gigadevice flash actually have this quirk, or you are adding it to let the emulation behave correctly? Also it looks like the GD behavior is now the same as Windbond. Would it be a simpler change to switch the flash type from "gd25q32" to "w25q32" in esp32.c?

qemu/hw/xtensa/esp32.c

Line 620 in 2ec9f04

DeviceState *flash_dev = qdev_new("gd25q32");

[a159x36]

OK, I've added a description. I reckon the best way to fix this is to fix the emulated flash rather than pretend it's a winbond device but like you say that would work too.
I've been using the emulator in a university course for distance students who can't get the hardware, it's fantastic, thanks for all your hard work.
I do have some other changes that I made but most are rather trivial or a bit hacky to get something usable.
One thing I had to do that you might want to include was to modify the interrupt matrix emulation to remember the irq state when an interrupt is disabled, see here:
[https://github.com/a159x36/qemu/blob/latest/hw/xtensa/esp32_intc.c]
Without this, DMA for an SPI device won't work because the ll driver code relies on it. I'm emulating an LCD SPI display so this is necessary.
Let me know if you want me to make a pull request for this.
Thanks again.

[igrr]

Thanks for the explanation, it makes sense to me now!
I agree that it is better to fix the buggy driver than to pretend we use a different chip. Since this is pretty small fix to the upstream code, do you mind if I submit it to upstream QEMU, in addition to merging it into our fork? (If yes, please acknowledge DCO option a) and I'll submit the patch under option c).

Regarding the interrupt matrix, I'll have a look. The thing you mention might fix another odd behavior I was seeing, so thank you for that!

I've also taken a look at the commits in your fork. The idea to add HSPI emulation along with the LCD model is great! Do you think the performance will be much worse if we split the emulation into a QEMU SSI master (HSPI) and an SSI slave device (LCD)?

(It's really awesome to hear that this project is helping you in a university course!)

[a159x36]

   By making a contribution to this project, I certify that:

    (a) The contribution was created in whole or in part by me and I
        have the right to submit it under the open source license
        indicated in the file

Signed-off-by: Martin Johnson M.J.Johnson@massey.ac.nz

[a159x36]

I've also taken a look at the commits in your fork. The idea to add HSPI emulation along with the LCD model is great! Do you think the performance will be much worse if we split the emulation into a QEMU SSI master (HSPI) and an SSI slave device (LCD)?

I did try to split into a master and a slave device but the spi transaction was too slow. It should be possible to make it work well but I don't know enough about qemu internals to do that so putting everything in the SPI controller was the easiest thing to do.
There are a few other things I did too, gpio interrupts work and it emulates the touch sensors and ADC (but not very well!)
If you want to check out the emulator, try my PlatformIO demo project here:

https://github.com/a159x36/TTGODemo

It should work on Windows, Linux and OSX but doesn't include the DIO flash fix yet.

Thanks again.

[igrr]

Have submitted the patch upstream, will follow up on the qemu-devel mailing list.