1. 16 8月, 2019 2 次提交
  2. 12 6月, 2019 1 次提交
  3. 08 3月, 2019 1 次提交
  4. 07 1月, 2019 1 次提交
    • P
      hw/arm/allwinner-a10: Add the 'A' SRAM and the SRAM controller · ead07aa4
      Philippe Mathieu-Daudé 提交于
      From the "A10 User Manual V1.20" p.29: "3.2. Memory Mapping" and:
      
       7. System Control
        7.1. Overview
      
        A10 embeds a high-speed SRAM which has been split into five segments.
        See detailed memory mapping in following table:
      
        Area          Address        Size (Bytes)
         A1    0x00000000-0x00003FFF 16K
         A2    0x00004000-0x00007FFF 16K
         A3    0x00008000-0x0000B3FF 13K
         A4    0x0000B400-0x0000BFFF  3K
      
      Since for emulation purpose we don't need the segmentations, we simply define
      the 'A' area as a single 48KB SRAM.
      
      We don't implement the following others areas:
      - 'B': 'Secure RAM' (64K),
      - 'C': Debug/ISP SRAM
      - 'D': USB SRAM
      
      (qemu) info mtree
      address-space: memory
        0000000000000000-ffffffffffffffff (prio 0, i/o): system
          0000000000000000-000000000000bfff (prio 0, ram): sram A
          0000000001c00000-0000000001c00fff (prio -1000, i/o): a10-sram-ctrl
          0000000001c0b000-0000000001c0bfff (prio 0, i/o): aw_emac
          0000000001c18000-0000000001c18fff (prio 0, i/o): ahci
            0000000001c18080-0000000001c180ff (prio 0, i/o): allwinner-ahci
          0000000001c20400-0000000001c207ff (prio 0, i/o): allwinner-a10-pic
          0000000001c20c00-0000000001c20fff (prio 0, i/o): allwinner-A10-timer
          0000000001c28000-0000000001c2801f (prio 0, i/o): serial
          0000000040000000-0000000047ffffff (prio 0, ram): cubieboard.ram
      Reported-by: NCharlie Smurthwaite <charlie@atech.media>
      Tested-by: NCharlie Smurthwaite <charlie@atech.media>
      Signed-off-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
      Message-id: 20190104142921.878-1-f4bug@amsat.org
      Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      ead07aa4
  5. 17 7月, 2018 1 次提交
  6. 26 4月, 2018 1 次提交
  7. 10 4月, 2018 1 次提交
    • T
      hw/arm/allwinner-a10: Do not use nd_table in instance_init function · 8aabc543
      Thomas Huth 提交于
      The instance_init function of a device can be called at any time, even
      if the device is not going to be used (i.e. not going to be realized).
      So a instance_init function must not do things that could cause QEMU
      to exit, like calling qemu_check_nic_model(&nd_table[0], ...) for example.
      But this is what the instance_init function of the allwinner-a10 device
      is currently doing - and this causes QEMU to quit unexpectedly when
      you run the 'device-list-properties' QMP command for example:
      
      $ echo "{'execute':'qmp_capabilities'}"\
             "{'execute':'device-list-properties',"\
             " 'arguments':{'typename':'allwinner-a10'}}" \
             | arm-softmmu/qemu-system-arm -M mps2-an505,accel=qtest -qmp stdio
      {"QMP": {"version": {"qemu": {"micro": 91, "minor": 11, "major": 2},
       "package": "build-all"}, "capabilities": []}}
      {"return": {}}
      Unsupported NIC model: lan9118
      
      ... and QEMU quits after printing the last line (which should not happen
      just because of running 'device-list-properties' here).
      
      And with the cubieboard, this even causes QEMU to abort():
      
      $ echo "{'execute':'qmp_capabilities'}"\
             "{'execute':'device-list-properties',"\
             " 'arguments':{'typename':'allwinner-a10'}}" \
             | arm-softmmu/qemu-system-arm -M cubieboard,accel=qtest -qmp stdio
      {"QMP": {"version": {"qemu": {"micro": 91, "minor": 11, "major": 2},
       "package": "build-all"}, "capabilities": []}}
      {"return": {}}
      Unexpected error in error_set_from_qdev_prop_error() at hw/core/qdev-properties.c:1095:
      Property 'allwinner-emac.netdev' can't take value 'hub0port0', it's in use
      Aborted (core dumped)
      
      To fix the problem we've got to move the offending code to the realize
      function instead.
      Signed-off-by: NThomas Huth <thuth@redhat.com>
      Message-id: 1522862420-7484-1-git-send-email-thuth@redhat.com
      Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      8aabc543
  8. 07 9月, 2017 1 次提交
  9. 20 4月, 2017 1 次提交
  10. 23 3月, 2016 2 次提交
    • P
      hw: explicitly include qemu-common.h and cpu.h · 4771d756
      Paolo Bonzini 提交于
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      4771d756
    • M
      include/qemu/osdep.h: Don't include qapi/error.h · da34e65c
      Markus Armbruster 提交于
      Commit 57cb38b3 included qapi/error.h into qemu/osdep.h to get the
      Error typedef.  Since then, we've moved to include qemu/osdep.h
      everywhere.  Its file comment explains: "To avoid getting into
      possible circular include dependencies, this file should not include
      any other QEMU headers, with the exceptions of config-host.h,
      compiler.h, os-posix.h and os-win32.h, all of which are doing a
      similar job to this file and are under similar constraints."
      qapi/error.h doesn't do a similar job, and it doesn't adhere to
      similar constraints: it includes qapi-types.h.  That's in excess of
      100KiB of crap most .c files don't actually need.
      
      Add the typedef to qemu/typedefs.h, and include that instead of
      qapi/error.h.  Include qapi/error.h in .c files that need it and don't
      get it now.  Include qapi-types.h in qom/object.h for uint16List.
      
      Update scripts/clean-includes accordingly.  Update it further to match
      reality: replace config.h by config-target.h, add sysemu/os-posix.h,
      sysemu/os-win32.h.  Update the list of includes in the qemu/osdep.h
      comment quoted above similarly.
      
      This reduces the number of objects depending on qapi/error.h from "all
      of them" to less than a third.  Unfortunately, the number depending on
      qapi-types.h shrinks only a little.  More work is needed for that one.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      [Fix compilation without the spice devel packages. - Paolo]
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      da34e65c
  11. 19 1月, 2016 1 次提交
  12. 07 11月, 2015 1 次提交
  13. 09 10月, 2015 1 次提交
    • M
      qdev: Protect device-list-properties against broken devices · 4c315c27
      Markus Armbruster 提交于
      Several devices don't survive object_unref(object_new(T)): they crash
      or hang during cleanup, or they leave dangling pointers behind.
      
      This breaks at least device-list-properties, because
      qmp_device_list_properties() needs to create a device to find its
      properties.  Broken in commit f4eb32b5 "qmp: show QOM properties in
      device-list-properties", v2.1.  Example reproducer:
      
          $ qemu-system-aarch64 -nodefaults -display none -machine none -S -qmp stdio
          {"QMP": {"version": {"qemu": {"micro": 50, "minor": 4, "major": 2}, "package": ""}, "capabilities": []}}
          { "execute": "qmp_capabilities" }
          {"return": {}}
          { "execute": "device-list-properties", "arguments": { "typename": "pxa2xx-pcmcia" } }
          qemu-system-aarch64: /home/armbru/work/qemu/memory.c:1307: memory_region_finalize: Assertion `((&mr->subregions)->tqh_first == ((void *)0))' failed.
          Aborted (core dumped)
          [Exit 134 (SIGABRT)]
      
      Unfortunately, I can't fix the problems in these devices right now.
      Instead, add DeviceClass member cannot_destroy_with_object_finalize_yet
      to mark them:
      
      * Hang during cleanup (didn't debug, so I can't say why):
        "realview_pci", "versatile_pci".
      
      * Dangling pointer in cpus: most CPUs, plus "allwinner-a10", "digic",
        "fsl,imx25", "fsl,imx31", "xlnx,zynqmp", because they create such
        CPUs
      
      * Assert kvm_enabled(): "host-x86_64-cpu", host-i386-cpu",
        "host-powerpc64-cpu", "host-embedded-powerpc-cpu",
        "host-powerpc-cpu" (the powerpc ones can't currently reach the
        assertion, because the CPUs are only registered when KVM is enabled,
        but the assertion is arguably in the wrong place all the same)
      
      Make qmp_device_list_properties() fail cleanly when the device is so
      marked.  This improves device-list-properties from "crashes, hangs or
      leaves dangling pointers behind" to "fails".  Not a complete fix, just
      a better-than-nothing work-around.  In the above reproducer,
      device-list-properties now fails with "Can't list properties of device
      'pxa2xx-pcmcia'".
      
      This also protects -device FOO,help, which uses the same machinery
      since commit ef523587 "qdev-monitor: include QOM properties in -device
      FOO, help output", v2.2.  Example reproducer:
      
          $ qemu-system-aarch64 -machine none -device pxa2xx-pcmcia,help
      
      Before:
      
          qemu-system-aarch64: .../memory.c:1307: memory_region_finalize: Assertion `((&mr->subregions)->tqh_first == ((void *)0))' failed.
      
      After:
      
          Can't list properties of device 'pxa2xx-pcmcia'
      
      Cc: "Andreas Färber" <afaerber@suse.de>
      Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
      Cc: Alexander Graf <agraf@suse.de>
      Cc: Anthony Green <green@moxielogic.com>
      Cc: Aurelien Jarno <aurelien@aurel32.net>
      Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
      Cc: Blue Swirl <blauwirbel@gmail.com>
      Cc: Eduardo Habkost <ehabkost@redhat.com>
      Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
      Cc: Jia Liu <proljc@gmail.com>
      Cc: Leon Alrae <leon.alrae@imgtec.com>
      Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
      Cc: Max Filippov <jcmvbkbc@gmail.com>
      Cc: Michael Walle <michael@walle.cc>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Peter Maydell <peter.maydell@linaro.org>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: qemu-ppc@nongnu.org
      Cc: qemu-stable@nongnu.org
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
      Message-Id: <1443689999-12182-10-git-send-email-armbru@redhat.com>
      4c315c27
  14. 02 4月, 2015 2 次提交
    • M
      hw: Mark device misusing nd_table[] FIXME · 19f33f16
      Markus Armbruster 提交于
      NICs defined with -net nic are for board initialization to wire up.
      Board code examines nd_table[] to find them, and creates devices with
      their qdev NIC properties set accordingly.
      
      Except "allwinner-a10" goes on a fishing expedition for NIC
      configuration instead of exposing the usual NIC properties for board
      code to set: it uses nd_table[0] in its instance_init() method.
      
      Picking up the first -net nic option's configuration that way works
      when the device is created by board code.  But it's inappropriate for
      -device and device_add.  Not only is it inconsistent with how the
      other block device models work (they get their configuration from
      properties "mac", "vlan", "netdev"), it breaks when nd_table[0] has
      been picked up by the board or a previous -device / device_add
      already.
      
      Example:
      
          $ qemu-system-arm -S -M cubieboard -device allwinner-a10
          qemu-system-arm: -device allwinner-a10: Property 'allwinner-emac.netdev' can't take value 'hub0port0', it's in use
          Aborted (core dumped)
      
      It also breaks in other entertaining ways:
      
          $ qemu-system-arm -M highbank -device allwinner-a10
          qemu-system-arm: -device allwinner-a10: Unsupported NIC model: xgmac
          $ qemu-system-arm -M highbank -net nic,model=allwinner-emac -device allwinner-a10
          qemu-system-arm: Unsupported NIC model: allwinner-emac
      
      Mark the mistake with a FIXME comment.
      
      Cc: Li Guang <lig.fnst@cn.fujitsu.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      19f33f16
    • M
      hw: Mark devices picking up char backends actively FIXME · d71b22bb
      Markus Armbruster 提交于
      Character devices defined with -serial and -parallel are for board
      initialization to wire up.  Board code examines serial_hds[] and
      parallel_hds[] to find them, and creates devices with their qdev
      chardev properties set accordingly.
      
      Except a few devices go on a fishing expedition for a suitable backend
      instead of exposing a chardev property for board code to set: they use
      serial_hds[] (often via qemu_char_get_next_serial()) or parallel_hds[]
      in their realize() or init() method to connect to a backend.
      
      Picking up backends that way works when the devices are created by
      board code.  But it's inappropriate for -device or device_add.  Not
      only is it inconsistent with how the other characrer device models
      work (they connect to a backend explicitly identified by a "chardev"
      property), it breaks when the backend has been picked up by the board
      or a previous -device / device_add already.
      
      Example:
      
          $ qemu-system-ppc64 -M bamboo -S -device i82378 -device pc87312 -device pc87312
          qemu-system-ppc64: -device pc87312: Property 'isa-parallel.chardev' can't take value 'parallel0', it's in use
      
      Mark them with suitable FIXME comments.
      
      Cc: Li Guang <lig.fnst@cn.fujitsu.com>
      Cc: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
      Cc: Antony Pavlov <antonynpavlov@gmail.com>
      Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
      Cc: Michael Walle <michael@walle.cc>
      Cc: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
      Cc: "Andreas Färber" <andreas.faerber@web.de>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      d71b22bb
  15. 08 2月, 2014 1 次提交
  16. 18 12月, 2013 1 次提交