memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.
PS:
- while at it add check for user supplied RAM size and error
out if it mismatches board expected value.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20200219160953.13771-12-imammedo@redhat.com>
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Acked-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20200219160953.13771-11-imammedo@redhat.com>
It's supposed that SOC will check if "-m" provided
RAM size is valid by setting "ram-size" property and
then board would read back valid (possibly corrected
value) to map RAM MemoryReging with valid size.
It isn't doing so, since check is called only
indirectly from
aspeed_sdmc_reset()->asc->compute_conf()
or much later when guest writes to configuration
register.
So depending on "-m" value QEMU end-ups with a warning
and an invalid MemoryRegion size allocated and mapped.
(examples:
-M ast2500-evb -m 1M
0000000080000000-000000017ffffffe (prio 0, i/o): aspeed-ram-container
0000000080000000-00000000800fffff (prio 0, ram): ram
0000000080100000-00000000bfffffff (prio 0, i/o): max_ram
-M ast2500-evb -m 3G
0000000080000000-000000017ffffffe (prio 0, i/o): aspeed-ram-container
0000000080000000-000000013fffffff (prio 0, ram): ram
[DETECTED OVERFLOW!] 0000000140000000-00000000bfffffff (prio 0, i/o): max_ram
)
On top of that sdmc falls back and reports to guest
"default" size, it thinks machine should have.
This patch makes ram-size check actually work and
changes behavior from a warning later on during
machine reset to error_fatal at the moment SOC.ram-size
is set so user will have to fix RAM size on CLI
to start machine.
It also gets out of the way mutable ram-size logic,
so we could consolidate RAM allocation logic around
pre-allocated hostmem backend (supplied by user or
auto created by generic machine code depending on
supplied -m/mem-path/mem-prealloc options.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20200219160953.13771-10-imammedo@redhat.com>
memory_region_allocate_system_memory() API is going away, so
replace it with memdev allocated MemoryRegion. The later is
initialized by generic code, so board only needs to opt in
to memdev scheme by providing
MachineClass::default_ram_id
and using MachineState::ram instead of manually initializing
RAM memory region.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Acked-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20200219160953.13771-9-imammedo@redhat.com>
In case of NUMA there are 2 cases to consider:
1. '-numa node,memdev', the only one that will be available
for 5.0 and newer machine types.
In this case reuse current behavior, with only difference
memdevs are put into MachineState::ram container +
a temporary glue to keep memory_region_allocate_system_memory()
working until all boards converted.
2. fake NUMA ("-numa node mem" and default RAM splitting)
the later has been deprecated and will be removed but the former
is going to stay available for compat reasons for 5.0 and
older machine types
it takes allocate_system_memory_nonnuma() path, like non-NUMA
case and falls under conversion to memdev. So extend non-NUMA
MachineState::ram initialization introduced in previous patch
to take care of fake NUMA case.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20200219160953.13771-6-imammedo@redhat.com>
the new field will be used by boards to get access to main
RAM memory region and will help to save boiler plate in
boards which often introduce a field or variable just for
this purpose.
Memory region will be equivalent to what currently used
memory_region_allocate_system_memory() is returning apart
from that it will come from hostmem backend.
Followup patches will incrementally switch boards to using
RAM from MachineState::ram.
Patch takes care of non-NUMA case and follow up patch will
initialize MachineState::ram for NUMA case.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20200219160953.13771-5-imammedo@redhat.com>
Property will contain link to memory backend that will be
used for backing initial RAM.
Follow up commit will alias -mem-path and -mem-prealloc
CLI options into memory backend options to make memory
handling consistent (using only hostmem backend family
for guest RAM allocation).
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20200219160953.13771-3-imammedo@redhat.com>
it has been deprecated since 4.0 by commit
cb79224b7 (deprecate -mem-path fallback to anonymous RAM)
Deprecation period ran out and it's time to remove it
so it won't get in a way of switching to using hostmem
backend for RAM.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20200219160953.13771-2-imammedo@redhat.com>
RISC-V Patches for the 5.0 Soft Freeze, Part 2
This is a fairly light-weight pull request, but I wanted to send it out to
avoid the Goldfish stuff getting buried as the next PR should contain the H
extension implementation.
As far as this PR goes, it contains:
* The addition of syscon device tree nodes for reboot and poweroff, which
allows Linux to control QEMU without an additional driver. The existing
device was already compatible with the syscon interface.
* A fix to our GDB stub to avoid confusing XLEN and FLEN, specifically useful
for rv32id-based systems.
* A device emulation for the Goldfish RTC device, a simple memory-mapped RTC.
* The addition of the Goldfish RTC device to the RISC-V virt board.
This passes "make check" and boots buildroot for me.
# gpg: Signature made Mon 10 Feb 2020 21:28:04 GMT
# gpg: using RSA key 2B3C3747446843B24A943A7A2E1319F35FBB1889
# gpg: issuer "palmer@dabbelt.com"
# gpg: Good signature from "Palmer Dabbelt <palmer@dabbelt.com>" [unknown]
# gpg: aka "Palmer Dabbelt <palmer@sifive.com>" [unknown]
# gpg: aka "Palmer Dabbelt <palmerdabbelt@google.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: 00CE 76D1 8349 60DF CE88 6DF8 EF4C A150 2CCB AB41
# Subkey fingerprint: 2B3C 3747 4468 43B2 4A94 3A7A 2E13 19F3 5FBB 1889
* remotes/palmer/tags/riscv-for-master-5.0-sf2:
MAINTAINERS: Add maintainer entry for Goldfish RTC
riscv: virt: Use Goldfish RTC device
hw: rtc: Add Goldfish RTC device
riscv: Separate FPU register size from core register size in gdbstub [v2]
riscv/virt: Add syscon reboot and poweroff DT nodes
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
target-arm queue:
* i.MX: Fix inverted sense of register bits in watchdog timer
* i.MX: Add support for WDT on i.MX6
* arm/virt: cleanups to ACPI tables
* Implement ARMv8.1-VMID16 extension
* Implement ARMv8.1-PAN
* Implement ARMv8.2-UAO
* Implement ARMv8.2-ATS1E1
* ast2400/2500/2600: Wire up EHCI controllers
* hw/char/exynos4210_uart: Fix memleaks in exynos4210_uart_init
* hw/arm/raspi: Clean up the board code
# gpg: Signature made Thu 13 Feb 2020 14:40:34 GMT
# gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE
# gpg: issuer "peter.maydell@linaro.org"
# gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [ultimate]
# gpg: aka "Peter Maydell <pmaydell@gmail.com>" [ultimate]
# gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [ultimate]
# Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE
* remotes/pmaydell/tags/pull-target-arm-20200213: (46 commits)
target/arm: Implement ARMv8.1-VMID16 extension
hw/arm/raspi: Extract the cores count from the board revision
hw/arm/raspi: Use a unique raspi_machine_class_init() method
hw/arm/raspi: Extract the board model from the board revision
hw/arm/raspi: Set default RAM size to size encoded in board revision
hw/arm/raspi: Let class_init() directly call raspi_machine_init()
hw/arm/raspi: Make board_rev a field of RaspiMachineClass
hw/arm/raspi: Make machines children of abstract RaspiMachineClass
hw/arm/raspi: Trivial code movement
hw/arm/raspi: Extract the processor type from the board revision
hw/arm/raspi: Extract the RAM size from the board revision
hw/arm/raspi: Extract the version from the board revision
hw/arm/raspi: Correct the board descriptions
hw/arm/raspi: Use BCM2708 machine type with pre Device Tree kernels
hw/char/exynos4210_uart: Fix memleaks in exynos4210_uart_init
hw/arm: ast2600: Wire up EHCI controllers
hw/arm: ast2400/ast2500: Wire up EHCI controllers
target/arm: Enable ARMv8.2-UAO in -cpu max
target/arm: Implement UAO semantics
target/arm: Update MSR access to UAO
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The count of ARM cores is encoded in the board revision. Add a
helper to extract the number of cores, and use it. This will be
helpful when we add the Raspi0/1 that have a single core.
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20200208165645.15657-14-f4bug@amsat.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
[PMM: tweaked commit message as suggested by Igor]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
We added a helper to extract the RAM size from the board
revision, and made board_rev a field of RaspiMachineClass.
The class_init() can now use the helper to extract from the
board revision the board-specific amount of RAM.
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20200208165645.15657-11-f4bug@amsat.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The board revision encode the amount of RAM. Add a helper
to extract the RAM size, and use it.
Since the amount of RAM is fixed (it is impossible to physically
modify to have more or less RAM), do not allow sizes different
than the one anounced by the manufacturer.
Acked-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20200208165645.15657-5-f4bug@amsat.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Initialize EHCI controllers on AST2600 using the existing
TYPE_PLATFORM_EHCI. After this change, booting ast2600-evb
into Linux successfully instantiates a USB interface after
the necessary changes are made to its devicetree files.
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-platform: EHCI generic platform driver
ehci-platform 1e6a3000.usb: EHCI Host Controller
ehci-platform 1e6a3000.usb: new USB bus registered, assigned bus number 1
ehci-platform 1e6a3000.usb: irq 25, io mem 0x1e6a3000
ehci-platform 1e6a3000.usb: USB 2.0 started, EHCI 1.00
usb usb1: Manufacturer: Linux 5.5.0-09825-ga0802f2d0ef5-dirty ehci_hcd
usb 1-1: new high-speed USB device number 2 using ehci-platform
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Niek Linnenbank <nieklinnenbank@gmail.com>
Message-id: 20200207174548.9087-1-linux@roeck-us.net
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Initialize EHCI controllers on AST2400 and AST2500 using the existing
TYPE_PLATFORM_EHCI. After this change, booting ast2500-evb into Linux
successfully instantiates a USB interface.
ehci-platform 1e6a3000.usb: EHCI Host Controller
ehci-platform 1e6a3000.usb: new USB bus registered, assigned bus number 1
ehci-platform 1e6a3000.usb: irq 21, io mem 0x1e6a3000
ehci-platform 1e6a3000.usb: USB 2.0 started, EHCI 1.00
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.05
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: EHCI Host Controller
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20200206183437.3979-1-linux@roeck-us.net
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The original code defines a named object for the resource template but
then returns the resource template object itself; the resulted output
is like below:
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Name (RBUF, ResourceTemplate ()
{
WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDecode,
0x0000, // Granularity
0x0000, // Range Minimum
0x00FF, // Range Maximum
0x0000, // Translation Offset
0x0100, // Length
,, )
......
})
Return (ResourceTemplate ()
{
WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDecode,
0x0000, // Granularity
0x0000, // Range Minimum
0x00FF, // Range Maximum
0x0000, // Translation Offset
0x0100, // Length
,, )
......
})
}
So the named object "RBUF" is actually useless. The more natural way
is to return RBUF instead, or simply drop RBUF definition.
Choose the latter one to simplify the code.
Signed-off-by: Heyi Guo <guoheyi@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-id: 20200204014325.16279-7-guoheyi@huawei.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The address field in each _PRT mapping package should be constructed
with high word for device# and low word for function#, so it is wrong
to use bus_no as the high word. The existing code adds a bunch useless
entries with device #s above 31. Enumerate all possible slots
(i.e. PCI_SLOT_MAX) instead.
Signed-off-by: Heyi Guo <guoheyi@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-id: 20200204014325.16279-5-guoheyi@huawei.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The only difference to hardware revision 4 is that the device doesn't
switch to VGA mode in case someone happens to touch a VGA register,
which should make things more robust in configurations with multiple
vga devices.
Swtiching back to VGA mode happens on reset, either full machine
reset or qxl device reset (QXL_IO_RESET ioport command).
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Message-id: 20200206074358.4274-1-kraxel@redhat.com
For usb2 bMaxPacketSize0 is "n", for usb3 it is "1 << n",
so it must be 9 not 64 ...
rom "Universal Serial Bus 3.1 Specification":
If the device is operating at Gen X speed, the bMaxPacketSize0
field shall be set to 09H indicating a 512-byte maximum packet.
An Enhanced SuperSpeed device shall not support any other maximum
packet sizes for the default control pipe (endpoint 0) control
endpoint.
We now announce a 512-byte maximum packet.
Fixes: 89a453d4a5 ("uas-uas: usb3 streams")
Reported-by: Benjamin David Lunt <fys@fysnet.net>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20200117073716.31335-1-kraxel@redhat.com
We extend QEMU RISC-V virt machine by adding Goldfish RTC device
to it. This will allow Guest Linux to sync it's local date/time
with Host date/time via RTC device.
Signed-off-by: Anup Patel <anup.patel@wdc.com>
Reviewed-by: Palmer Dabbelt <palmer@sifive.com>
Acked-by: Palmer Dabbelt <palmer@sifive.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
This patch adds model for Google Goldfish virtual platform RTC device.
We will be adding Goldfish RTC device to the QEMU RISC-V virt machine
for providing real date-time to Guest Linux. The corresponding Linux
driver for Goldfish RTC device is already available in upstream Linux.
For now, VM migration support is available but untested for Goldfish RTC
device. It will be hardened in-future when we implement VM migration for
KVM RISC-V.
Signed-off-by: Anup Patel <anup.patel@wdc.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
The SiFive test device found on virt machine can be used by
generic syscon reboot and poweroff drivers available in Linux
kernel.
This patch updates FDT generation in virt machine so that
Linux kernel can probe and use generic syscon drivers.
Signed-off-by: Anup Patel <anup.patel@wdc.com>
Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
9p patches:
- some more protocol sanity checks
- qtest for readdir
- Christian Schoenebeck now official reviewer
# gpg: Signature made Sat 08 Feb 2020 08:38:10 GMT
# gpg: using RSA key B4828BAF943140CEF2A3491071D4D5E5822F73D6
# gpg: Good signature from "Greg Kurz <groug@kaod.org>" [full]
# gpg: aka "Gregory Kurz <gregory.kurz@free.fr>" [full]
# gpg: aka "[jpeg image of size 3330]" [full]
# Primary key fingerprint: B482 8BAF 9431 40CE F2A3 4910 71D4 D5E5 822F 73D6
* remotes/gkurz/tags/9p-next-2020-02-08:
MAINTAINERS: 9pfs: Add myself as reviewer
tests/virtio-9p: added readdir test
hw/9pfs/9p-synth: added directory for readdir test
9pfs: validate count sent by client with T_readdir
9pfs: require msize >= 4096
tests/virtio-9p: add terminating null in v9fs_string_read()
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This will provide the following virtual files by the 9pfs
synth driver:
- /ReadDirDir/ReadDirFile99
- /ReadDirDir/ReadDirFile98
...
- /ReadDirDir/ReadDirFile1
- /ReadDirDir/ReadDirFile0
This virtual directory and its virtual 100 files will be
used by the upcoming 9pfs readdir tests.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <5408c28c8de25dd575b745cef63bf785305ccef2.1579567020.git.qemu_oss@crudebyte.com>
Signed-off-by: Greg Kurz <groug@kaod.org>
A good 9p client sends T_readdir with "count" parameter that's sufficiently
smaller than client's initially negotiated msize (maximum message size).
We perform a check for that though to avoid the server to be interrupted
with a "Failed to encode VirtFS reply type 41" transport error message by
bad clients. This count value constraint uses msize - 11, because 11 is the
header size of R_readdir.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <3990d3891e8ae2074709b56449e96ab4b4b93b7d.1579567020.git.qemu_oss@crudebyte.com>
[groug: added comment ]
Signed-off-by: Greg Kurz <groug@kaod.org>
A client establishes a session by sending a Tversion request along with a
'msize' parameter which client uses to suggest server a maximum message
size ever to be used for communication (for both requests and replies)
between client and server during that session. If client suggests a 'msize'
smaller than 4096 then deny session by server immediately with an error
response (Rlerror for "9P2000.L" clients or Rerror for "9P2000.u" clients)
instead of replying with Rversion.
So far any msize submitted by client with Tversion was simply accepted by
server without any check. Introduction of some minimum msize makes sense,
because e.g. a msize < 7 would not allow any subsequent 9p operation at
all, because 7 is the size of the header section common by all 9p message
types.
A substantial higher value of 4096 was chosen though to prevent potential
issues with some message types. E.g. Rreadlink may yield up to a size of
PATH_MAX which is usually 4096, and like almost all 9p message types,
Rreadlink is not allowed to be truncated by the 9p protocol. This chosen
size also prevents a similar issue with Rreaddir responses (provided client
always sends adequate 'count' parameter with Treaddir), because even though
directory entries retrieval may be split up over several T/Rreaddir
messages; a Rreaddir response must not truncate individual directory entries
though. So msize should be large enough to return at least one directory
entry with the longest possible file name supported by host. Most file
systems support a max. file name length of 255. Largest known file name
lenght limit would be currently ReiserFS with max. 4032 bytes, which is
also covered by this min. msize value because 4032 + 35 < 4096.
Furthermore 4096 is already the minimum msize of the Linux kernel's 9pfs
client.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <8ceecb7fb9fdbeabbe55c04339349a36929fb8e3.1579567019.git.qemu_oss@crudebyte.com>
Signed-off-by: Greg Kurz <groug@kaod.org>
Commit ed65fd1a27 ("virtio-blk: switch off scsi-passthrough by
default") changed the default value of the 'scsi' property of
virtio-blk, which is only available on Linux hosts. It also added
an unconditional compat entry for 2.4 or earlier machines.
Trying to set this property on a pre-2.5 machine on OSX, we get:
Unexpected error in object_property_find() at qom/object.c:1201:
qemu-system-x86_64: -device virtio-blk-pci,id=scsi0,drive=drive0: can't apply global virtio-blk-device.scsi=true: Property '.scsi' not found
Fix this error by marking the property optional.
Fixes: ed65fd1a27 ("virtio-blk: switch off scsi-passthrough by default")
Suggested-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-id: 20200207001404.1739-1-philmd@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
TD (two dimensions) DMA mode did not work, because the xlen variable
has not been re-initialized before each additional ylen run through
in bcm2835_dma_update(). Fix it.
Signed-off-by: Rene Stange <rsta2@o2online.de>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
