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.
Remove support for building extsrc/:
1. Makefile: remove do-extsrc target.
2. build.sh: remove options -y and -Y extsrcdir.
3. distrib/sets: remove support for extsrc in various tools
including the options -L ext and -y, and the extsrc sets.
4. doc/BUILDING.mdoc: remove docs for extsrc/, EXTSRCSRCDIR, MKEXTSRC (etc)
5. bsd.own.mk and various Makefiles: remove support for extsrc/,
EXTSRCSRCDIR, MKEXTSRC.
As proposed on tech-kern and tech-userlevel on 2022-01-07
and followed up on 2022-08-21.
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.)
Note that realpath can act differently for root than for other users
(where an ordinary user will see EACCESS root just barrels right through).
The tests adapt themselves, when run as root, less error cases can be
tested than when run as some other user.
in /etc/conf/raid/raidN (as well as in /etc/raidN.conf) (less
clutter in /etc).
Allow config files to exist for raids that are autoconfigured (just
skip anything autoconfigured) - this allows a (simplistic) recovery
mechanism if autoconf fails, and makes it simpler to enable/disable
autoconf at will, while keeping the raid working.
While here, add sh quoting where it is needed, and remove it from
where it is pointless.
unless changed by something - and has been since NetBSD 3) don't blindly
simply change it to a PATH that doesn't have /rescue in it at all.
This doesn't solve the "/rescue/tar execs /usr/bin/gzip" problem completely,
as if PATH is in the environment when /rescue/sh is started, that one will
override the shell's built in PATH, but this is better than nothing.
allow conditionally disabling the building of certain user space
programs in the 'base' set.
There is not enough consensus that this is the right way and a few
people had strong objections, see source-changes-d@.
strictly-aligned versions of memcmp(3), bcopy(3), memcpy(3), and
memmove(3).
This is used for 403 by ld.so.conf with machdep.no_unaligned variable.
With this library, unaligned memory accesses are significantly reduced
for 403 (from several hundreds to few tens per sec under heavy load);
only ld.elf_so (typically few times per fork) and statically-linked
binaries do such access.
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...
Now that we have WSDISPLAYIO_LISTFONTS we want users to be able to use it.
NB: older kernels didn't check that WSDISPLAYIO_LDFONT was performed
on wsfont(4) device opened for writing and relied on its restrictive
root-only permissions to restrict who can load fonts.
created if it actualy did create keys (one should thing that a
function called sshd_keygen() only is called to create keys, but
the "precmd" magic makes it run every time sshd is started or stopped).
Patch from Tom Lane, with modifications suggested by kre and a minor
additional cosemtic change.
radeon has different case but same name firmware files. the lower case
ones are already installed into /libdata/firmware, and to avoid having
to provide some special method to build on systems with case-preserving
file systems (such as macOS), we install the lower case ones in /usr.
this means that anyone that requires the lower case files must either
have /usr as part of the / file system, or manually keep them updated.
last part of PR#54976, though i doubt we'll try to pull up these.
this is enabled on i386, amd64 and arm64.
first character in /etc/gpio.conf and have the rest evaluated in a
shell. It is useful to be able to do actions after setting up gpio
pins or attaching gpioiic(4).
These tests run two threads for five seconds each to try to trigger
races in the event of broken memory barriers. They run only on
machines with at least two CPUs; on uniprocessor systems there's no
point -- the membars can correctly just be (instruction barrier)
no-ops.
that "continue" is a command as intended, and not an invalid last arg to
the '[' command (the last arg is required to be ']').
Sometime the proverbial someone should go through this and remove all the
obsolete test -o and -a operators, and probably do something with test's
usage of ! as well. Not today, or not by me anyway.
in the kernel sets. Having the .gdb kernels in the EXTRA_KERNELS does not
work, since we only walk through the standard kernels in the Makefile. Also
doing DEBUG=-g in config twice does not hurt.
as the name implies, includes a netbsd.gdb inside each kernel set:
$ tar -tzvf kern-GENERIC.tgz
-rwxr-xr-x 0 root wheel 29398264 Dec 19 12:50 ./netbsd
-rwxr-xr-x 0 root wheel 208125880 Dec 19 12:50 ./netbsd.gdb
Symlinks inferred from linux-firmware/WHENCE and compared to a linux distro's
firmware.
Note: said linux distro appears to have some mistakes compared to the
linux-firmware repo in linking ucode_unload.bin to unload_bl.bin and vice
versa in some places.
I didn't replicate this aspect, and lack the hardware to test it.
Driver module as illustrated here:
https://www.sparkfun.com/products/13911
A SCMD module is a ARM SOC simular to a Arduino in front of a motor
driver chip. The single SCMD module can control two motors and up to
16 additional modules can be chained together using an internal I2C
bus. One can interface with the SCMD using tty uart commands, SPI or
I2C. The driver in this commit adds a kernel driver for the I2C and
SPI interfaces. The command line utility provides a set of
convenience commands that support most of the functions of the SCMD
and is able to use the tty uart mode, SPI user land or the included
kernel driver in a uniform manor.
The use of the SCMD module is mostly for small robots and the like,
but it can control anything that is controllable by voltage.
brook