On Wed, Jul 03, 2024 at 08:27:09PM -0500, Mark Hatle wrote:
>
> Should not be required to pass ANY arguments to runqemu. Behavior should be
> the same as if you run no arguments when using it with any regular Yocto
> Project QEMU.
I agree, your qemu-system-aarch64-multiarch interposer should exhibit
the same behavior as qemu-system-aarch64 as expected by runqemu. In
2024.1 it isn't. There is no sense in disputing this with me. I didn't
write runqemu. I don't maintain runqemu. I have no intention of
changing runqemu. I'm just the messenger. This change has caused a
code path which previously worked to break.
> Looking at what was generated:
>
> qb_opt_append = -hw-dtb
> /localdisk/git/xlnx_rel-v2024.1/build/tmp/deploy/images/product/qemu-hw-devicetrees/multiarch/board-versal-xcvp1802-ps-virt.dtb
> -serial null -serial null -device
> loader,file=/localdisk/git/xlnx_rel-v2024.1/build/tmp/deploy/images/product/Image-initramfs-product.bin,addr=0x200000,force-raw=on
> -device
> loader,file=/localdisk/git/xlnx_rel-v2024.1/build/tmp/deploy/images/product/boot.scr,addr=0x20000000,force-raw=on
> -boot mode=5 -plm-args ' -M microblaze-fdt -device
> loader,file=/localdisk/git/xlnx_rel-v2024.1/build/tmp/deploy/images/product/BOOT-product_bh.bin,addr=0xF201E000,force-raw
> -device loader,addr=0xf0000000,data=0xba020004,data-len=4 -device
> loader,addr=0xf0000004,data=0xb800fffc,data-len=4 -device
> loader,file=/localdisk/git/xlnx_rel-v2024.1/build/tmp/deploy/images/product/CDO/pmc_cdo.bin,addr=0xf2000000,force-raw
> -device
> loader,file=/localdisk/git/xlnx_rel-v2024.1/build/tmp/deploy/images/product/plm-product.elf,cpu-num=1
> -device loader,addr=0xF1110624,data=0x0,data-len=4 -device
> loader,addr=0xF1110620,data=0x1,data-len=4 -hw-dtb
> /localdisk/git/xlnx_rel-v2024.1/build/tmp/deploy/images/product/qemu-hw-devicetrees/multiarch/board-versal-pmc-virt.dtb
> -display none ' -serial mon:stdio -display none -net nic -net
> bridge,br=virbr0,helper=/localdisk/git/xlnx_rel-v2024.1/build/tmp/work/product-ciena-linux/ciena-image/1.0-r0/recipe-sysroot-native/usr/bin/qemu-oe-bridge-helper
>
>
> This contains the '-plm-args' and such. So the --help should NOT have been
> triggered, assuming there isn't any other sort of issue there.
--help was triggered because runqemu specifically asked for --help. I
pasted the link to the line of code that does it, but to be even more
clear, I will paste the code itself here. It is in runqemu's setup_vga
function:
# If we have no display option, we autodetect based upon what qemu
supports. We
# need our font setup and show-cusor below so we need to see what qemu
--help says
# is supported so we can pass our correct config in.
if not self.nographic and not self.sdl and not self.gtk and not
self.publicvnc and not self.egl_headless == True:
output = subprocess.check_output([self.qemu_bin, "--help"],
universal_newlines=True, env=self.qemu_environ)
here ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
> If you do --help, it's debatable if exit 0 or 1 is appropriate... but in the
> end this script didn't do anything "useful" for runqemu.
Agree, causing runqemu to raise an uncaught exception is not very
useful. Disagree that it's debatable. If the user asks for help, and
you displayed help successfully, the convention is to exit with a
success code. If you displayed help because there was some error with
the command line arguments, then the convention is to exit with an error
code. And regardless of convention, this is the behavior of
qemu-system-aarch64. Since qemu-system-aarch64-multiarch represents an
interposer to qemu-system-aarch64, it's required to behave as
qemu-system-aarch64 behaves, or else risk these sort of problems.
> If the second clause hits, then it IS an error, since the machine didn't
> startup properly.
Also agree. The change I described earlier is our /workaround/, I would
not suggest it as a fix. A fix would probably look something more like
(not tested, and probably could be nicer):
diff --git
a/meta-xilinx-core/recipes-devtools/qemu/files/qemu-system-aarch64-multiarch
b/meta-xilinx-core/recipes-devtools/qemu/files/qemu-system-aarch64-multiarch
index 1dcac990..7a63fdd8 100644
--- a/meta-xilinx-core/recipes-devtools/qemu/files/qemu-system-aarch64-multiarch
+++ b/meta-xilinx-core/recipes-devtools/qemu/files/qemu-system-aarch64-multiarch
@@ -29,7 +29,13 @@ if '-plm-args' in APU_args:
if PMU_args and PLM_args:
sys.exit("\nError: -pmu-args can not be used with -plm-args\n")
-if ('--help' in APU_args) or (not PMU_args and not PLM_args):
+def help(status):
+
+if '--help' in APU_args:
+ process = subprocess.Popen(binpath + '/qemu-system-aarch64 --help')
+ sys.exit(process.wait())
+
+if not PMU_args and not PLM_args:
print("AMD FPGA QEMU multiarch wrapper\n")
print("Version 2024.1")
print("")
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5441):
https://lists.yoctoproject.org/g/meta-xilinx/message/5441
Mute This Topic: https://lists.yoctoproject.org/mt/107005905/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/meta-xilinx/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
