The previous commit introduced the ability to install a set of
bootable images as a normal part of a release build. While this made
it easy to install bootable images, the contents of a release build
depend on whether or not U-Boot packages are installed in /usr/pkgsrc,
which is the default location searched by installboot(8).
This commit requires users to explicitly list the bootable images to
be installed, which by default is none (i.e., prior behavior).
Release builds for arm platforms create compressed images in
${RELEASEDIR}/${RELEASEMACHINEDIR}/binary/gzimg. However, in some
cases, e.g., armv7.img.gz, they are not bootable. Consequently, boot
blocks must be manually installed in the images, which is an extra
barrier for testing systems or adopting NetBSD. This has prompted
creation of external repositories, e.g., armbsd.org, to host a
collection of bootable images. However, this does not ease the burden
on developers compiling their own systems; for them, manual
installation of boot blocks is still required.
For arm platforms, etc/etc.evbarm/Makefile.inc contains the commands
used to create system images. Because installboot(8) can write boot
blocks directly to system images, a loop through possible boards can
create a series of bootable images during the normal build process.
In the case of many arm platforms, installboot(8) uses U-Boot boot
blocks, which are not part of the NetBSD source code. Developers can,
however, install as many U-Boot boot blocks as desired, either in the
default location of /usr/pkg/share/u-boot or in a set of directories
pointed to by the U-Boot search path, the INSTALLBOOT_UBOOT_PATHS
environment variable. For each board with an available boot block, a
board-specific bootable image will be created in
${RELEASEDIR}/${RELEASEMACHINEDIR}/binary/gzimg. If a boot block is
not available, which is the typical situation currently, no additional
image will be created.
This facility creates opportunities to build bootable images for any
number of boards within the scope of a standard release build.
However, that is not required and will not occur without the
intervention of installing U-Boot boot blocks prior to the build.
viocon* at virtio?
/dev/ttyVI??
Tested under qemu with:
qemu-system-aarch64 ... \
-device virtio-serial \
-chardev socket,path=/tmp/ttyVI00,server=on,wait=off,id=ttyVI00 \
-device virtconsole,chardev=ttyVI00,name=org.NetBSD.dev.ttyVI00 \
...
I updated MAKEDEV.conf to create /dev/ttyVI?? on all ports where it
looks likely to work based on:
(a) having pci or a non-pci virtio attachment,
(b) `qemu-system-$ARCH -M ?' mentioned something resembling the port,
and
(c) `qemu-system-$ARCH -device virtio-serial' launched without
complaining about the virtio-serial device.
(Criterion (c) excluded sparc and sparc64.)
It works --- except for:
- mvsata(4) problems (already reported repeatedly)
- NFS root with mvgbe(4) is weird; the system eventually locks up
Yes, we need to fix them...
Introduce a /dev/efi character device that provides a means for accessing
UEFI RT variable services from userland. Compatible with the FreeBSD ioctl
interface for ease of porting their libefivar and associated tools.
The ioctl interface is defined in sys/efiio.h.
To enable support for this on an arch, the kernel needs `pseudo-device efi`
and the MD EFI implementation needs to register its backend by calling
efi_ops_register(). This commit includes an implementation for Arm.
With this switch processes (such as xconsole) can open /dev/console
without breaking login on the text or serial console. This can be
trivially triggered by enabling xdm in rc.conf and hitting
Ctrl+Alt+F1 or equivalent once booted.
The changes:
- Add entry for /dev/console or /dev/constty if missing
- If a port's had /dev/console 'on' switch it off and enable /dev/constty
- If a port did not have /dev/console 'on', leave /dev/constty off
Some ports had /dev/console off and /dev/ttyE0 enabled, presumably to
avoid just this issue. It may make sense to adjust these also (but not
in this pass)
As discussed on current-users
is of poor quality, and is now an obstacle to MP-ification. It was removed
ten years ago from FreeBSD for the same reason.
This retires a big user of the mbuf API, and will ease maintenance of the
kernel.
- sys/arch/evbarm64 is gone and integrated into sys/arch/evbarm. (by skrll@)
- add support fdt. evbarm/conf/GENERIC64 fdt (bcm2837,sunxi,tegra) based generic 64bit kernel config. (by skrll@, jmcneill@)
skrll