On 1/7/25 12:05, Alex Bennée wrote:
Stafford Horne <sho...@gmail.com> writes:
I have not used -hda before, do you have it working with other targets?
According to the qemu docs in qemu-options.hx. I see:
Use file as hard disk 0, 1, 2 or 3 image on the default bus of the
emulated machine (this is for example the IDE bus on most x86 machines,
but it can also be SCSI, virtio or something else on other target
architectures). See also the :ref:`disk images` chapter in the System
Emulation Users Guide.
I think, since we don't have a "default" bus in openrisc this doesn't work so we
need to specify the -drive explictly.
I checked the x86 machine code and confirm it seems to work like this. There is
code in the system setup to look for hd* drives and wire them into IDE. There
is no such code in openrisc.
Yeah don't use -hdX as they are legacy options with a lot of default
assumptions. As the docs say:
https://qemu.readthedocs.io/en/master/system/invocation.html#hxtool-1
The QEMU block device handling options have a long history and have
gone through several iterations as the feature set and complexity of
the block layer have grown. Many online guides to QEMU often reference
older and deprecated options, which can lead to confusion.
I want "a block device from this file" in a generic way that works the
same across multiple architectures regardless of the board being
emulated, where I only have to specify the file not explicitly
micromanage bus plumbing details, and which is easy for a human to type
from when explained over a voice call.
What's the alternative to -hda you suggest for that?
Can I do "./run-qemu.sh -drive file=blah.img" without the rest? Perhaps
specify all the details in the script and then optionally add an extra
argument at the end? I couldn't get that to work:
$ root/or1k/run-qemu.sh -netdev user,id=net0 -device
virtio-net-device,netdev=net0 -drive format=raw,id=hd0 -device
virtio-blk-device,drive=hd0 -drive file=README
qemu-system-or1k: -drive format=raw,id=hd0: A block device must be
specified for "file"
Also, if you say -device and -drive but do NOT specify a file, qemu
refuses to start. So I can't set the defaults but only optionally use
them, the way -hda has defaults built into the image that don't cause a
problem if I DON'T add a -hda argument to the command line.
Older options like -hda are essentially macros which expand into -drive
options for various drive interfaces.
Where the knowledge of "what this board needs in order to do that" is
built into qemu rather than provided by the caller, yes.
The original forms bake in a lot
of assumptions from the days when QEMU was emulating a legacy PC, they
are not recommended for modern configurations.
I'm building a kernel. It finds /dev/?da so I can mount it. That is my
desired outcome.
I am attempting to get generic behavior out of multiple architectures,
among other reasons so I can cross-test and package up "it fails on X,
here's a build and test" to point package maintainers at.
"It natively builds under the emulator" is the easiest way to make that
work, which is why https://landley.net/bin/toolchains/latest/ has a
native.sqf for each cross.tar.xz.
wget system-image-arch.txz
wget toolchain.sqf
wget test.img
./run-emulator.sh -hda test.img -hdb toolchain.sqf
If I have to explain "-drive virtio-potato-walrus,inkpot=striated
-device collect=striated,burbank-potato,ireland" at somebody whose
domain expertise is xfce or something, the barrier to getting them to
reproduce the issue I'm seeing is noticeably higher. If I have to MAKE a
bespoke wrapper shell script for them with every bug report, the
likelihood that it works differently for them than when I tried it is
noticeably nonzero, and the likelihood of the issue going on my todo
heap and never getting pursued upstream is also noticeably higher. Which
is why I try to make generic tools...
(Making a _test_ script to demonstrate the issue is normal. If it's
their project, usually they can tell if I typoed it and fix it up
themselves because they know what I MEANT. But if I typo the setup for
the virtual environment, or are missing a prerequisite package install,
or they hit qemu version skew, or I said /bin/sh and theirs points to
dash... Brick wall. It either works or it doesn't.)
(And when I have to set up the long version for a nightly cron job, and
then when the test fails 6 months later and I look at it and go "huh?
salad?" that's a bad 3am digression as well. And which is more likely to
break from version skew during qemu version upgrades: two lines of
micromanaging --longopts or -hda that gets adjusted by the maintainers?)
Rob
P.S. For some reason -hda grew an "I'm going to make the first block
read-only just like loopback devices do because you can't be trusted"
nag a few years back, but it's mostly yet more boot spam. I can tell the
kernel to be quiet during boot, but never figured out the equivalent for
qemu-system...
