Since newer kernels work just fine with older images, at
least within the same Raspbian release, there is no point
in keeping old ones around.
Drop all kernels (along with the corresponding patches and
configuration files) except for the newest one for each
Raspbian release.
Just like the unversioned configuration file is used
unless a more specific version is requested, and in particular
every time the latest kernel is built, it makes sense that
the patch would have the same behavior.
This avoid the awkward situation where, as it happened when
introducing 4.14.79, a new file is introduced despite the
previous version of the patch being applicable as-is.
Going forward, creating a named patch file will only be
necessary when adding support for a new major release of
Raspbian.
Fished out of commit aeb4259501.
Together, these allow to rebuild kernel-qemu-4.4.34-jessie
from the raspberrypi-kernel_1.20161125-1 tag by simply
pointing build-kernel-qemu to it.
CONFIG_CROSS_COMPILE is the only dynamic part of the
configuration, so we can move the rest to a separate file.
In addition to making the script nicer, this also allows
us to store more than one configuration at a time.
The configuration is not dynamic, so we can simply store it
separately and concatenate it to the configuration file, like
we already do with the networking stuff.
When building old kernels, the .dtb file will not be
generated, resulting in an error when we attempt to copy it.
Solve this by only copying the .dtb file if it actually
exists.
When building on machines with more than 4 cores, the current
script would not fully utilize the available resources.
Use `nproc` to dynamically figure out the optimal number of
build jobs for the current machine.
The most recent kernel, kernel-qemu-4.14.79-stretch, added
by commit 36b2f35699, is built from the
raspberrypi-kernel_1.20181112-1 tag.
Update build-kernel-qemu accordingly.
libvirt 5.0.0 supports ARMv6 guests and, as of commit
e362b8bbd4, the kernel built using the scripts in this
repository can drive all the virtual hardware in such a guest.
Provide some instructions on how to use libvirt instead of
spawning QEMU directly.
Note that, while VirtIO RNG support is not yet available in any
of the pre-built kernel images, the corresponding configuration
toggles have been enabled in commit 4938f7a626, so the next
time a kernel image is built they will be picked up. Given that,
it makes sense to start adding the device to guests right away.
This turns the README file, which is usually the first piece
of documentation users will see, into a fully self-contained
quick start guide.
The document is also split into several sections, which makes
it easier to navigate, and reflowed for more convenient editing.
When emulating a Raspberry Pi with QEMU, we don't actually
emulate the very exact hardware, but rather approximate it
using the versatilepb board instead.
The board comes with a built-in SCSI controller and network
interface, but it also has a standard PCI bus which allows
us to add more devices. For example, we can replace the
built-in devices with the VirtIO equivalent; however, driving
them requires support to be built into the kernel.
With a kernel build containing this patch and a build of
libvirt that contains commit 96d62d9721af, it's finally
possible to ditch custom QEMU launcher scripts, import a
vanilla Raspbian image using something along the lines of
$ virt-install \
--name pi \
--arch armv6l \
--machine versatilepb \
--cpu arm1176 \
--vcpus 1 \
--memory 256 \
--import \
--disk .../pi.raw,format=raw,bus=virtio \
--network default,model=virtio \
--video vga \
--graphics spice \
--channel name=org.qemu.guest_agent.0,char_type=unix \
--boot 'kernel=.../pi.kernel,dtb=.../pi.dtb,kernel_args=root=/dev/vda2'
and manage the emulated Raspberry Pi using the usual tools
such as virt-manager and virsh.
Dhruv Vyas
Niklas Salmoukas
Wes Chow
Valerio Pilo
Andrea Bolognani
Alex Williams
DDoSolitary
mettacrawler
Jeremy Lainé
CuriousTommy
Vilnius Ramanauskas
Isaac
H. Pitkala