bwlp/qemu.git/include/hw/arm, branch spice_video_codecs

hw/arm/xlnx-zynqmp: Connect ZynqMP's USB controllers

2022-09-29T16:40:01+00:00

Connect ZynqMP's USB controllers. Signed-off-by: Francisco Iglesias Acked-by: Alistair Francis Message-id: 20220920081517.25401-1-frasse.iglesias@gmail.com Reviewed-by: Peter Maydell Signed-off-by: Peter Maydell

target/arm: Make boards pass base address to armv7m_load_kernel()

2022-09-14T10:19:40+00:00

Currently armv7m_load_kernel() takes the size of the block of memory where it should load the initial guest image, but assumes that it should always load it at address 0. This happens to be true of all our M-profile boards at the moment, but it isn't guaranteed to always be so: M-profile CPUs can be configured (via init-svtor and init-nsvtor, which match equivalent hardware configuration signals) to have the initial vector table at any address, not just zero. (For instance the Teeny board has the boot ROM at address 0x0200_0000.) Add a base address argument to armv7m_load_kernel(), so that callers now pass in both base address and size. All the current callers pass 0, so this is not a behaviour change. Signed-off-by: Peter Maydell Reviewed-by: Richard Henderson Reviewed-by: Philippe Mathieu-Daudé Message-Id: <20220823160417.3858216-3-peter.maydell@linaro.org> Signed-off-by: Richard Henderson

Align Raspberry Pi DMA interrupts with Linux DTS

2022-07-18T12:25:13+00:00

There is nothing in the specs on DMA engine interrupt lines: it should have been in the "BCM2835 ARM Peripherals" datasheet but the appropriate "ARM peripherals interrupt table" (p.113) is nearly empty. All Raspberry Pi models 1-3 (based on bcm2835) have Linux device tree (arch/arm/boot/dts/bcm2835-common.dtsi +25): /* dma channel 11-14 share one irq */ This information is repeated in the driver code (drivers/dma/bcm2835-dma.c +1344): /* * in case of channel >= 11 * use the 11th interrupt and that is shared */ In this patch channels 0--10 and 11--14 are handled separately. Signed-off-by: Andrey Makarov Message-id: 20220716113210.349153-1-andrey.makarov@auriga.com [PMM: fixed checkpatch nits] Reviewed-by: Peter Maydell Signed-off-by: Peter Maydell

aspeed: Make aspeed_board_init_flashes public

2022-07-14T14:24:38+00:00

Signed-off-by: Peter Delevoryas Reviewed-by: Cédric Le Goater Message-Id: <20220705191400.41632-5-peter@pjd.dev> Signed-off-by: Cédric Le Goater

aspeed: Refactor UART init for multi-SoC machines

2022-07-14T14:24:38+00:00

This change moves the code that connects the SoC UART's to serial_hd's to the machine. It makes each UART a proper child member of the SoC, and then allows the machine to selectively initialize the chardev for each UART with a serial_hd. This should preserve backwards compatibility, but also allow multi-SoC boards to completely change the wiring of serial devices from the command line to specific SoC UART's. This also removes the uart-default property from the SoC, since the SoC doesn't need to know what UART is the "default" on the machine anymore. I tested this using the images and commands from the previous refactoring, and another test image for the ast1030: wget https://github.com/facebook/openbmc/releases/download/v2021.49.0/fuji.mtd wget https://github.com/facebook/openbmc/releases/download/v2021.49.0/wedge100.mtd wget https://github.com/peterdelevoryas/OpenBIC/releases/download/oby35-cl-2022.13.01/Y35BCL.elf Fuji uses UART1: qemu-system-arm -machine fuji-bmc \ -drive file=fuji.mtd,format=raw,if=mtd \ -nographic ast2600-evb uses uart-default=UART5: qemu-system-arm -machine ast2600-evb \ -drive file=fuji.mtd,format=raw,if=mtd \ -serial null -serial mon:stdio -display none Wedge100 uses UART3: qemu-system-arm -machine palmetto-bmc \ -drive file=wedge100.mtd,format=raw,if=mtd \ -serial null -serial null -serial null \ -serial mon:stdio -display none AST1030 EVB uses UART5: qemu-system-arm -machine ast1030-evb \ -kernel Y35BCL.elf -nographic Fixes: 6827ff20b2975 ("hw: aspeed: Init all UART's with serial devices") Signed-off-by: Peter Delevoryas Reviewed-by: Cédric Le Goater Message-Id: <20220705191400.41632-4-peter@pjd.dev> Signed-off-by: Cédric Le Goater

