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>
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>
Provide access to the virtual queue and some functions for sending
various FUSE messages.
Add myself as a maintainer of virtio.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present virtio devices are acknowleged when bound. This results in a
call to virtio_set_status() which uses device-private data in several
cases, e.g. in virtio_pci_get_status()
This data is only allocated when the device is probed, so the access is
either ignored (on QEMU) or results in a crash (on sandbox).
Acknowledging the device so early does not seem to be necessary. Move it
to the pre-probe function instead. Update the test to match. We now have
no coverage to check that VIRTIO_CONFIG_S_ACKNOWLEDGE was actually set.
If we later find it necessary to acknowledge the device while binding,
we can update the uclass and drivers to use plat data instead of priv.
Signed-off-by: Simon Glass <sjg@chromium.org>
As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.
This reverts commit c8ffd1356d, reversing
changes made to 2ee6f3a5f7.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
This name is a little confusing since it suggests that it sets up the
sibling block device. In fact it sets up a bootdev for it. Rename the
function to make this clearer.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
If a driver cannot be bound, provide the driver name in the debug
message. Now the debug message may look like this:
(virtio-pci.l#0): virtio-rng driver not configured
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Sometimes virtio may rely on PCI, or at least that is what the
distro_bootcmd script suggests. Add this in.
Signed-off-by: Simon Glass <sjg@chromium.org>
If we detect the VIRTIO_F_IOMMU_PLATFORM transport feature for a device,
then expose it in the device features.
Signed-off-by: Will Deacon <willdeacon@google.com>
[ Paul: pick from the Android tree. Rebase to the upstream ]
Signed-off-by: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
Link: 9693bd26bf
Reviewed-by: Simon Glass <sjg@chromium.org>
At present virtio tries to attach QEMU services to a bootdev device, which
cannot work. Add a check for this.
Also use bootdev_setup_sibling_blk() to create the bootdev device, since
it allows the correct name to be used and bootdev_get_sibling_blk() to
work as expected.
The bootdev is not created on sandbox since it does have a real virtio
device and it is not possible to read blocks.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: a60f7a3e35 ("bootstd: Add a virtio bootdev")
Reported-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
We need extensions to be set up before we start trying to boot any of the
bootdevs. Add a new priority before all the others for tht sort of thing.
Also add a 'none' option, so that the first one is not 0.
While we are here, comment enum bootdev_prio_t fully and expand the test
for the 'bootdev hunt' command.
Signed-off-by: Simon Glass <sjg@chromium.org>
This has a special meaning in driver model. There is clearly a device, so
it does not make sense to return this error code. Fix it.
Signed-off-by: Simon Glass <sjg@chromium.org>
We already have a function for probing all devices of a specific class,
use it.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Define LOG_CATEGORY for all uclass to allow filtering with
log command.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
VIRTIO_ID_MAX_NUM is the largest device ID plus 1. Therefore a device id
cannot be greater or equal to VIRTIO_ID_MAX_NUM. Fix the comparison
accordingly.
Fixes: 8fb49b4c7a ("dm: Add a new uclass driver for VirtIO transport devices")
Signed-off-by: Vincent Stehlé <vincent.stehle@laposte.net>
Cc: Simon Glass <sjg@chromium.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
At present various drivers etc. access the device's 'seq' member directly.
This makes it harder to change the meaning of that member. Change access
to go through a function instead.
The drivers/i2c/lpc32xx_i2c.c file is left unchanged for now.
Signed-off-by: Simon Glass <sjg@chromium.org>
This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.
Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present dm/device.h includes the linux-compatible features. This
requires including linux/compat.h which in turn includes a lot of headers.
One of these is malloc.h which we thus end up including in every file in
U-Boot. Apart from the inefficiency of this, it is problematic for sandbox
which needs to use the system malloc() in some files.
Move the compatibility features into a separate header file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a driver for the virtio-rng device on the qemu platform. The
device uses pci as a transport medium. The driver can be enabled with
the following configs
CONFIG_VIRTIO
CONFIG_DM_RNG
CONFIG_VIRTIO_PCI
CONFIG_VIRTIO_RNG
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
This adds a new virtio uclass driver for “virtio” [1] family of
devices that are are found in virtual environments like QEMU,
yet by design they look like physical devices to the guest.
The uclass driver provides child_pre_probe() and child_post_probe()
methods to do some common operations for virtio device drivers like
device and driver supported feature negotiation, etc.
[1] http://docs.oasis-open.org/virtio/virtio/v1.0/virtio-v1.0.pdf
Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
