The current priority of BOOTDEVP_4_SCAN_FAST means that virtio is
scanned after SCSI. But virtio-scsi provides higher performance.
It seems better to regard virtio has an internal device, since it is
paravirtualised and thus fast. Change its bootdev priority to
BOOTDEVP_2_INTERNAL_FAST
Disable the virtio-fs feature on sandbox, since the virtio queue is not
not yet supported by the emulator.
Signed-off-by: Simon Glass <sjg@chromium.org>
U-Boot only supports a subset of the devices supported by QEMU. For
example, U-Boot does not currently support the vsock device.
It is helpful to see what devices are provided by QEMU and whether there
is a driver for it in U-Boot.
Add a new 'virtio list' command to provide this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Even if U-Boot doesn't have a driver for all of the virtio devices
provided by QEMU, it is still useful to see what they are. Fill out the
table of device types and names, so that 'virtio list' lists them all.
Signed-off-by: Simon Glass <sjg@chromium.org>
Provide a simple command to read a named file into memory.
Skip this test on sandbox for now, as it doesn't support this feature in
its emulation of QEMU.
Signed-off-by: Simon Glass <sjg@chromium.org>
There are a few selectors in a different region which contain what seems
to be arch-specific information. Add a way to display this. So far it
only works on x86.
Signed-off-by: Simon Glass <sjg@chromium.org>
QEMU provides a table containing the ACPI tables and information on how
to relocate them to any suitable memory address. Add a command to show
this information.
Signed-off-by: Simon Glass <sjg@chromium.org>
There are quite a few values provided by QEMU and used by U-Boot, for
which it isn't possible to see the values. Add a new 'qfw dump' command
to support this.
Skip this test on sandbox for now, as it doesn't support this feature in
its emulation of QEMU.
Signed-off-by: Simon Glass <sjg@chromium.org>
There are a few entries missing from this enum. Add them and add
comments for all items, since this doesn't seem to be clearly documented
within QEMU itself.
Signed-off-by: Simon Glass <sjg@chromium.org>
Update the command to show the size and selected file, since this is
useful information at times. Add a heading so it is clear what each
field refers to.
Add a simple test as well.
Signed-off-by: Simon Glass <sjg@chromium.org>
On 64-bit machines we don't always want to show 16 hex digits,
particularly if the value is 32-bit. Add a new function to show a 32-bit
value.
Signed-off-by: Simon Glass <sjg@chromium.org>
The bdinfo command makes use of quite a few functions which show a label
followed by a value, on a single line.
This sort of thing is generally useful outside of bdinfo, so move it to
a generic place. Use 'l' (for label) as the prefix.
The margin is still hard-coded to 12, which seems a reasonable limit for
a label.
Signed-off-by: Simon Glass <sjg@chromium.org>
These tests are designed to work on sandbox only. The truetype font
changes the current font, which QEMU targets may not support. The
meminfo test assumes a particular memory size.
Mark them as sandbox-only.
Signed-off-by: Simon Glass <sjg@chromium.org>
When a unit test fails, it returns the error code, which results in a
warning:
exit not allowed from main input shell.
Fix it by returning a failure code instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
Sometimes it is useful to process just one or two defconfigs and it is
convenient to do this just by listing them in the arguments. Add a -D
option for this.
Update the docs to avoid mentioning boards which have been removed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Sometimes it is useful to provide several disks to QEMU. Update the -d
flag to support this. It can be used like this:
scripts/build-qemu -d root.img mmc6.img -r
Signed-off-by: Simon Glass <sjg@chromium.org>
This file provide common functions related to QFW, so move it into
driver/qfw with the other code.
Series-to: concept
Cover-letter:
emulation: Restructure the Kconfig
At present ARM and x86 use differently named symbols to mean similar
things. For x86, board/emulation/Kconfig contains the targets, but ARM
has them in a different file. While ARM uses ARCH_QEMU to mean QEMU,
x86 uses VENDOR_EMULATION.
This series adjusts the Kconfig for emulation targets on x86 and ARM, to
improve consistency.
A new arch-neutral MACH_QEMU is introduced. This is enabled for all
ARM/x86 emulation targets. Furture work could add this for other archs
too.
END
Signed-off-by: Simon Glass <sjg@chromium.org>
There seems to be enough QFW code now to have its own directory. Move
the files there before adding more.
Signed-off-by: Simon Glass <sjg@chromium.org>
Now that ARM is using board/emulation/Kconfig, put the includes for the
board-specific Kconfig into this file too.
With this, both ARM and x86 use board/emulation/Kconfig to list the
targets.
Set up a single place in Kconfig where board/emulation/Kconfig is
included, removing the two sites in arch/arm and arch/x86
Move the ARM-specific Kconfig into this file.
Signed-off-by: Simon Glass <sjg@chromium.org>
This name matches the ARM name and 'emulation' is not really a vendor.
Use ARCH_QEMU_X86 instead, moving that option from its existing location.
Signed-off-by: Simon Glass <sjg@chromium.org>
Define MACH_QEMU whenever ARCH_QEMU_ARM is used.
Some of the uses of ARCH_QEMU_ARM with efi_loader should clearly apply
to all QEMU variables, so update these.
Signed-off-by: Simon Glass <sjg@chromium.org>
We have QEMU targets across various architecture. So there is not really
a QEMU archicture. So 'ARCH_QEMU' seems a bit peculiar.
We have a board/emulation directory where much of the arch-specific code
is kept. But QEMU is not really a board; in fact many boards use QEMU.
While 'emulation' is a useful concept, QEMU is only one of the emulators
available. so MACH_EMULATION seems too vague to capture QEMU-specific
features.
On ARM the code is in the arch/arm/mach-qemu directory and it seems
reasonable to go with this approach and consider QEMU to be a machine.
So add a MACH_QEMU option. For now nothing uses it.
Signed-off-by: Simon Glass <sjg@chromium.org>
When a device type is not supported by U-Boot it is silently ignored.
Add some debugging for this.
Also show the driver features to provide a fuller picture of feature
negotiation.
Series-to: concept
Cover-letter:
virtio: Add support for virtio-scsi
It is often possible to use virtio-blk for block devices, but it is
less flexible than SCSI. SCSI provides a means to probe for multiple
disks through the same interface. It also supports hotplug and other
features.
This series adds a simple virtio-scsi driver for use with QEMU. The new
driver creates a SCSI bus when the virtio buses are scanned. That can be
scanned in turn, using 'scsi scan', to find the available virtio disks.
For this to work, quite a few minor updates are needed in the SCSI
implementation:
- Increase the buffer sizes for commands and sense buffer
- Fix off-by-one error when scanning for devices
- Use REPORT LUN to determine what LUNs are present for a target
- Clean up some open-coded constants
- Make use of a struct to decode the IDENTIFY response
- Clean up of the confusing and error-prone SCSI read/write functions
- Add support for using a scsi disk to the build-qemu/efi scripts
When a SCSI disk is inaccessible (e.g. the LUN is wrong), this is seldom
reported as an error. For example 'part list' does not say 'read error'
but 'unsupported partition type'. Probing the block device results in
each partition-type driver reading blocks, none of which reports the
error. So an attempt is made here to clean this up, so that bad LUNs
show an error.
Another clean-up is to show partition numbers in hex with 'part list',
since the current approach conflicts with the 'part' command.
Some additional x86 debugging is added for the jump from SPL to U-Boot
proper, since this can be confusing when it fails in QEMU.
With all of the above, virtio-scsi can be used on qemu-x86_64 for
loading an OS and associated files, including with standard boot.
END
Signed-off-by: Simon Glass <sjg@chromium.org>
This feature can be useful where the host wants to provide more than one
block device, since it allows all of them to be under one virtio device.
Add an implementation of virtio-scsi
Series-to: concept
Cover-letter:
virtio: Support SCSI over virtio
U-Boot supports virtio-blk and in most cases this is sufficient for
providing access to a disk. However some larger users such as LXD prefer
virtio-scsi since it groups disks together and provides unified probing
of devices.
This series implements this protocol.
END
Signed-off-by: Simon Glass <sjg@chromium.org>
The file include/uapi/linux/virtio_scsi.h contains some useful
definitions for virtio-scsi so bring this in from Linux v6.15
Signed-off-by: Simon Glass <sjg@chromium.org>
The current logic is fairly confusing. We always add to_read to start
and we always subtract it from blks. Even the place where blks is set to
0 is really just subtracting to_read.
So move these additions and subtractions out of the if() logic and to
the end of the loop. This is much easier to follow.
Signed-off-by: Simon Glass <sjg@chromium.org>
Each time around the loop a certain number of blocks are processed. Put
this in a variable (to_read/to_write) and avoid changing the input
parameter
Signed-off-by: Simon Glass <sjg@chromium.org>
The current code never returns an error if something goes wrong. While
it is normally useful to return the number of blocks processed, when
nothing is read/written at all, there is clearly something wrong.
Update the logic to return -EIO in this case.
Avoid changing blkcnt since it is an input parameter and this is
confusing.
Signed-off-by: Simon Glass <sjg@chromium.org>
Newer SCSI controllers handle the LUN in a different place from the SCSI
command. Detect this and adjust the command accordingly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Rather than doing the same shift operation each time, create a function
which writes in the correct command and the LUN. This will allows us to
handle newer controllers which do not want the LUN in the command.
Fix checkpatch warnings about CONFIG_SYS_64BIT_LBA while here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use if() for this condition. Adjust scsi_setup_read16() to use a
standard unaligned access to avoid shifting more than 32 on a 32-bit
architecture (which produces a compiler warning).
Signed-off-by: Simon Glass <sjg@chromium.org>
The word 'block_dev' suggests it is a device, but this struct is not the
device (now that we use driver model), only some information about it.
We use desc (for descriptor) elsewhere in the code, so update scsi to do
the same.
Signed-off-by: Simon Glass <sjg@chromium.org>
