diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/generic-loader.txt | 92 | ||||
| -rw-r--r-- | docs/system/arm/aspeed.rst | 16 | ||||
| -rw-r--r-- | docs/system/deprecated.rst | 8 | ||||
| -rw-r--r-- | docs/system/generic-loader.rst | 117 | ||||
| -rw-r--r-- | docs/system/guest-loader.rst | 54 | ||||
| -rw-r--r-- | docs/system/index.rst | 2 | ||||
| -rw-r--r-- | docs/system/ppc/embedded.rst | 10 | ||||
| -rw-r--r-- | docs/system/ppc/powermac.rst | 34 | ||||
| -rw-r--r-- | docs/system/ppc/powernv.rst | 193 | ||||
| -rw-r--r-- | docs/system/ppc/prep.rst | 18 | ||||
| -rw-r--r-- | docs/system/ppc/pseries.rst | 12 | ||||
| -rw-r--r-- | docs/system/quickstart.rst | 8 | ||||
| -rw-r--r-- | docs/system/target-ppc.rst | 53 | ||||
| -rw-r--r-- | docs/system/targets.rst | 2 |
14 files changed, 483 insertions, 136 deletions
diff --git a/docs/generic-loader.txt b/docs/generic-loader.txt deleted file mode 100644 index a9603a2af7..0000000000 --- a/docs/generic-loader.txt +++ /dev/null @@ -1,92 +0,0 @@ -Copyright (c) 2016 Xilinx Inc. - -This work is licensed under the terms of the GNU GPL, version 2 or later. See -the COPYING file in the top-level directory. - - -The 'loader' device allows the user to load multiple images or values into -QEMU at startup. - -Loading Data into Memory Values -------------------------------- -The loader device allows memory values to be set from the command line. This -can be done by following the syntax below: - - -device loader,addr=<addr>,data=<data>,data-len=<data-len> - [,data-be=<data-be>][,cpu-num=<cpu-num>] - - <addr> - The address to store the data in. - <data> - The value to be written to the address. The maximum size of - the data is 8 bytes. - <data-len> - The length of the data in bytes. This argument must be - included if the data argument is. - <data-be> - Set to true if the data to be stored on the guest should be - written as big endian data. The default is to write little - endian data. - <cpu-num> - The number of the CPU's address space where the data should - be loaded. If not specified the address space of the first - CPU is used. - -All values are parsed using the standard QemuOps parsing. This allows the user -to specify any values in any format supported. By default the values -will be parsed as decimal. To use hex values the user should prefix the number -with a '0x'. - -An example of loading value 0x8000000e to address 0xfd1a0104 is: - -device loader,addr=0xfd1a0104,data=0x8000000e,data-len=4 - -Setting a CPU's Program Counter -------------------------------- -The loader device allows the CPU's PC to be set from the command line. This -can be done by following the syntax below: - - -device loader,addr=<addr>,cpu-num=<cpu-num> - - <addr> - The value to use as the CPU's PC. - <cpu-num> - The number of the CPU whose PC should be set to the - specified value. - -All values are parsed using the standard QemuOps parsing. This allows the user -to specify any values in any format supported. By default the values -will be parsed as decimal. To use hex values the user should prefix the number -with a '0x'. - -An example of setting CPU 0's PC to 0x8000 is: - -device loader,addr=0x8000,cpu-num=0 - -Loading Files -------------- -The loader device also allows files to be loaded into memory. It can load ELF, -U-Boot, and Intel HEX executable formats as well as raw images. The syntax is -shown below: - - -device loader,file=<file>[,addr=<addr>][,cpu-num=<cpu-num>][,force-raw=<raw>] - - <file> - A file to be loaded into memory - <addr> - The memory address where the file should be loaded. This is - required for raw images and ignored for non-raw files. - <cpu-num> - This specifies the CPU that should be used. This is an - optional argument and will cause the CPU's PC to be set to - the memory address where the raw file is loaded or the entry - point specified in the executable format header. This option - should only be used for the boot image. - This will also cause the image to be written to the specified - CPU's address space. If not specified, the default is CPU 0. - <force-raw> - Setting force-raw=on forces the file to be treated as a raw - image. This can be used to load supported executable formats - as if they were raw. - -All values are parsed using the standard QemuOps parsing. This allows the user -to specify any values in any format supported. By default the values -will be parsed as decimal. To use hex values the user should prefix the number -with a '0x'. - -An example of loading an ELF file which CPU0 will boot is shown below: - -device loader,file=./images/boot.elf,cpu-num=0 - -Restrictions and ToDos ----------------------- - - At the moment it is just assumed that if you specify a cpu-num then you - want to set the PC as well. This might not always be the case. In future - the internal state 'set_pc' (which exists in the generic loader now) should - be exposed to the user so that they can choose if the PC is set or not. diff --git a/docs/system/arm/aspeed.rst b/docs/system/arm/aspeed.rst index 690bada784..d1fb8f25b3 100644 --- a/docs/system/arm/aspeed.rst +++ b/docs/system/arm/aspeed.rst @@ -48,6 +48,7 @@ Supported devices * UART * Ethernet controllers * Front LEDs (PCA9552 on I2C bus) + * LPC Peripheral Controller (a subset of subdevices are supported) Missing devices @@ -56,7 +57,6 @@ Missing devices * Coprocessor support * ADC (out of tree implementation) * PWM and Fan Controller - * LPC Bus Controller * Slave GPIO Controller * Super I/O Controller * Hash/Crypto Engine @@ -72,18 +72,22 @@ Missing devices Boot options ------------ -The Aspeed machines can be started using the -kernel option to load a -Linux kernel or from a firmware image which can be downloaded from the -OpenPOWER jenkins : +The Aspeed machines can be started using the ``-kernel`` option to +load a Linux kernel or from a firmware. Images can be downloaded from +the OpenBMC jenkins : - https://openpower.xyz/ + https://jenkins.openbmc.org/job/ci-openbmc/lastSuccessfulBuild/distro=ubuntu,label=docker-builder + +or directly from the OpenBMC GitHub release repository : + + https://github.com/openbmc/openbmc/releases The image should be attached as an MTD drive. Run : .. code-block:: bash $ qemu-system-arm -M romulus-bmc -nic user \ - -drive file=flash-romulus,format=raw,if=mtd -nographic + -drive file=obmc-phosphor-image-romulus.static.mtd,format=raw,if=mtd -nographic Options specific to Aspeed machines are : diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst index 241b28a521..5e3a31c123 100644 --- a/docs/system/deprecated.rst +++ b/docs/system/deprecated.rst @@ -166,6 +166,14 @@ Using ``-M kernel-irqchip=off`` with x86 machine types that include a local APIC is deprecated. The ``split`` setting is supported, as is using ``-M kernel-irqchip=off`` with the ISA PC machine type. +hexadecimal sizes with scaling multipliers (since 6.0) +'''''''''''''''''''''''''''''''''''''''''''''''''''''' + +Input parameters that take a size value should only use a size suffix +(such as 'k' or 'M') when the base is written in decimal, and not when +the value is hexadecimal. That is, '0x20M' is deprecated, and should +be written either as '32M' or as '0x2000000'. + QEMU Machine Protocol (QMP) commands ------------------------------------ diff --git a/docs/system/generic-loader.rst b/docs/system/generic-loader.rst new file mode 100644 index 0000000000..6bf8a4eb48 --- /dev/null +++ b/docs/system/generic-loader.rst @@ -0,0 +1,117 @@ +.. + Copyright (c) 2016, Xilinx Inc. + +This work is licensed under the terms of the GNU GPL, version 2 or later. See +the COPYING file in the top-level directory. + +Generic Loader +-------------- + +The 'loader' device allows the user to load multiple images or values into +QEMU at startup. + +Loading Data into Memory Values +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +The loader device allows memory values to be set from the command line. This +can be done by following the syntax below:: + + -device loader,addr=<addr>,data=<data>,data-len=<data-len> \ + [,data-be=<data-be>][,cpu-num=<cpu-num>] + +``<addr>`` + The address to store the data in. + +``<data>`` + The value to be written to the address. The maximum size of the data + is 8 bytes. + +``<data-len>`` + The length of the data in bytes. This argument must be included if + the data argument is. + +``<data-be>`` + Set to true if the data to be stored on the guest should be written + as big endian data. The default is to write little endian data. + +``<cpu-num>`` + The number of the CPU's address space where the data should be + loaded. If not specified the address space of the first CPU is used. + +All values are parsed using the standard QemuOps parsing. This allows the user +to specify any values in any format supported. By default the values +will be parsed as decimal. To use hex values the user should prefix the number +with a '0x'. + +An example of loading value 0x8000000e to address 0xfd1a0104 is:: + + -device loader,addr=0xfd1a0104,data=0x8000000e,data-len=4 + +Setting a CPU's Program Counter +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The loader device allows the CPU's PC to be set from the command line. This +can be done by following the syntax below:: + + -device loader,addr=<addr>,cpu-num=<cpu-num> + +``<addr>`` + The value to use as the CPU's PC. + +``<cpu-num>`` + The number of the CPU whose PC should be set to the specified value. + +All values are parsed using the standard QemuOpts parsing. This allows the user +to specify any values in any format supported. By default the values +will be parsed as decimal. To use hex values the user should prefix the number +with a '0x'. + +An example of setting CPU 0's PC to 0x8000 is:: + + -device loader,addr=0x8000,cpu-num=0 + +Loading Files +^^^^^^^^^^^^^ + +The loader device also allows files to be loaded into memory. It can load ELF, +U-Boot, and Intel HEX executable formats as well as raw images. The syntax is +shown below: + + -device loader,file=<file>[,addr=<addr>][,cpu-num=<cpu-num>][,force-raw=<raw>] + +``<file>`` + A file to be loaded into memory + +``<addr>`` + The memory address where the file should be loaded. This is required + for raw images and ignored for non-raw files. + +``<cpu-num>`` + This specifies the CPU that should be used. This is an + optional argument and will cause the CPU's PC to be set to the + memory address where the raw file is loaded or the entry point + specified in the executable format header. This option should only + be used for the boot image. This will also cause the image to be + written to the specified CPU's address space. If not specified, the + default is CPU 0. <force-raw> - Setting force-raw=on forces the file + to be treated as a raw image. This can be used to load supported + executable formats as if they were raw. + +All values are parsed using the standard QemuOpts parsing. This allows the user +to specify any values in any format supported. By default the values +will be parsed as decimal. To use hex values the user should prefix the number +with a '0x'. + +An example of loading an ELF file which CPU0 will boot is shown below:: + + -device loader,file=./images/boot.elf,cpu-num=0 + +Restrictions and ToDos +^^^^^^^^^^^^^^^^^^^^^^ + +At the moment it is just assumed that if you specify a cpu-num then +you want to set the PC as well. This might not always be the case. In +future the internal state 'set_pc' (which exists in the generic loader +now) should be exposed to the user so that they can choose if the PC +is set or not. + + diff --git a/docs/system/guest-loader.rst b/docs/system/guest-loader.rst new file mode 100644 index 0000000000..37d03cbd89 --- /dev/null +++ b/docs/system/guest-loader.rst @@ -0,0 +1,54 @@ +.. + Copyright (c) 2020, Linaro + +Guest Loader +------------ + +The guest loader is similar to the `generic-loader` although it is +aimed at a particular use case of loading hypervisor guests. This is +useful for debugging hypervisors without having to jump through the +hoops of firmware and boot-loaders. + +The guest loader does two things: + + - load blobs (kernels and initial ram disks) into memory + - sets platform FDT data so hypervisors can find and boot them + +This is what is typically done by a boot-loader like grub using it's +multi-boot capability. A typical example would look like: + +.. parsed-literal:: + + |qemu_system| -kernel ~/xen.git/xen/xen \ + -append "dom0_mem=1G,max:1G loglvl=all guest_loglvl=all" \ + -device guest-loader,addr=0x42000000,kernel=Image,bootargs="root=/dev/sda2 ro console=hvc0 earlyprintk=xen" \ + -device guest-loader,addr=0x47000000,initrd=rootfs.cpio + +In the above example the Xen hypervisor is loaded by the -kernel +parameter and passed it's boot arguments via -append. The Dom0 guest +is loaded into the areas of memory. Each blob will get +`/chosen/module@<addr>` entry in the FDT to indicate it's location and +size. Additional information can be passed with by using additional +arguments. + +Currently the only supported machines which use FDT data to boot are +the ARM and RiscV `virt` machines. + +Arguments +^^^^^^^^^ + +The full syntax of the guest-loader is:: + + -device guest-loader,addr=<addr>[,kernel=<file>,[bootargs=<args>]][,initrd=<file>] + +``addr=<addr>`` + This is mandatory and indicates the start address of the blob. + +``kernel|initrd=<file>`` + Indicates the filename of the kernel or initrd blob. Both blobs will + have the "multiboot,module" compatibility string as well as + "multiboot,kernel" or "multiboot,ramdisk" as appropriate. + +``bootargs=<args>`` + This is an optional field for kernel blobs which will pass command + like via the `/chosen/module@<addr>/bootargs` node. diff --git a/docs/system/index.rst b/docs/system/index.rst index 625b494372..6ad9c93806 100644 --- a/docs/system/index.rst +++ b/docs/system/index.rst @@ -25,6 +25,8 @@ Contents: usb ivshmem linuxboot + generic-loader + guest-loader vnc-security tls gdb diff --git a/docs/system/ppc/embedded.rst b/docs/system/ppc/embedded.rst new file mode 100644 index 0000000000..cfffbda24d --- /dev/null +++ b/docs/system/ppc/embedded.rst @@ -0,0 +1,10 @@ +Embedded family boards +====================== + +- ``bamboo`` bamboo +- ``mpc8544ds`` mpc8544ds +- ``ppce500`` generic paravirt e500 platform +- ``ref405ep`` ref405ep +- ``sam460ex`` aCube Sam460ex +- ``taihu`` taihu +- ``virtex-ml507`` Xilinx Virtex ML507 reference design diff --git a/docs/system/ppc/powermac.rst b/docs/system/ppc/powermac.rst new file mode 100644 index 0000000000..04334ba210 --- /dev/null +++ b/docs/system/ppc/powermac.rst @@ -0,0 +1,34 @@ +PowerMac family boards (``g3beige``, ``mac99``) +================================================================== + +Use the executable ``qemu-system-ppc`` to simulate a complete PowerMac +PowerPC system. + +- ``g3beige`` Heathrow based PowerMAC +- ``mac99`` Mac99 based PowerMAC + +Supported devices +----------------- + +QEMU emulates the following PowerMac peripherals: + + * UniNorth or Grackle PCI Bridge + * PCI VGA compatible card with VESA Bochs Extensions + * 2 PMAC IDE interfaces with hard disk and CD-ROM support + * NE2000 PCI adapters + * Non Volatile RAM + * VIA-CUDA with ADB keyboard and mouse. + + +Missing devices +--------------- + + * To be identified + +Firmware +-------- + +Since version 0.9.1, QEMU uses OpenBIOS https://www.openbios.org/ for +the g3beige and mac99 PowerMac and the 40p machines. OpenBIOS is a free +(GPL v2) portable firmware implementation. The goal is to implement a +100% IEEE 1275-1994 (referred to as Open Firmware) compliant firmware. diff --git a/docs/system/ppc/powernv.rst b/docs/system/ppc/powernv.rst new file mode 100644 index 0000000000..43c58bc32e --- /dev/null +++ b/docs/system/ppc/powernv.rst @@ -0,0 +1,193 @@ +PowerNV family boards (``powernv8``, ``powernv9``) +================================================================== + +PowerNV (as Non-Virtualized) is the "baremetal" platform using the +OPAL firmware. It runs Linux on IBM and OpenPOWER systems and it can +be used as an hypervisor OS, running KVM guests, or simply as a host +OS. + +The PowerNV QEMU machine tries to emulate a PowerNV system at the +level of the skiboot firmware, which loads the OS and provides some +runtime services. Power Systems have a lower firmware (HostBoot) that +does low level system initialization, like DRAM training. This is +beyond the scope of what QEMU addresses today. + +Supported devices +----------------- + + * Multi processor support for POWER8, POWER8NVL and POWER9. + * XSCOM, serial communication sideband bus to configure chiplets + * Simple LPC Controller + * Processor Service Interface (PSI) Controller + * Interrupt Controller, XICS (POWER8) and XIVE (POWER9) + * POWER8 PHB3 PCIe Host bridge and POWER9 PHB4 PCIe Host bridge + * Simple OCC is an on-chip microcontroller used for power management + tasks + * iBT device to handle BMC communication, with the internal BMC + simulator provided by QEMU or an external BMC such as an Aspeed + QEMU machine. + * PNOR containing the different firmware partitions. + +Missing devices +--------------- + +A lot is missing, among which : + + * POWER10 processor + * XIVE2 (POWER10) interrupt controller + * I2C controllers (yet to be merged) + * NPU/NPU2/NPU3 controllers + * EEH support for PCIe Host bridge controllers + * NX controller + * VAS controller + * chipTOD (Time Of Day) + * Self Boot Engine (SBE). + * FSI bus + +Firmware +-------- + +The OPAL firmware (OpenPower Abstraction Layer) for OpenPower systems +includes the runtime services `skiboot` and the bootloader kernel and +initramfs `skiroot`. Source code can be found on GitHub: + + https://github.com/open-power. + +Prebuilt images of `skiboot` and `skiboot` are made available on the `OpenPOWER <https://openpower.xyz/job/openpower/job/openpower-op-build/>`__ site. To boot a POWER9 machine, use the `witherspoon <https://openpower.xyz/job/openpower/job/openpower-op-build/label=slave,target=witherspoon/lastSuccessfulBuild/>`__ images. For POWER8, use +the `palmetto <https://openpower.xyz/job/openpower/job/openpower-op-build/label=slave,target=palmetto/lastSuccessfulBuild/>`__ images. + +QEMU includes a prebuilt image of `skiboot` which is updated when a +more recent version is required by the models. + +Boot options +------------ + +Here is a simple setup with one e1000e NIC : + +.. code-block:: bash + + $ qemu-system-ppc64 -m 2G -machine powernv9 -smp 2,cores=2,threads=1 \ + -accel tcg,thread=single \ + -device e1000e,netdev=net0,mac=C0:FF:EE:00:00:02,bus=pcie.0,addr=0x0 \ + -netdev user,id=net0,hostfwd=::20022-:22,hostname=pnv \ + -kernel ./zImage.epapr \ + -initrd ./rootfs.cpio.xz \ + -nographic + +and a SATA disk : + +.. code-block:: bash + + -device ich9-ahci,id=sata0,bus=pcie.1,addr=0x0 \ + -drive file=./ubuntu-ppc64le.qcow2,if=none,id=drive0,format=qcow2,cache=none \ + -device ide-hd,bus=sata0.0,unit=0,drive=drive0,id=ide,bootindex=1 \ + +Complex PCIe configuration +~~~~~~~~~~~~~~~~~~~~~~~~~~ +Six PHBs are defined per chip (POWER9) but no default PCI layout is +provided (to be compatible with libvirt). One PCI device can be added +on any of the available PCIe slots using command line options such as: + +.. code-block:: bash + + -device e1000e,netdev=net0,mac=C0:FF:EE:00:00:02,bus=pcie.0,addr=0x0 + -netdev bridge,id=net0,helper=/usr/libexec/qemu-bridge-helper,br=virbr0,id=hostnet0 + + -device megasas,id=scsi0,bus=pcie.0,addr=0x0 + -drive file=./ubuntu-ppc64le.qcow2,if=none,id=drive-scsi0-0-0-0,format=qcow2,cache=none + -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=2 + +Here is a full example with two different storage controllers on +different PHBs, each with a disk, the second PHB is empty : + +.. code-block:: bash + + $ qemu-system-ppc64 -m 2G -machine powernv9 -smp 2,cores=2,threads=1 -accel tcg,thread=single \ + -kernel ./zImage.epapr -initrd ./rootfs.cpio.xz -bios ./skiboot.lid \ + \ + -device megasas,id=scsi0,bus=pcie.0,addr=0x0 \ + -drive file=./rhel7-ppc64le.qcow2,if=none,id=drive-scsi0-0-0-0,format=qcow2,cache=none \ + -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=2 \ + \ + -device pcie-pci-bridge,id=bridge1,bus=pcie.1,addr=0x0 \ + \ + -device ich9-ahci,id=sata0,bus=bridge1,addr=0x1 \ + -drive file=./ubuntu-ppc64le.qcow2,if=none,id=drive0,format=qcow2,cache=none \ + -device ide-hd,bus=sata0.0,unit=0,drive=drive0,id=ide,bootindex=1 \ + -device e1000e,netdev=net0,mac=C0:FF:EE:00:00:02,bus=bridge1,addr=0x2 \ + -netdev bridge,helper=/usr/libexec/qemu-bridge-helper,br=virbr0,id=net0 \ + -device nec-usb-xhci,bus=bridge1,addr=0x7 \ + \ + -serial mon:stdio -nographic + +You can also use VIRTIO devices : + +.. code-block:: bash + + -drive file=./fedora-ppc64le.qcow2,if=none,snapshot=on,id=drive0 \ + -device virtio-blk-pci,drive=drive0,id=blk0,bus=pcie.0 \ + \ + -netdev tap,helper=/usr/lib/qemu/qemu-bridge-helper,br=virbr0,id=netdev0 \ + -device virtio-net-pci,netdev=netdev0,id=net0,bus=pcie.1 \ + \ + -fsdev local,id=fsdev0,path=$HOME,security_model=passthrough \ + -device virtio-9p-pci,fsdev=fsdev0,mount_tag=host,bus=pcie.2 + +Multi sockets +~~~~~~~~~~~~~ + +The number of sockets is deduced from the number of CPUs and the +number of cores. ``-smp 2,cores=1`` will define a machine with 2 +sockets of 1 core, whereas ``-smp 2,cores=2`` will define a machine +with 1 socket of 2 cores. ``-smp 8,cores=2``, 4 sockets of 2 cores. + +BMC configuration +~~~~~~~~~~~~~~~~~ + +OpenPOWER systems negotiate the shutdown and reboot with their +BMC. The QEMU PowerNV machine embeds an IPMI BMC simulator using the +iBT interface and should offer the same power features. + +If you want to define your own BMC, use ``-nodefaults`` and specify +one on the command line : + +.. code-block:: bash + + -device ipmi-bmc-sim,id=bmc0 -device isa-ipmi-bt,bmc=bmc0,irq=10 + +The files `palmetto-SDR.bin <http://www.kaod.org/qemu/powernv/palmetto-SDR.bin>`__ +and `palmetto-FRU.bin <http://www.kaod.org/qemu/powernv/palmetto-FRU.bin>`__ +define a Sensor Data Record repository and a Field Replaceable Unit +inventory for a palmetto BMC. They can be used to extend the QEMU BMC +simulator. + +.. code-block:: bash + + -device ipmi-bmc-sim,sdrfile=./palmetto-SDR.bin,fruareasize=256,frudatafile=./palmetto-FRU.bin,id=bmc0 \ + -device isa-ipmi-bt,bmc=bmc0,irq=10 + +The PowerNV machine can also be run with an external IPMI BMC device +connected to a remote QEMU machine acting as BMC, using these options +: + +.. code-block:: bash + + -chardev socket,id=ipmi0,host=localhost,port=9002,reconnect=10 \ + -device ipmi-bmc-extern,id=bmc0,chardev=ipmi0 \ + -device isa-ipmi-bt,bmc=bmc0,irq=10 \ + -nodefaults + +NVRAM +~~~~~ + +Use a MTD drive to add a PNOR to the machine, and get a NVRAM : + +.. code-block:: bash + + -drive file=./witherspoon.pnor,format=raw,if=mtd + +CAVEATS +------- + + * No support for multiple HW threads (SMT=1). Same as pseries. + * CPU can hang when doing intensive I/Os. Use ``-append powersave=off`` in that case. diff --git a/docs/system/ppc/prep.rst b/docs/system/ppc/prep.rst new file mode 100644 index 0000000000..bd9eb8eabd --- /dev/null +++ b/docs/system/ppc/prep.rst @@ -0,0 +1,18 @@ +Prep machine (``40p``) +================================================================== + +Use the executable ``qemu-system-ppc`` to simulate a complete 40P (PREP) + +Supported devices +----------------- + +QEMU emulates the following 40P (PREP) peripherals: + + * PCI Bridge + * PCI VGA compatible card with VESA Bochs Extensions + * 2 IDE interfaces with hard disk and CD-ROM support + * Floppy disk + * PCnet network adapters + * Serial port + * PREP Non Volatile RAM + * PC compatible keyboard and mouse. diff --git a/docs/system/ppc/pseries.rst b/docs/system/ppc/pseries.rst new file mode 100644 index 0000000000..932d4dd17d --- /dev/null +++ b/docs/system/ppc/pseries.rst @@ -0,0 +1,12 @@ +pSeries family boards (``pseries``) +=================================== + +Supported devices +----------------- + +Missing devices +--------------- + + +Firmware +-------- diff --git a/docs/system/quickstart.rst b/docs/system/quickstart.rst index 3a3acab5e7..681678c86e 100644 --- a/docs/system/quickstart.rst +++ b/docs/system/quickstart.rst @@ -11,3 +11,11 @@ Download and uncompress a PC hard disk image with Linux installed (e.g. |qemu_system| linux.img Linux should boot and give you a prompt. + +Users should be aware the above example elides a lot of the complexity +of setting up a VM with x86_64 specific defaults and assumes the +first non switch argument is a PC compatible disk image with a boot +sector. For a non-x86 system where we emulate a broad range of machine +types, the command lines are generally more explicit in defining the +machine and boot behaviour. You will find more example command lines +in the :ref:`system-targets-ref` section of the manual. diff --git a/docs/system/target-ppc.rst b/docs/system/target-ppc.rst index a2f04c533c..67905b8f2a 100644 --- a/docs/system/target-ppc.rst +++ b/docs/system/target-ppc.rst @@ -3,45 +3,22 @@ PowerPC System emulator ----------------------- -Use the executable ``qemu-system-ppc`` to simulate a complete 40P (PREP) -or PowerMac PowerPC system. +Board-specific documentation +============================ -QEMU emulates the following PowerMac peripherals: +You can get a complete list by running ``qemu-system-ppc64 --machine +help``. -- UniNorth or Grackle PCI Bridge +.. + This table of contents should be kept sorted alphabetically + by the title text of each file, which isn't the same ordering + as an alphabetical sort by filename. -- PCI VGA compatible card with VESA Bochs Extensions +.. toctree:: + :maxdepth: 1 -- 2 PMAC IDE interfaces with hard disk and CD-ROM support - -- NE2000 PCI adapters - -- Non Volatile RAM - -- VIA-CUDA with ADB keyboard and mouse. - -QEMU emulates the following 40P (PREP) peripherals: - -- PCI Bridge - -- PCI VGA compatible card with VESA Bochs Extensions - -- 2 IDE interfaces with hard disk and CD-ROM support - -- Floppy disk - -- PCnet network adapters - -- Serial port - -- PREP Non Volatile RAM - -- PC compatible keyboard and mouse. - -Since version 0.9.1, QEMU uses OpenBIOS https://www.openbios.org/ for -the g3beige and mac99 PowerMac and the 40p machines. OpenBIOS is a free -(GPL v2) portable firmware implementation. The goal is to implement a -100% IEEE 1275-1994 (referred to as Open Firmware) compliant firmware. - -More information is available at -http://perso.magic.fr/l_indien/qemu-ppc/. + ppc/embedded + ppc/powermac + ppc/powernv + ppc/prep + ppc/pseries diff --git a/docs/system/targets.rst b/docs/system/targets.rst index 75ed1087fd..9dcd95dd84 100644 --- a/docs/system/targets.rst +++ b/docs/system/targets.rst @@ -1,3 +1,5 @@ +.. _system-targets-ref: + QEMU System Emulator Targets ============================ |