hw/arm/virt: dt: add rng-seed property

2022-07-07T10:36:07+00:00

In 60592cfed2 ("hw/arm/virt: dt: add kaslr-seed property"), the kaslr-seed property was added, but the equally as important rng-seed property was forgotten about, which has identical semantics for a similar purpose. This commit implements it in exactly the same way as kaslr-seed. It then changes the name of the disabling option to reflect that this has more to do with randomness vs determinism, rather than something particular about kaslr. Cc: Peter Maydell Signed-off-by: Jason A. Donenfeld [PMM: added deprecated.rst section for the deprecation] Reviewed-by: Peter Maydell Signed-off-by: Peter Maydell

hw/misc/aspeed: Add PECI controller

2022-06-30T07:21:14+00:00

This introduces a really basic PECI controller that responses to commands by always setting the response code to success and then raising an interrupt to indicate the command is done. This helps avoid getting hit with constant errors if the driver continuously attempts to send a command and keeps timing out. The AST2400 and AST2500 only included registers up to 0x5C, not 0xFC. They supported PECI 1.1, 2.0, and 3.0. The AST2600 and AST1030 support PECI 4.0, which includes more read/write buffer registers from 0x80 to 0xFC to support 64-byte mode. This patch doesn't attempt to handle that, or to create a different version of the controller for the different generations, since it's only implementing functionality that is common to all generations. The basic sequence of events is that the firmware will read and write to various registers and then trigger a command by setting the FIRE bit in the command register (similar to the I2C controller). Then the firmware waits for an interrupt from the PECI controller, expecting the interrupt status register to be filled in with info on what happened. If the command was transmitted and received successfully, then response codes from the host CPU will be found in the data buffer registers. Signed-off-by: Peter Delevoryas Reviewed-by: Cédric Le Goater Message-Id: <20220630045133.32251-12-me@pjd.dev> [ clg: s/sysbus_mmio_map/aspeed_mmio_map/ ] Signed-off-by: Cédric Le Goater

aspeed: Map unimplemented devices in SoC memory

2022-06-30T07:21:13+00:00

Signed-off-by: Peter Delevoryas Reviewed-by: Cédric Le Goater Message-Id: <20220624003701.1363500-5-pdel@fb.com> Signed-off-by: Cédric Le Goater

aspeed: Remove usage of sysbus_mmio_map

2022-06-30T07:21:13+00:00

sysbus_mmio_map maps devices into "get_system_memory()". With the new SoC memory attribute, we want to make sure that each device is mapped into the SoC memory. In single SoC machines, the SoC memory is the same as "get_system_memory()", but in multi SoC machines it will be different. Signed-off-by: Peter Delevoryas Reviewed-by: Cédric Le Goater Message-Id: <20220624003701.1363500-4-pdel@fb.com> Signed-off-by: Cédric Le Goater

aspeed: Add memory property to Aspeed SoC

2022-06-30T07:21:13+00:00

Multi-SoC machines can use this property to specify a memory container for each SoC. Single SoC machines will just specify get_system_memory(). Signed-off-by: Peter Delevoryas Reviewed-by: Cédric Le Goater Message-Id: <20220624003701.1363500-3-pdel@fb.com> Signed-off-by: Cédric Le Goater