to help avoid hard-coding 'python<MAJOR>.<MINOR>' in several
scripts in the client-side scripts.
PR: 230248
MFC after: 3 days
Submitted by: gustavo.scalet@collabora.com
Sponsored by: The FreeBSD Foundation
flag to bsdec2-image-upload instructing it to mark the snapshot of its
root disk as public (which is independent from marking the created AMIs
as public).
Requested by: Amazon
When booting via EFI on arm we have no way to know the dtb file to load
and we always use the one provided from the bootloader.
This works in most case but :
U-Boot have some really old DTB for some boards, the sync from Linux isn't done automatically for all boards
Some boards (like TI BeagleBone series) use one u-boot for all the model and it doesn't embed the DTBs
Some boards (like IMX6 based ones), don't embed the DTB
We want u-boot to load and patch the DTB with the mac address or the display
node enabled or not.
Reviewed by: gjb, imp
Differential Revision: https://reviews.freebsd.org/D16596
The images were renamed from KERNCONF to BOARDNAME when
specified, which would result in an image name of:
12.0-CURRENT-arm-armv7-GENERIC.img
which would then be renamed to use the BOARDNAME for the
SoC the image is targeted to use. BOARDNAME was specified
for all images as of r336994, which now causes the ftp-stage
target to fail, as the rename is no longer necessary.
Sponsored by: The FreeBSD Foundation
Pine64 isn't produced anymore but Pine64-LTS is.
This image works on the LTS release and the Sopine module.
Reviewed by: gjb
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D16487
Since we have now EFI framebuffer enabled for ARM64 if we boot on a board
with an screen, u-boot will set up a EFI GOP framebuffer and we won't boot
using the serial console.
Also on RPI3 the firmware always setup the framebuffer area resulting in u-boot
always setup the EFI GOP and FreeBSD never using the serial console.
Reviewed by: gjb, lwshu (previous version)
Differential Revision: https://reviews.freebsd.org/D16472
boot.scr is a u-boot script that loads and execute ubldr.bin
If not present u-boot will automatically boot loader.efi which
is already installed.
This means that all armv6/armv7 images are now booted via EFI
Tested-On: RPI-B
Tested-On: RPI2
Tested-On: OrangePi One
Tested-On: All lot of other boards
MFC after: Never
Relnotes: yes
This is not a problem for 12-CURRENT as EFI boot works but it doesn't
for 11.
While here some board arm_install_uboot also copy ubldr.bin et create
firstboot files but it's already done in arm_install_boot
Reviewed by: gjb
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D16481
FORCE_PKG_REGISTER is broken so multiple invocation of release.sh for the
same board will fails if /scratch isn't cleaned.
Leave it but deinstall the package first.
Reviewed by: gjb
Differential Revision: https://reviews.freebsd.org/D16513
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
