Using KERNEL made sense when all boards had different kernel configuration.
Now that all of them are using GENERIC use the board name instead
Reviewed by: gjb
Differential Revision: https://reviews.freebsd.org/D16512
This produce a generic sdcard image using armv7 GENERIC kernel that
just need some u-boot (or none if the board have u-boot or a SPI flash
for example).
Reviewed by: imp, gjb
Differential Revision: https://reviews.freebsd.org/D16410
They were added for unclear reasons in r277263. The current OpenSSH
defaults (7.5+) are reasonable, and do not include the insecure rc4 cipher:
chacha20-poly1305@openssh.com,
aes128-ctr,aes192-ctr,aes256-ctr,
aes128-gcm@openssh.com,aes256-gcm@openssh.com,
aes128-cbc,aes192-cbc,aes256-cbc
I think I recall there being a reason for a specific list of ciphers on GCE
at the time, but I do not recall what it was, and cannot find any
current GCE documentation of such a list.
So, just revert the explicit configuration and use sane openssh defaults.
PR: 230092
Submitted by: Gustavo Scalet <gustavo.scalet AT collabora.com>
MFC after: 3 days
Security: yes
This config never worked. At no time did u-boot match the kenrel match
the userland. As all the GUMSTIX gear we support is quite old and/or
not working, remove it. The duovero stuff might work, but nobody
has the hardware for it and GUMSTIX hasn't sold it in years.
The change made in r336593 assumes that the build is happening in a
svn checkout resulting in misleading debug output. Check that we're
actually working in an svn checkout before proceeding to call svn.
This is needed with new u-boot that uses the rpi-firmware dtbs.
Reviewed by: gjb
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D16240
This reduce the per-board arm_install_uboot to just install u-boot.
While here remove the installation of rpi.dtb and rpi2.dtb as we load
them from the UFS partition via ubldr.
Reviewed by: gjb, imp (older version)
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D16239
and revision number announced in SNS notifications about new EC2 AMIs.
While I'm here, incorporate that information into the AMI "description"
fields, since it's more useful than simply echoing the information
already provided via the AMI "name".
Approved by: gjb
the system to make use of USB device mode / USB OTG to provide a "virtual
serial port" on release images.
Reviewed by: gjb@
MFC after: 2 weeks
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D15602
than $4. Introduce $BASEBITSDIR for clarity and to avoid repeating this
mistake in the future. Fixing this ensures that we pick up newly built
boot bits native to the target rather for/from the host.
- Apply some of the argument quoting fixes done in r287635 but missing in
later revisions.
A good number of BIOSes have trouble booting from GPT in non-UEFI mode.
This is commonly reported with Lenovo desktops and laptops (including
X220, X230, T430, and E31) and Dell systems. Although UEFI is the
preferred amd64 boot method on recent hardware, older hardware does not
support UEFI, a user may wish to boot via BIOS/CSM, and some systems
that support UEFI fail to boot FreeBSD via UEFI (such as an old
AMD FX-6100 that I have).
With this change amd64 memsticks remain dual-mode (booting from either
UEFI or CSM); the partitioning type is just switched from GPT to MBR.
The "vestigial swap partition" in the GPT scheme was added in r265017 to
work around some issue with loader's GPT support, so we should not need
it when using MBR.
There is some concern that future UEFI systems may not boot from MBR,
but I am not aware of any today. In any case the likely path forward
for our installers is to migrate to CD/USB combo images, and if it
becomes necessary introduce a separate memstick specifically for the
MBR BIOS/CSM case.
PR: 227954
Reviewed by: gjb, imp, tsoome
MFC after: 3 days
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D15599
switch the default kldxref_enable to YES.
The reason is that it's required for every image that's being cross-built,
as kldxref(8) cannot handle files for non-native architectures. For the
one that is not - amd64 - having it on by default doesn't change anything;
the script is noop if the linker.hints already exists.
MFC after: 2 weeks
Sponsored by: DARPA, AFRL
boot1.efi have some trouble to read MBR partitions, it needs them to be
aligned a certain way while loader.efi can cope with them either way.
We want to switch to loader.efi as the main efi loader everywhere, it seems
that arm64 using MBR partition will be the guinea pig.
Tested On: RPI3, Pine64
Reviewed by: imp
Approved by: gjb
RPI* 32bits and RPI* 64bits have a different config.txt
Copy to correct config.txt to the fat partition of the release image.
Also copy pwm.dtbo as some people want to use it.
Reviewed by: gjb
r332674 raised the size of the FAT partition from 2MB to 41MB for some
boards. But we format them in FAT12 and this size appears to be to big
for FAT12 and some SoC bootrom cannot cope with that.
Format the msdosfs partition as FAT16,
PR: 228285
MFC after: soon
the /boot/kernel/linker.hints file, which breaks loading some of the modules
with dependencies, eg cfiscsi.ko.
This is a minimal fix for ARM images, in order to safely MFC it before
11.2-RELEASE. Afterwards, however, I believe we should actually just change
the default (as in, etc/defaults/rc.conf). The reason is that it's required
for every image that's being cross-built, as kldxref(1) cannot handle files
for non-native architectures. For the one that is not - amd64 - having it
on by default doesn't change anything - the script is noop if the linker.hints
already exists.
The long-term solution would be to rewrite kldxref(1) to handle other
architectures, and generate linker.hints at build time.
Reviewed by: gjb@
MFC after: 3 days
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D14534
will include license metadata in the resultant GCE image.
GCE_LICENSE is unset by default, as it primarily pertains to images
produced by the FreeBSD Project, but for downstream FreeBSD consumers,
it can be set in the make(1) environment in the format of:
--licenses="projects/PROJECT_ID/global/licenses/LICENSE_NAME"
The "license" is not a license, per se, but required metadata that
is required by the GCE marketplace. For the FreeBSD Project, the
license name is simply 'freebsd', with the description of 'FreeBSD'.
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
satisfying a requirement to allow FreeBSD to be considered
a top-tier supported OS in Google Compute Engine.
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Recent changes to makefs and mkimg have led to situations where the
disconnect between this script and the versions installed on the host cause
failures. Provide a way to work around this that doesn't require the
installation of new versions to the host system if that's not desired.
With this change mkisoimages.sh will honour the $ETDUMP, $MAKEFS and $MKIMG
environment variables but fall back to the previous behaviour of finding them
within $PATH.
Reviewed by: gjb
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D15181
current size may not be sufficiently large for development and/or
testing.
PR: 227548
Submitted by: trasz
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
EC2 instances from sysctl.conf to loader.conf; these can all be set as
loader tunables, and setting them in loader.conf gives us the right
behaviour in the event of a kernel panic taking place prior to when
sysctl.conf is processed.
MFC after: 1 week
This keeps the existing El Torito entries for BIOS and UEFI boot code and
adds a GPT in the ISO image's System Area containing boot code for BIOS that
will load /boot/loader from the ISO filesystem and execute it. We then use
etdump to find the EFI System Partition image in the El Torito catalog and
add an entry to the GPT that allows EFI to find it.
Reviewed by: gjb, imp
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D15051
Some BIOSes have trouble booting from GPT in non-UEFI mode. This is
commonly reported with Lenovo laptops, including my x220. As we do not
currently support booting FreeBSD/i386 via UEFI there's no reason to
prefer GPT.
The "vestigial swap partition" was added in r265017 to work around an
issue with loader's GPT support, so we should not need it when using
MBR.
We may want to make the same change to amd64, although the issue there is
mitigated by such systems booting via UEFI in the common case.
PR: 227422
Reviewed by: gjb
MFC after: 3 weeks
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
This makes it easier to identify the individual partition types and
facilitates comparisons across architectures.
Reviewed by: gjb
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
have moved from the u-boot-rpi3 share directory to the default
rpi-firmware share directory. Remove the files from UBOOT_FILES
and append the DTB file to a DTB_FILES list so the correct path
is used, fixing a build failure.
Sponsored by: The FreeBSD Foundation
This allows for GCE consumers to easily detect the latest major
version of FreeBSD when using the gcloud command line utility.
To ensure snapshot builds do not conflict with release-style
builds (ALPHA, BETA, RC, RELEASE), the '-snap' suffix is appended
to the GCE image family name.
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Latest u-boot update need u-boot script to load and start ubldr.
(See D14230 for more details)
Copy this file for our arm release on the fat partition.
Approved by: gjb
UEFI booting requires an EFI System Partition (ESP). On most storage devices
this will be in a specific partition type. To allow booting from CD/ISO
filesystems, UEFI will look for an ESP in the form of a FAT filesystem image
embedded in the image. Historically FreeBSD has added one of these to its
amd64 ISO images but marked it as simply another i386 boot image. Luckily for
us most UEFI implementations are rather forgiving and work this out for us.
This change adds the ability to mark a boot image as being a UEFI image. It
also modifies our ISO generation to use this marking for the UEFI image we
embed.
Reported by: Thomas Schmitt <scdbackup@gmx.net>
Reviewed by: emaste, imp
MFC after: 1 week
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D14809
kernel.ucl uses a hardcoded boot/kernel for kldxref, which is the incorrect
directory when we're installing extra kernels that aren't the "default"
kernel (placed at boot/kernel).
Fix this by instead using a new %KERNELDIR% that we now replace in
Makefile.inc1 with "kernel" for the default kernel and "kernel.${_kernel}"
for these extra kernels so that, e.g. /boot/kernel.SHIVA, will get properly
kldxref'd upon update and avoid outdated linker.hints.
Reviewed by: gjb
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D14689
providing more space for a local buildworld to succeed without
attaching separate disks for /usr/src and /usr/obj.
Reported by: mckusick
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
The Pine64 root filesystem was incorrectly created directly on the MBR
partition. This can cause the loader to get confused when loading the
kernel from this filesystem.
The loader will see this as a small partition meaning later checks to
ensure it doesn't read past the end of the disk incorrectly report a
failure. This seems to work mostly by accident with the released images as
they are smaller than the reported size, however after growfs has run the
image may no longer boot.
Reviewed by: gjb, emaste, imp
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D14343
