While servicing OHCI transfer descriptors(TD), ohci_service_iso_td
retires a TD if it has passed its time frame. It does not check if
the TD was already processed once and holds an error code in TD_CC.
It may happen if the TD list has a loop. Add check to avoid an
infinite loop condition.
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
Reviewed-by: Li Qiang <liq3ea@gmail.com>
Message-id: 20200915182259.68522-3-ppandit@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Just use qemu_open_old() for a quick fix, switch
to better error handling left for another day.
Fixes: 448058aa99 ("util: rename qemu_open() to qemu_open_old()")
Cc: César Belley <cesar.belley@lse.epita.fr>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-id: 20200918110122.9121-1-kraxel@redhat.com
One of the goals of having less boilerplate on QOM declarations
is to avoid human error. Requiring an extra argument that is
never used is an opportunity for mistakes.
Remove the unused argument from OBJECT_DECLARE_TYPE and
OBJECT_DECLARE_SIMPLE_TYPE.
Coccinelle patch used to convert all users of the macros:
@@
declarer name OBJECT_DECLARE_TYPE;
identifier InstanceType, ClassType, lowercase, UPPERCASE;
@@
OBJECT_DECLARE_TYPE(InstanceType, ClassType,
- lowercase,
UPPERCASE);
@@
declarer name OBJECT_DECLARE_SIMPLE_TYPE;
identifier InstanceType, lowercase, UPPERCASE;
@@
OBJECT_DECLARE_SIMPLE_TYPE(InstanceType,
- lowercase,
UPPERCASE);
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Acked-by: Cornelia Huck <cohuck@redhat.com>
Acked-by: Igor Mammedov <imammedo@redhat.com>
Acked-by: Paul Durrant <paul@xen.org>
Acked-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20200916182519.415636-4-ehabkost@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Some typedefs and macros are defined after the type check macros.
This makes it difficult to automatically replace their
definitions with OBJECT_DECLARE_TYPE.
Patch generated using:
$ ./scripts/codeconverter/converter.py -i \
--pattern=QOMStructTypedefSplit $(git grep -l '' -- '*.[ch]')
which will split "typdef struct { ... } TypedefName"
declarations.
Followed by:
$ ./scripts/codeconverter/converter.py -i --pattern=MoveSymbols \
$(git grep -l '' -- '*.[ch]')
which will:
- move the typedefs and #defines above the type check macros
- add missing #include "qom/object.h" lines if necessary
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20200831210740.126168-9-ehabkost@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Some of the enum constant names conflict with the QOM type check
macros (SIFIVE_U_OTP, SIFIVE_U_PRCI). This needs to be addressed
to allow us to transform the QOM type check macros into functions
generated by OBJECT_DECLARE_TYPE().
Rename all the constants to SIFIVE_U_DEV_*, to avoid conflicts.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-Id: <20200911173447.165713-3-ehabkost@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Some of the enum constant names conflict with a QOM type check
macro (SIFIVE_E_PRCI). This needs to be addressed to allow us to
transform the QOM type check macros into functions generated by
OBJECT_DECLARE_TYPE().
Rename all the constants to SIFIVE_E_DEV_*, to avoid conflicts.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-Id: <20200911173447.165713-2-ehabkost@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
The documentation on g_byte_array_free()
<https://developer.gnome.org/glib/stable/glib-Byte-Arrays.html#g-byte-array-free>
says:
> Returns
>
> the element data if free_segment is FALSE, otherwise NULL. The element
> data should be freed using g_free().
Because we currently call g_byte_array_free() with free_segment=TRUE, we
end up passing data=NULL to fw_cfg_add_file().
On the plus side, fw_cfg_data_read() and fw_cfg_dma_transfer() both deal
with NULL data gracefully: QEMU does not crash when the guest reads such
an item, the guest just gets a properly sized, but zero-filled blob.
However, the bug breaks UEFI HTTPS boot, as the IANA_TLS_CIPHER array,
generated otherwise correctly by the "tls-cipher-suites" object, is in
effect replaced with a zero blob.
Fix the issue by passing free_segment=FALSE to g_byte_array_free():
- the caller (fw_cfg_add_from_generator()) temporarily assumes ownership
of the generated byte array,
- then ownership of the byte array is transfered to fw_cfg, as
fw_cfg_add_file() links (not copies) "data" into fw_cfg.
Cc: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Fixes: 3203148917
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20200916151510.22767-1-lersek@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* Couple of cleanups
* New machine properties to define the flash models
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEoPZlSPBIlev+awtgUaNDx8/77KEFAl9kYGcACgkQUaNDx8/7
7KF8ZhAAz1sMrIMCfMovyO+MOIo2ejCDzbCamPulme8GctKf+E3yJ+BTtYkyuxJk
8VxmvFe730KNYC/eUaxddqvFlNDkWbbsoN0YrzqOz1pJKvy7HLUzVt8cX68vcC7i
K+uKdUh1uCf8SRVOdPXrfjbpRE48OZDQEmwfd+Dd+zm/J3LO/z+c3UK2ZvUSidZ7
LefiZYdAAqKLkjr+bVRuuWl92+ZXU1hotciac291CArJ+UaKrHF2WgUYq/SmB0Cr
Bmtl1E5Be2DqvfiIjcJw8/vhE4pGgZEjr8vhLQatxonH4LBKhQVX0KedmmgAheuH
J49TgrKV+s5cMw6XDfJv5h29FgDxM07Te0y1Os8R8GpWJEVQ3JB6u3FFYpGxywBz
u/zRtZRZMDVrnNzUdl/FsYauD167hhVUn9LfVy7DTTv+Vi49NwGy3+Tl/rakUxgq
YjEw99kDaBAWimW/CX40R9qodshxQ4pzN+1C4i6qWdXCFL9xJVXxOwGVlDg7BqGq
uw6FRGC9sv7qp22PIGBv5sHL1YWSgMZtJpHaruBPDKom0zeI6rvjIm7ZlXONnTXj
Fo4xW/JJVqL0+e0gAsChgeTA89zWXGPx72IFs+I7nPMRkDdmtBqQwSd0zSh3VaCJ
bhOixgDhaFhKzKIdOHzDrCj413NoYM/NhDzC4U0Rx0nZKuMsmZk=
=jN+V
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/legoater/tags/pull-aspeed-20200918' into staging
Aspeed patches :
* Couple of cleanups
* New machine properties to define the flash models
# gpg: Signature made Fri 18 Sep 2020 08:23:19 BST
# gpg: using RSA key A0F66548F04895EBFE6B0B6051A343C7CFFBECA1
# gpg: Good signature from "Cédric Le Goater <clg@kaod.org>" [undefined]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: A0F6 6548 F048 95EB FE6B 0B60 51A3 43C7 CFFB ECA1
* remotes/legoater/tags/pull-aspeed-20200918:
misc: aspeed_scu: Update AST2600 silicon id register
hw/arm/aspeed: Add machine properties to define the flash models
hw/arm/aspeed: Map the UART5 device unconditionally
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Aspeed have released an updated datasheet (v7) containing the silicon id
for the AST2600 A2. It looks like this:
SCU004 SCU014
AST2600-A0 0x05000303 0x05000303
AST2600-A1 0x05010303 0x05010303
AST2600-A2 0x05010303 0x05020303
AST2620-A1 0x05010203 0x05010203
AST2620-A2 0x05010203 0x05020203
The SCU004 (silicon id 1) value matches SCU014 for A0, but for
subsequent revisions it is hard coded to the A1 value.
Qemu effectively dropped support for the A0 in 7582591ae7 ("aspeed:
Support AST2600A1 silicon revision") as the A0 reset table was removed,
so it makes sense to only support the behaviour of A1 and onwards.
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20200916082012.776628-1-joel@jms.id.au>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Some machines don't have much differences a part from the flash model
being used. Introduce new machine properties to change them from the
command line.
For instance, to start the ast2500-evb machine with a different FMC
chip and a 64M SPI chip, use :
-M ast2500-evb,fmc-model=mx25l25635e,spi-model=mx66u51235f
Cc: 郁雷 <yulei.sh@bytedance.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Tested-by: Lei YU <yulei.sh@bytedance.com>
Message-Id: <20200915054859.2338477-1-clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
The UART5 is present on the machine regardless there is a
character device connected to it. Map it unconditionally.
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20200905212415.760452-1-f4bug@amsat.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
The cpu hotplug code handles the initialization of coldplugged cpus
too, so it is needed even in case cpu hotplug is not supported.
Wire cpu hotplug up for microvm.
Without this we get a broken MADT table.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Sergio Lopez <slp@redhat.com>
Message-id: 20200915120909.20838-17-kraxel@redhat.com
The cpu hotplug code handles the initialization of coldplugged cpus
too, so it is needed even in case cpu hotplug is not supported.
Move the code from pc to x86, so microvm can use it.
Move both plug and unplug to keep everything in one place, even
though microvm needs plug only.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Sergio Lopez <slp@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-id: 20200915120909.20838-16-kraxel@redhat.com
Both pc and microvm machine types have a acpi_dev field.
Move it to the common base type.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Sergio Lopez <slp@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-id: 20200915120909.20838-15-kraxel@redhat.com
... in case we are using ACPI.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Sergio Lopez <slp@redhat.com>
Message-id: 20200915120909.20838-13-kraxel@redhat.com
With acpi=off continue to use qboot.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Sergio Lopez <slp@redhat.com>
Message-id: 20200915120909.20838-12-kraxel@redhat.com
With ACPI enabled and IO-APIC being properly declared in the ACPI tables
we can use interrupt lines 16-23 for virtio and avoid shared interrupts.
With acpi disabled we continue to use lines 5-12.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Sergio Lopez <slp@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-id: 20200915120909.20838-11-kraxel@redhat.com
$subject says all. Can be controlled using -M microvm,acpi=on/off.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-id: 20200915120909.20838-9-kraxel@redhat.com
qboot isn't a bios and shouldnt be named that way.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Sergio Lopez <slp@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20200915120909.20838-2-kraxel@redhat.com
the negative file I/O performance impact when using a very low value
for 9P client parameter 'msize', which especially is the case if no
'msize' parameter was supplied by the user with a 9P Linux client at all.
All it does is logging a performance warning on host side (once) in
that case. By setting 'msize' on client side to any value larger than
8192 the performance warning will disappear.
See https://wiki.qemu.org/Documentation/9psetup#msize for details.
-----BEGIN PGP SIGNATURE-----
iQJLBAABCgA1FiEEltjREM96+AhPiFkBNMK1h2Wkc5UFAl9gmWwXHHFlbXVfb3Nz
QGNydWRlYnl0ZS5jb20ACgkQNMK1h2Wkc5UbSA//edhciQPI7XX/jfxBd5OaxF28
2/iYY/dEDKcR+cywpXzZsDRvbEo+Sr6xxd0gPV0QnMIVzpUcGwf57L88NS2FcIBm
u702t+ynUg/Za78siQ3CTVcIKT/Da5gIhJQzDJ+tjLjJePKGJBKxSVkEH/j5II9+
9EVIW0SGis7OfRRTiXusxAjeIgGGOBpj8VXy72iaiWw2qig7Nb+ESs84p9DHBjbk
3w3jB8wZS/0q2M3KpBShm20tijW5Evt5xEJfMuxQDKsXfzHOTr8bHgAffVb2kvnD
m0F5jEFyRdaInMtpHU6jtIMm9V0+Wny5UEjLnSBPSgB4mgNpnKoGeezCnIH3xZmt
vGJSQK+83iBH+eOvEHNOD9MWggHjNZi7tqLDyEcmfE9BFS/FEckxpVsYOHLKsLrJ
EBbpcrJGxlgTYIAbLeJ7XPWaidzSw3lrsJzdDSIL9Q2kzsx58iR1O45bJr8i++W0
OyDf5eTUASrZ6pKO74JF3DSwhiN6vsTHQzYDPSsoge+PUUfXVCtVkwXW/vW5csNJ
4Go//BDE5afkuP8doilxDHU4EvXDTiRnzSQn46lMb/n7zbTirIT6NQP8Yre7LS1L
j8qOCA8V0aNBA4pZ3Iax9u00E628gbAgYl0rAh8cudIEPXS1MZNNdMv8Vn0XzMZM
eEqcRH8aZArQsYY5ATE=
=Ha0F
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/cschoenebeck/tags/pull-9p-20200915' into staging
The intention of the following two patches is making users aware about
the negative file I/O performance impact when using a very low value
for 9P client parameter 'msize', which especially is the case if no
'msize' parameter was supplied by the user with a 9P Linux client at all.
All it does is logging a performance warning on host side (once) in
that case. By setting 'msize' on client side to any value larger than
8192 the performance warning will disappear.
See https://wiki.qemu.org/Documentation/9psetup#msize for details.
# gpg: Signature made Tue 15 Sep 2020 11:37:32 BST
# gpg: using RSA key 96D8D110CF7AF8084F88590134C2B58765A47395
# gpg: issuer "qemu_oss@crudebyte.com"
# gpg: Good signature from "Christian Schoenebeck <qemu_oss@crudebyte.com>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: ECAB 1A45 4014 1413 BA38 4926 30DB 47C3 A012 D5F4
# Subkey fingerprint: 96D8 D110 CF7A F808 4F88 5901 34C2 B587 65A4 7395
* remotes/cschoenebeck/tags/pull-9p-20200915:
9pfs: disable msize warning for synth driver
9pfs: log warning if msize <= 8192
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
We want to introduce a new version of qemu_open() that uses an Error
object for reporting problems and make this it the preferred interface.
Rename the existing method to release the namespace for the new impl.
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Fix compiler errors when compiling with -DHPET_DEBUG due to mismatch
between format string token "%x" and the argument type uint64_t.
Also "%#x" is replaced by "0x%" PRIx64 according to the coding style.
Signed-off-by: Dov Murik <dovmurik@linux.vnet.ibm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20200909083650.46771-3-dovmurik@linux.vnet.ibm.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Fix compiler error about defined but not used functions when compiling
with -DHPET_DEBUG by deleting the unused debug functions hpet_ram_readb
and hpet_ram_readw.
Signed-off-by: Dov Murik <dovmurik@linux.vnet.ibm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20200909083650.46771-2-dovmurik@linux.vnet.ibm.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Replace the magic '4' value by the PCI_NUM_PINS definition.
Suggested-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20200910072325.439344-3-f4bug@amsat.org>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
The max7310_gpio_set() handler is static and only used by
qdev_init_gpio_in, initialized with 8 IRQs. The 'line'
argument can not be out of the [0-8[ range.
Replace the dead code by an assertion.
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20200910072325.439344-2-f4bug@amsat.org>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Only build virtio-gpu-device modular (the code which actually depends on
the external virglrenderer library). virtio-gpu-pci and virtio-vga are
compiled into core qemu still.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-id: 20200914134224.29769-7-kraxel@redhat.com
Reference it via ops pointer instead, simliar to the vga one.
Removes hard symbol reference, needed to build virtio-gpu modular.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-id: 20200914134224.29769-6-kraxel@redhat.com
We should add sources to the softmmu_ss or module_ss but not both.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-id: 20200914134224.29769-4-kraxel@redhat.com
Previous patch introduced a performance warning being logged on host
side if client connected with an 'msize' <= 8192. Disable this
performance warning for the synth driver to prevent that warning from
being printed whenever the 9pfs (qtest) test cases are running.
Introduce a new export flag V9FS_NO_PERF_WARN for that purpose, which
might also be used to disable such warnings from the CLI in future.
We could have also prevented the warning by simply raising P9_MAX_SIZE
in virtio-9p-test.c to any value larger than 8192, however in the
context of test cases it makes sense running for edge cases, which
includes the lowest 'msize' value supported by the server which is
4096, hence we want to preserve an msize of 4096 for the test client.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <E1kEyDy-0006nN-5A@lizzy.crudebyte.com>
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
It is essential to choose a reasonable high value for 'msize' to avoid
severely degraded file I/O performance. This parameter can only be
chosen on client/guest side, and a Linux client defaults to an 'msize'
of only 8192 if the user did not explicitly specify a value for 'msize',
which results in very poor file I/O performance.
Unfortunately many users are not aware that they should specify an
appropriate value for 'msize' to avoid severe performance issues, so
log a performance warning (with a QEMU wiki link explaining this issue
in detail) on host side in that case to make it more clear.
Currently a client cannot automatically pick a reasonable value for
'msize', because a good value for 'msize' depends on the file I/O
potential of the underlying storage on host side, i.e. a feature
invisible to the client, and even then a user would still need to trade
off between performance profit and additional RAM costs, i.e. with
growing 'msize' (RAM occupation), performance still increases, but
performance delta will shrink continuously.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <e6fc84845c95816ad5baecb0abd6bfefdcf7ec9f.1599144062.git.qemu_oss@crudebyte.com>
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
When booting directly into a kernel, bypassing the boot loader, the CPU and
UART clocks are not set up correctly. This makes the system appear very
slow, and causes the initrd boot test to fail when optimization is off.
The UART clock must run at 24 MHz. The default 25 MHz reference clock
cannot achieve this, so switch to PLL2/2 @ 480 MHz, which works
perfectly with the default /20 divider.
The CPU clock should run at 800 MHz, so switch it to PLL1/2. PLL1 runs
at 800 MHz by default, so we need to double the feedback divider as well
to make it run at 1600 MHz (so PLL1/2 runs at 800 MHz).
We don't bother checking for PLL lock because we know our emulated PLLs
lock instantly.
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Havard Skinnemoen <hskinnemoen@google.com>
Message-id: 20200911052101.2602693-13-hskinnemoen@google.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This allows these NPCM7xx-based boards to boot from a flash image, e.g.
one built with OpenBMC. For example like this:
IMAGE=${OPENBMC}/build/tmp/deploy/images/gsj/image-bmc
qemu-system-arm -machine quanta-gsj -nographic \
-drive file=${IMAGE},if=mtd,bus=0,unit=0,format=raw,snapshot=on
Reviewed-by: Tyrone Ting <kfting@nuvoton.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Tested-by: Cédric Le Goater <clg@kaod.org>
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Havard Skinnemoen <hskinnemoen@google.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20200911052101.2602693-12-hskinnemoen@google.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This implements a device model for the NPCM7xx SPI flash controller.
Direct reads and writes, and user-mode transactions have been tested in
various modes. Protection features are not implemented yet.
All the FIU instances are available in the SoC's address space,
regardless of whether or not they're connected to actual flash chips.
Reviewed-by: Tyrone Ting <kfting@nuvoton.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Tested-by: Alexander Bulekov <alxndr@bu.edu>
Signed-off-by: Havard Skinnemoen <hskinnemoen@google.com>
Message-id: 20200911052101.2602693-11-hskinnemoen@google.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Stefano Garzarella