On 7/3/24 4:19 PM, Thompson, Corey via lists.yoctoproject.org wrote:
On Wed, Jul 03, 2024 at 03:40:27PM -0500, Mark Hatle wrote:
On 7/2/24 1:58 PM, Thompson, Corey via lists.yoctoproject.org wrote:
Hello.
I'm in the process of upgrading my organization's development
environment from 2023.2 to 2024.1 and encountered this issue. We can
easily work around it with a patch in our layers, but I thought I'd
bring it to your attention.
It looks like in 2024.1 qemu-system-aarch64-multiarch received some
changes, one of which was to exit(1) in response to --help:
https://urldefense.com/v3/__https://github.com/Xilinx/meta-xilinx/blob/master/meta-xilinx-core/recipes-devtools/qemu/files/qemu-system-aarch64-multiarch*L42__;Iw!!OSsGDw!KQymcH2-Xrjs_qbSrMjGZOz7K8rIn2MQkL-7lleoyTmD1k506OoYLBSBcEh7Z54qUajtmhL4qWK9BqzeMT-0Dd3BnA$
[github[.]com]
In our environment this is causing a failure when we use "runqemu"
without the "nographic" option. For us, it makes it to this line:
https://urldefense.com/v3/__https://github.com/Xilinx/poky/blob/rel-v2024.1/scripts/runqemu*L1391__;Iw!!OSsGDw!KQymcH2-Xrjs_qbSrMjGZOz7K8rIn2MQkL-7lleoyTmD1k506OoYLBSBcEh7Z54qUajtmhL4qWK9BqzeMT-ie5V89w$
[github[.]com]
How are you executing runqemu that is triggering the help? Assuming you are
NOT passing in "--help", then the condition:
I'm using "runqemu" without any arguments and with the attached
qemuboot.conf generated from our machine.conf. Regardless of how I got
there, you can look at that line and see that exiting 1 from --help will
cause that code path in runqemu to fail.
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.
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.
subprocess.check_output() detects that the command exited with non-zero
status and throws an exception.
If I simply patch that qemu-system-aarch64-multiarch script to exit(0)
then our regular workflow works again.
As of right now this is intentional, unless I've got a clear workflow where
it's triggered and should not be.
That's a little surprising to me. Why would you want to indicate error
when the user asks for --help and it prints the help successfully?
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.
If the second clause hits, then it IS an error, since the machine didn't startup
properly.
Here are a few examples of the convention:
$ ls --help >/dev/null 2>&1; echo $?
0
$ top -h >/dev/null 2>&1; echo $?
0
$ git --help >/dev/null 2>&1; echo $?
0
$ python3 --help >/dev/null 2>&1; echo $?
0
$ runqemu --help >/dev/null 2>&1; echo $?
0
$ devtool --help >/dev/null 2>&1; echo $?
0
$ qemu-system-aarch64 --help >/dev/null 2>&1; echo $?
0
Can you make the following change and test it in your configuration? This will
tell us what is actually going wrong and help me figure out the right solution:
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):
+if (not PMU_args and not PLM_args):
+ sys.exit(f"\nERROR: Neither -pmu-args nor -plm-args was defined.\n")
+
+if ('--help' in APU_args):
print("AMD FPGA QEMU multiarch wrapper\nVersion 2024.1\n\nUsage:")
print(f" {sys.argv[0]} <APU options> [-pmu-args <pmu options>]")
print(f" {sys.argv[0]} <APU options> [-plm-args <plm options>]\n")
sys.exit(0)
This way if you ARE calling --help, it will display and not error. If you are
triggering the other clause you will get an error indicating missing arguments.
--Mark
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5440):
https://lists.yoctoproject.org/g/meta-xilinx/message/5440
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]]
-=-=-=-=-=-=-=-=-=-=-=-
