The new firmware includes support for an A400-44 machine
with initial functional 64-bit PAT PDC support:
- Linux 64-bit kernel runs nicely.
- ODE 2006 works nicely on 715, B160L, and A400, but has problems on C3700.
- MPE and 64-bit HP-UX11 need more work, although HP-UX11 boot up to a crash
where it reports where it had problems.
Signed-off-by: Helge Deller <deller@gmx.de>
Reviewed-by: Anton Johansson <anjo@rev.ng>
Without this linker flag, the linking fails on NetBSD v10.1 with:
ld: i386 architecture of input file `multiboot.o' is incompatible with i386:x86-64 output
ld: i386 architecture of input file `multiboot_dma.o' is incompatible with i386:x86-64 output
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260121074819.29396-1-thuth@redhat.com>
Full changelog since last update (183c9ff8056b) :
Joe Komlodi (1):
npcm8xx: Fix u-boot copy size
Jamin Lin (3):
ast27x0: refactor FIT boot loader into fmc_image.c for future Caliptra Manifest support
ast27x0: Add Caliptra Manifest boot support and MCU runtime loader framework
ast27x0: Fix compilation issues on Ubuntu 22.04
Compiled with gcc version 13.3.0
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Nabih Estefan <nabihestefan@google.com>
Some small bugfixes for the 715/64 machine:
- fix CPU detection of 715 in HP-UX and NetBSD
- minor cleanups regarding LASI_SCSI for 715
Signed-off-by: Helge Deller <deller@gmx.de>
PPC Patches for 10.2 Hard Freeze
* Pegasos fixes for mem leak and dtb blob updates
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEa4EM1tK+EPOIPSFCRUTplPnWj7sFAmkRm/YACgkQRUTplPnW
# j7tTWA/+PTQfODH0dRpuApQys23okruXRJ0C26e+1Bb/H7IeSerfZ33GgpgW8ldi
# R6amhrJ4GYXFkjK34iFV+daXhtKEA/44fBykr1SCwDixiD7qGGq7a0yOEDERurEq
# eDn4of82O2C2l1jUY+hx0jXgWlEQLAeLH1bVwikJL75jbV7Ob7wt3W3bC7M6iup9
# jaZP6RwcXW9JqFeavS5r3DCbdPf+U/jafmxIP+qpZVS92jwxcOZbmsXgZVPW92xe
# Cwc8AY3FwUIdUfPGKj2uyuJNtLWuev0+o1roZ8mmuiSFoMGQuw+X5bmLt0qBvVyK
# EPc0dxsliyUhPso4vq9SCI9hBid0NQlsqpGpRWpEuP0z8vc4aF41P++VBC4DQ8ls
# Ffc2dz3ncUhII8V+N7jGykWG2ZKOqxgndlq7V/8k2f96kbDWEXNYJomnJd5NN6NK
# uKlKQN9pu2Btp2Lo9bLNVQT3jclByBmNtSyzqQhbLT/JbhTorhs6mYilTM8Wv7da
# 1Dn+PesmxTMtO7wgjy1qu6Ms55zTweKvpW0sNDMOMGOvQ1ssff/3WT8nrk1jXXHw
# UeEidzTZtr375LkCJ7DQnChztr9YjiQLPPAEkpUMz1sV32fGRrOr4kR3zGbjAiBY
# ARZLAErqHBMYO0NYi/+MR266cjZ841d+ImrP329BZqBvGfGBbpE=
# =iAZh
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 10 Nov 2025 09:01:58 AM CET
# gpg: using RSA key 6B810CD6D2BE10F3883D21424544E994F9D68FBB
# gpg: Good signature from "Harsh Prateek Bora <harsh.prateek.bora@gmail.com>" [undefined]
# gpg: aka "Harsh Prateek Bora <harshpb@linux.ibm.com>" [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: 6B81 0CD6 D2BE 10F3 883D 2142 4544 E994 F9D6 8FBB
* tag 'pull-ppc-for-10.2-d5-20251110' of https://gitlab.com/harshpb/qemu:
pc-bios/dtb/pegasos*.dtb: Fix compiled dtb blobs
hw/ppc/pegasos: Fix memory leak
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
This is SeaBIOS for the hppa architecture v20
and it contains mostly bugfixes for issues which
were introduced by adding the 715/64 machine.
Fixes include:
- Fix inventory for 715 Snake machine
- Detect if LASI LAN and SCSI exists at startup
- Allow LASI LAN on B160L if created by qemu
- Enhance error messages
Signed-off-by: Helge Deller <deller@gmx.de>
When adding these files somehow an incomplete version was committed.
Regenerate and update these dtb files to match the dts which fixes
problems caused by missing nodes in the dtb.
Fixes: 9099b430a4 (hw/ppc/pegasos2: Change device tree generation)
Fixes: 3c21f9dfcf (hw/ppc/pegasos2: Add VOF support for pegasos1)
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Reported-by: Yogesh Vyas <yvyas1991@gmail.com>
Tested-by: Yogesh Vyas <yvyas1991@gmail.com>
Message-Id: <20251108193717.DADA9597302@zero.eik.bme.hu>
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Update the sam460ex firmware to match 2015.c version from the machine
vendor which fixes USB devices and some other bugs. Also cherry pick
some commits from upstream U-Boot that moves licenses in a subdir and
allows gitlab to correctly detect and show license information. Drop
version number from the binary name to avoid needing to change it in
case of future updates.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Message-Id: <20251028151923.10DBB5972E5@zero.eik.bme.hu>
Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
HP-PARISC 715 machine with NCR710 SCSI chip
This series adds a new emulation for a HP PA-RISC 715/64 model,
as descrived here: https://www.openpa.net/systems/hp-9000_715.html.
That machine has no PCI bus and instead uses a "LASI" chip which has built-in
NCR 53c710 SCSI and i82596 network chips. Compared to the other already
emulated machines B160L and C3700, this machine should be able to support older
operating systems like HP-UX 9 as well.
The QEMU project participated in the Google Summer of Code 2025 program by
"Implementing LASI Network Card and NCR 710 SCSI Controller Device Models", and
Soumyajyotii Ssarkar stepped up to develop those drivers.
This patch series includes the code for the NCR710 SCSI controller,
the network code will follow in later patch series.
# -----BEGIN PGP SIGNATURE-----
#
# iHUEABYKAB0WIQS86RI+GtKfB8BJu973ErUQojoPXwUCaP/g8wAKCRD3ErUQojoP
# X1hOAP9WOYVNz7UIpNztQ9p3tUKApALaPR3aaiORMLrjktaDMQD/TIHExaKIKtn6
# iLy+RXzPFdpqmI/cBQx57q8lWzUd2QI=
# =Y7lX
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 27 Oct 2025 10:15:31 PM CET
# gpg: using EDDSA key BCE9123E1AD29F07C049BBDEF712B510A23A0F5F
# gpg: Good signature from "Helge Deller <deller@gmx.de>" [unknown]
# gpg: aka "Helge Deller <deller@kernel.org>" [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: 4544 8228 2CD9 10DB EF3D 25F8 3E5F 3D04 A7A2 4603
# Subkey fingerprint: BCE9 123E 1AD2 9F07 C049 BBDE F712 B510 A23A 0F5F
* tag 'devel-scsi-ncr710-pull-request' of https://github.com/hdeller/qemu-hppa:
hw/hppa: Add 715 machine type including NCR710 SCSI
hw/hppa: Require SeaBIOS version 19 for 715 machine
hw/hppa: PCI devices depend on availability of PCI bus
hw/hppa: Add NCR 710 SCSI driver to LASI chip Kconfig entry
hw/hppa: Fix interrupt of LASI parallel port
hw/hppa: Fix firmware end address for LASI chip
hw/scsi: Add config option for new ncr710 driver
lasi: Forward LASI SCSI ports to NCR 53c710 driver
ncr710: Add driver for the NCR 53c710 SCSI chip
lasi_ncr710: Add LASI wrapper for NCR 53c710 SCSI chip
target/hppa: Update SeaBIOS-hppa to version 19
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
This is SeaBIOS for the hppa architecture v19.
It's required to support the new 715 machine,
which uses a LASI NCR710 SCSI controller.
New:
- Added new 715 machine (Snake machine, no PCI bus)
- Added driver for NCR710 SCSI on LASI (Soumyajyotii Ssarkar)
Fixes & cleanups:
- Fix memory size detection on NetBSD
- Snake machines do not support the PDC_SYSTEM_MAP call
- Always return the HPA in pdc_mem_map() PDC call
- Add LMMIO range for internal artist graphic card
- various coding style cleanups
Signed-off-by: Helge Deller <deller@gmx.de>
While running the kvm-unit-tests on Intel platforms with "split lock
disable" feature, every test triggers a kernel warning of
x86/split lock detection: #AC: qemu-system-x86_64/373232 took a split_lock trap at address: 0x1e3
Hack KVM by exiting to QEMU on split lock #AC, we get
KVM: exception 17 exit (error code 0x0)
EAX=00000001 EBX=00000000 ECX=00000014 EDX=0001fb80
ESI=00000000 EDI=000000a8 EBP=00000000 ESP=00006f10
EIP=000001e3 EFL=00010002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0900 00009000 0000ffff 00009300 DPL=0 DS16 [-WA]
CS =c000 000c0000 0000ffff 00009b00 DPL=0 CS16 [-RA]
SS =0000 00000000 0000ffff 00009300 DPL=0 DS16 [-WA]
DS =c000 000c0000 0000ffff 00009300 DPL=0 DS16 [-WA]
FS =0950 00009500 0000ffff 00009300 DPL=0 DS16 [-WA]
GS =06f2 00006f20 0000ffff 00009300 DPL=0 DS16 [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
GDT= 000c02b4 00000027
IDT= 00000000 000003ff
CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000000
Code=89 16 08 00 65 66 0f 01 16 06 00 66 b8 01 00 00 00 0f 22 c0 <65> 66 ff 2e 00 00 b8 10 00 00 00 8e d0 8e d8 8e c0 8e e0 8e e8 66 b8 08 00 66 ba 10 05 66
And it matches with what disassembled from multiboo_dma.bin:
#objdump -b binary -m i386 -D pc-bios/multiboot_dma.bin
1d1: 08 00 or %al,(%eax)
1d3: 65 66 0f 01 16 lgdtw %gs:(%esi)
1d8: 06 push %es
1d9: 00 66 b8 add %ah,-0x48(%esi)
1dc: 01 00 add %eax,(%eax)
1de: 00 00 add %al,(%eax)
1e0: 0f 22 c0 mov %eax,%cr0
> 1e3: 65 66 ff 2e ljmpw *%gs:(%esi)
1e7: 00 00 add %al,(%eax)
1e9: b8 10 00 00 00 mov $0x10,%eax
1ee: 8e d0 mov %eax,%ss
1f0: 8e d8 mov %eax,%ds
1f2: 8e c0 mov %eax,%es
1f4: 8e e0 mov %eax,%fs
1f6: 8e e8 mov %eax,%gs
1f8: 66 b8 08 00 mov $0x8,%ax
1fc: 66 ba 10 05 mov $0x510,%dx
We can see that the instruction at 0x1e3 is a far jmp through the GDT.
However, the GDT is not 8 byte aligned, the base is 0xc02b4.
Intel processors follow the LOCK semantics to set the accessed flag of the
segment descriptor when loading a segment descriptor. If the the segment
descriptor crosses two cache line, it causes split lock.
Fix it by aligning the GDT on 8 bytes, so that segment descriptor cannot
span two cache lines.
Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Link: https://lore.kernel.org/r/20250808035027.2194673-1-xiaoyao.li@intel.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Full changelog since last update (1287b6e42e83) :
Hao Wu (2):
Automatically search for UBOOT location for NPCM8xx images.
Dynamically detects NPCM8XX UBOOT destination and size.
Jamin Lin (5):
Add initial support for AST27x0
ast27x0: Show build date and git version
ast27x0: Initialize and enable SSP/TSP using SCU with reserved-memory from DTB
ast27x0: Fix missing SCU module reset for SSP and TSP initialization
ast27x0: Fix Makefile to unconditionally set CC to support correct cross-compilation
Compiled with gcc version 13.3.0
Reviewed-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Cédric Le Goater <clg@redhat.com>
This new s390-ccw.img binary contains the addition of the loadparm
feature to the pxelinux.cfg network booting code.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Adding -pie to LDFLAGS caused s390-ccw.img to become dynamically linked.
By using -static-pie it will be linked statically like other bios.
This ensures that the build output doesn't change depending on the
default dynamic loader path of the toolchain.
Fixes: d884c86dcd ("s390/bios: Make the s390-ccw.img relocatable")
Signed-off-by: Sertonix <sertonix@posteo.net>
Message-ID: <DAJ1QOSAP9LS.342SQSM0UZU80@posteo.net>
Signed-off-by: Thomas Huth <thuth@redhat.com>
We are going to reuse this function for selecting an entry from
the pxelinux.cfg menu, so rename this function with a "menu_"
prefix and make it available globally.
Reviewed-by: Jared Rossi <jrossi@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20250709083443.41574-4-thuth@redhat.com>
We're going to support a menu for the pxelinux.cfg code, and to be able
to reuse some functionality from menu.c, we should align the maximum
amount of possible entries with the MAX_BOOT_ENTRIES constant that is
used there. Thus replace MAX_PXELINUX_ENTRIES with MAX_BOOT_ENTRIES.
Reviewed-by: Jared Rossi <jrossi@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20250709083443.41574-3-thuth@redhat.com>
Since we're linking the network booting code into the main firmware
binary nowadays, we can support the "loadparm" parameter now quite
easily for pxelinux.cfg config files that contain multiple entries.
Reviewed-by: Jared Rossi <jrossi@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20250709083443.41574-2-thuth@redhat.com>
We have been inconsistent about whether ROMS stored in git have
execute permission set, and by default meson will preserve source
file permissions when installing files. This has caused periodic
problems in RPM packaging as executable binary files get analysed
by various tools/linters, which can trip up on the ROMs.
Tell meson explicitly that all the ROMs should be without execute
permission when installed.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Helge Deller <deller@gmx.de>
Tested-by: Helge Deller <deller@gmx.de>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250530152118.65030-1-berrange@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
The default PNOR image is erased and not recognised by skiboot, so NVRAM
gets disabled. This change adds a tiny pnor file that is a proper FFS
image with a formatted NVRAM partition. This is recognised by skiboot and
will persist across machine reboots.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
This adds TPM pass through API.
Also, moves SLOF from github to gitlab.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
This skiboot firmware importantly contains updates for HOMER/OCC bugs.
These subsystems have bitrotted in QEMU and skiboot and this update
allows new QEMU models to be exercised.
Power11 support is also added. This model is not yet merged in QEMU,
but firmware support will make development and testing simpler.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
This is SeaBIOS for the hppa architecture v18.
It allows us to emulate up to 256 GB RAM on 64-bit
guests and to boot HP-UX 64-bit one step further.
Fixes:
- Fix PDC_CACHE/PDC_CACHE_RET_SPID return value for space
register hashing on 64-bit HP-UX
- Fix IRT table entries to use slot number
- Increase PCI alignment for memory bars to 64k
New PDC functions & general enhancements:
- Allow up to 256 GB RAM on 64-bit machines
Signed-off-by: Helge Deller <deller@gmx.de>
Fix the problem with the non-quiesced virtio-net device and
make sure to abort the boot process if the user specified a wrong
loadparm parameter.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Because the loadparm specifies an exact kernel the user wants to boot, if the
loadparm is invalid it must represent a misconfiguration of the guest. Thus we
should abort the IPL immediately, without attempting to use other devices, to
avoid booting into an unintended guest image.
Signed-off-by: Jared Rossi <jrossi@linux.ibm.com>
Message-ID: <20250117212235.1324063-2-jrossi@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
The code in net_init_ip() currently bails out early if "rc" is less
than 0, so the if-statements that check for negative "rc" codes to
print out some specific error messages with regards to the TFTP server
are never reached. Move them earlier to bring that dead code back to
life.
Reviewed-by: Jared Rossi <jrossi@linux.ibm.com>
Reviewed-by: Eric Farman <farman@linux.ibm.com>
Tested-by: Jared Rossi <jrossi@linux.ibm.com>
Message-ID: <20250116115826.192047-4-thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
When we are trying to boot from virtio-net devices, the
s390-ccw bios currently leaves the virtio-net device enabled
after using it. That means that the receiving virt queues will
continue to happily write incoming network packets into memory.
This can corrupt data of the following boot process. For example,
if you set up a second guest on a virtual network and create a
lot of broadcast traffic there, e.g. with:
ping -i 0.02 -s 1400 -b 192.168.1.255
and then you try to boot a guest with two boot devices, a network
device first (which should not be bootable) and e.g. a bootable SCSI
CD second, then this guest will fail to load the kernel from the CD
image:
$ qemu-system-s390x -m 2G -nographic -device virtio-scsi-ccw \
-netdev tap,id=net0 -device virtio-net-ccw,netdev=net0,bootindex=1 \
-drive if=none,file=test.iso,format=raw,id=cd1 \
-device scsi-cd,drive=cd1,bootindex=2
LOADPARM=[ ]
Network boot device detected
Network boot starting...
Using MAC address: 52:54:00:12:34:56
Requesting information via DHCP: done
Using IPv4 address: 192.168.1.76
Using TFTP server: 192.168.1.1
Trying pxelinux.cfg files...
TFTP error: ICMP ERROR "port unreachable"
Receiving data: 0 KBytes
Repeating TFTP read request...
TFTP error: ICMP ERROR "port unreachable"
Failed to load OS from network.
Failed to IPL from this network!
LOADPARM=[ ]
Using virtio-scsi.
! virtio-scsi:setup:inquiry: response VS RESP=ff !
ERROR: No suitable device for IPL. Halting...
We really have to shut up the virtio-net devices after we're not
using it anymore. The easiest way to do this is to simply reset
the device, so let's do that now.
Reviewed-by: Jared Rossi <jrossi@linux.ibm.com>
Reviewed-by: Eric Farman <farman@linux.ibm.com>
Tested-by: Jared Rossi <jrossi@linux.ibm.com>
Message-ID: <20250116115826.192047-3-thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
QEMU consumes some device tree blobs, so these have been committed
to the tree in as firmware, along with the device tree source used
to generate them. We know the blobs are "good enough" to have QEMU
boot a system, so we don't really maintain and rebuild the sources.
These blobs were generated with older 'dtc' binaries. We use the
v1.6.1 version since 2021 (commit 962fde57b7 "dtc: Update to version
1.6.1").
Since commit 6e0dc9d2a8 ("meson: compile bundled device trees"),
if dtc binary is available, it is directly used to compile the
device tree sources. New versions of 'dtc' add checks which display
warnings or errors. Our sources are a bit old, so dtc v1.6.1 now
emit the following warnings on a fresh build:
[163/3414] Generating pc-bios/canyonlands.dts with a custom command
pc-bios/canyonlands.dts:47.9-50.4: Warning (unit_address_vs_reg): /memory: node has a reg or ranges property, but no unit name
pc-bios/canyonlands.dts:210.13-429.5: Warning (unit_address_vs_reg): /plb/opb: node has a reg or ranges property, but no unit name
pc-bios/canyonlands.dts:464.26-504.5: Warning (pci_bridge): /plb/pciex@d00000000: node name is not "pci" or "pcie"
pc-bios/canyonlands.dts:506.26-546.5: Warning (pci_bridge): /plb/pciex@d20000000: node name is not "pci" or "pcie"
pc-bios/canyonlands.dtb: Warning (unit_address_format): Failed prerequisite 'pci_bridge'
pc-bios/canyonlands.dtb: Warning (pci_device_reg): Failed prerequisite 'pci_bridge'
pc-bios/canyonlands.dtb: Warning (pci_device_bus_num): Failed prerequisite 'pci_bridge'
pc-bios/canyonlands.dts:268.14-289.7: Warning (avoid_unnecessary_addr_size): /plb/opb/ebc/ndfc@3,0: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
[164/3414] Generating pc-bios/petalogix-s3adsp1800.dts with a custom command
pc-bios/petalogix-s3adsp1800.dts:258.33-266.5: Warning (interrupt_provider): /plb/interrupt-controller@81800000: Missing #address-cells in interrupt provider
[165/3414] Generating pc-bios/petalogix-ml605.dts with a custom command
pc-bios/petalogix-ml605.dts:234.39-241.5: Warning (interrupt_provider): /axi/interrupt-controller@81800000: Missing #address-cells in interrupt provider
[177/3414] Generating pc-bios/bamboo.dts with a custom command
pc-bios/bamboo.dts:45.9-48.4: Warning (unit_address_vs_reg): /memory: node has a reg or ranges property, but no unit name
pc-bios/bamboo.dts:87.13-154.5: Warning (unit_address_vs_reg): /plb/opb: node has a reg or ranges property, but no unit name
pc-bios/bamboo.dts:198.3-50: Warning (chosen_node_stdout_path): /chosen:linux,stdout-path: Use 'stdout-path' instead
pc-bios/bamboo.dts:87.13-154.5: Warning (interrupts_property): /plb/opb: Missing interrupt-parent
pc-bios/bamboo.dts:100.14-108.6: Warning (interrupts_property): /plb/opb/ebc: Missing interrupt-parent
From QEMU perspective, these warnings are not really useful. It is
the responsibility of developers adding DT source/blob to QEMU
repository to check the source doesn't produce warnings, but as
long as the blob is useful enough, QEMU can consume it. So these
warnings don't add any value, instead they are noisy and might
distract us to focus on important warnings. Better disable them.
'dtc' provides the '--quiet' option for that [*]:
$ dtc --help
Usage: dtc [options] <input file>
Options: -[qI:O:o:V:d:R:S:p:a:fb:i:H:sW:E:@AThv]
-q, --quiet
Quiet: -q suppress warnings, -qq errors, -qqq all
Update meson to disable these unuseful DTC warnings.
[*] https://lore.kernel.org/qemu-devel/CAFEAcA-WJ9J1YQunJ+bSG=wnpxh1By+Bf18j2CyV7G0vZ=8b7g@mail.gmail.com/
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Acked-by: BALATON Zoltan <balaton@eik.bme.hu>
Message-Id: <20231006064750.33852-1-philmd@linaro.org>
I was seeing failures on vnc-display-test on FreeBSD:
make vm-build-freebsd V=1 TARGET_LIST=aarch64-softmmu BUILD_TARGET=check-qtest QEMU_LOCAL=1 DEBUG=1
Leads to:
qemu-system-aarch64: -vnc none: could not read keymap file: 'en-us'
Broken pipe
../src/tests/qtest/libqtest.c:196: kill_qemu() tried to terminate QEMU process but encountered exit status 1 (expected 0)
which was as far as I could tell because we don't populate the
$BLD/pc-bios/keymaps (although scripts/symlink-install-tree.py
attempts to symlink qemu-bundle/usr/local/share/qemu/keymaps/ to that
dir).
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20250108121054.1126164-31-alex.bennee@linaro.org>
Now that we can boot from multiple boot devices, we have to make sure
to reinitialize static variables like rx_last_idx to avoid that they
contain garbage data during the second boot attempt (which can lead to
crashes when the code tries to access the wrong ring data).
Message-ID: <20241111131120.317796-1-thuth@redhat.com>
Reviewed-by: Jared Rossi <jrossi@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Commit bb185de423 ("s390x: Add individual loadparm assignment to
CCW device") allowed boot devices to be assigned a loadparm value independent
of the machine value, however, when no boot devices are defined, the machine
loadparm becomes ignored. Therefore, let's check the machine loadparm
prior to probing the devices.
Signed-off-by: Jared Rossi <jrossi@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20241114161952.3508554-1-jrossi@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
