Currently the partition layout is hardcoded to create an EFI/FAT
partition and a UFS root partition, with some logic to handle GPT/MBR
differences.
On RISC-V platforms we are seeing the emerging pattern that firmware
should be placed in a partition of a known type, rather than just a
known sector of the disk. Thus, some functionality is needed to
customize the layout for SD card images.
Add a hook, arm_create_partitions(), which can be overridden to insert
additional platform-specific partitions, possibly preceding the standard
EFI and UFS ones. A couple of new variables are added to track the
indices, e.g. ROOTFSPART_SUFFIX=p2.
In a couple places this de-duplicates the GPT/MBR logic.
Reviewed by: manu, karels, imp
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D43848
These days, the entries are the identical for GPT and MBR.
Reviewed by: manu, karels, imp
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D43847
Most 64-bit Raspberry Pi models have a variable processor clock
speed that defaults to a slow speed (e.g. 600 MHz for a nominal
1.5 GHz clock). This results in everything running slowly unless
or until powerd is started, and FreeBSD is then thought to be slow.
Enable powerd by default in /etc/rc.conf on the arm64-aarch64-RPI
images. Tested on Raspberry Pi 3B+ and 4B so far.
PR: 256836
MFC after: 1 month
Reviewed by: rgrimes
Differential Revision: https://reviews.freebsd.org/D43296
When building ARM release images, enable IPv6 SLAAC by default in
addition to IPv4 DHCP.
Unlike amd64 (and other desktop/server) releases, ARM releases on SoC
setups are usually deployed by just using the installation image, so
there is no interactive network configuration. Not having IPv6
included by default is kind of an anachronism these days, given that
FreeBSD with the KAME project once pioneered IPv6 technology.
MFC after: 2 weeks
We need to do a relative link to efi instead of an absolute link into
the build tree.
Sponsored by: Netflix
Reviewed by: gjb
Differential Revision: https://reviews.freebsd.org/D36941
Traditionally, we've used /boot/msdos for the MBR mount point for the SD
images that we produced. For GPT and bsdinstall, we've used
/boot/efi. Migrate to using /boot/efi for MBR as well and add a
/boot/msdos -> /boot/efi symlink for compatibility (which may disappear
before 14.0, but will remain on the stable branches).
When we first created the arm images, there was no EFI booting and the
FAT partion on an MBR image was used to hold the firmware, uboot.bin,
SoC config files and ubldr. When we transitioned to uboot with EFI, we
put the loader files in the same partition. Later we standardized on
/boot/efi at about the same time we added GPT support to the RE produced
images. We left the MRB case as /boot/msdos for legacy reasons and since
it wasn't always EFI. Later, we dropped support of non-EFI booting on
the RE produced images, so the duality of /boot/msdos diminished even
more. Since so little secondary meaning remains, putting it all in
/boot/efi standardizes the location and reflects the RE images
better as using efi-only booting.
In addition, always label the msdosfs partion 'efi'. While a small
misnomer on some systems that store other files in the ESP, it was
requested in review for more consistency for similar reasons to the
mountpoint rename. There was no way to have an 'alias' or 'second label'
here, so this breaks compatibility. Since the images are self-contained,
this was judged to be an acceptable change.
Sponsored by: Netflix
Reviewed by: manu, allanjude, emaste, gjb
Differential Revision: https://reviews.freebsd.org/D36635
We do not want CHS-based alignment for VM or SD card release images.
(Other images use makefs/mkimg, not kernel gpart and so do not depend
on this sysctl.)
Sponsored by: The FreeBSD Foundation
Approved by: re (gjb)
MFC after: 1 week
ubldr.bin was obsoleted by our uboot ports last year, so this is
completely unused in the default config (some customers still use
it, but that's not relevant to this script). Don't copy it at all
since it won't be used for re@ produced images.
Sponsored by: Netflix
Reviewed by: kevans, gjb (re@)
Differential Revision: https://reviews.freebsd.org/D34192
Per [(1), i.e. test(1), the string comparison operator should be `=`,
not `==` in sh(1) scripts.
No functional change. FreeBSD's test accepts `==` as an alias for `=`
for compatibility with gnu test's `==` extension.
Reviewed by: imp@, gjb@
Pull Request: https://github.com/freebsd/freebsd-src/pull/485
Remove tmpfs size limitation, this breaks make installworld and installation of some packages
Format generated fstab using tabs to make it consistent and readable
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D29283
This had prevented the bootconfig step from determining if an ESP exists,
resulting in its unconditional setup. On BIOS-booted amd64, this wasn't
harmful, just unnecessary, but it resulted in failed installations on
non-EFI-supporting platforms like powerpc64.
MFC after: 3 days
Since the few existing RISC-V hardware platforms are single board
computers, we can piggyback off of arm/arm64's embedded build support
for generating SD card images.
I don't see a pressing need to change the naming in this file at this
time.
Reviewed by: gjb, manu
Differential Revision: https://reviews.freebsd.org/D27043
SRC_CONF, __MAKE_CONF and SRCCONF, respectively) through
to arm_install_base() and chroot_arm_build_release().
This prevents failures when the target image is intended
to be build with make.conf(5) and src.conf(5) overrides,
which are correctly handled for non-embedded image builds.
Reported and tested by: Daniel Engberg
PR: 238615
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Add a configuration for PINEBOOK image.
Pinebook is a arm64 laptop based on a Pine64 board.
Since the usb trackpad need a quirk, add a common function for adding
quirk for arm board.
A default one is supplied as most board to not need quirks.
Reviewed by: gjb
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D18337
lualoader has moved to a model where the user is expected to disable color
as desired, rather than disabling it automatically for serial boots, due to
more wide-spread support for color sequences.
In a similar vain, though also to reduce special cases, lualoader no
longer disables the beastie menu automatically for !x86. This was done in
Forth land with a different loader.rc that simply didn't invoke the menu
routines, thus wasn't necessary.
This set of changes puts release images back to how they would've been
experienced prior to the switch to Lua.
Approved by: re (rgrimes)
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
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
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
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
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
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
build on arm/armv6 images.
Pointyhat: gjb (myself)
MFC after: immediate
MFC note: releng/10.4 has broken because of this
Sponsored by: The FreeBSD Foundation
virtual machine images and embedded images, similar to what is
done when extracting base.txz to the target root filesystem in
an new installation.
Noticed by: marius
Tested with: head@r323729
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
- Rename chroot_arm_armv6_build_release() to chroot_arm_build_release()
and make it hardware agnostic (such as armv6 -vs- armv7 -vs- arm64).
- Evaluate EMBEDDED_TARGET differently so release/tools/arm.subr can
be used for arm/armv6 and arm64/aarch64.
- Update comments and copyright.
In release/tools/arm.subr:
- In arm_create_disk(), change the default alignment from 63 to 512k,
fixing a boot issue on arm64 and EFI. [1]
- Update comments and copyright.
Add a RPI3 configuration file, pieces obtained from Crochet.
Obtained from: Crochet [1]
MFC after: 5 days
X-MFC-Note: maybe
Sponsored by: The FreeBSD Foundation
30m isn't enough for pkg anymore to extract packagesite.txz.
40m is fine for now but let's take a safer way as we don't know when pkg will need more.
Reported by: many
Approved by: re (gjb), andrew (mentor)
on performance, especially with SD cards on certain SoCs.
Requested by: trasz
Discussed with: ian, kientzle
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
A stray trailing space snuck in with one of the recent
changes, making r290550 and r290573 effectively no-op.
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
The true cause of the missing UFS/MSDOSFS labels has been
identified, and only affects stable/10 at the moment.
An request for commit to stable/10 will be pending RE approval
after this commit.
MFC after: 1 day
X-MFC-Note: never
X-MFC-Never: r285018, r285019, r285076, r285078, r285082
Sponsored by: The FreeBSD Foundation
the symlink from loader.rc.sample.
Fix paths relative to the CHROOTDIR.
MFC after: 3 days
X-MFC-With: r285076, r285078
X-MFC-Before: 10.2-BETA1
Sponsored by: The FreeBSD Foundation
UFS/MSDOSFS label issues on FreeBSD/arm builds, however
the real problem was addressed in r285076, which is due
to two separate issues, unrelated to md(4) stale device
existence.
MFC after: 3 days
X-MFC-With: r285076
X-MFC-Before: 10.2-BETA1
Sponsored by: The FreeBSD Foundation
FreeBSD/arm builds. The problem stems from the loader.rc file
not existing, as well as geom_label not being loaded at boot.
For now, add the geom_label_load entry to loader.conf, and
symlink loader.rc.sample to loader.rc, both of which allowed
my BeagleBone Black to boot fine with a UFS label reference in
fstab(5).
MFC after: 3 days
X-MFC-Before: 10.2-BETA1
Sponsored by: The FreeBSD Foundation
cannot possibly exist within the chroot(8) before the target
filesystem actually exists.
MFC after: 3 days
X-MFC-With: r285018
Sponsored by: The FreeBSD Foundation
written to disk with newfs(8) and newfs_msdosfs(8).
When iterating through snapshot builds in serial, it is possible for
a build failure to leave stale md(4) devices behind, in some cases, they
could have a UFS or MSDOS filesystem label assigned.
If the md(4) is not destroyed (or not able to be destroyed, as has
happened recently due to my own fault), the filesystem label that
already exists can interfere with a new md(4) device that is targeted to
have the same label.
This behavior, although admittedly a logic error in the wrapper build
scripts, has caused intermittent reports (in particular with the armv6
builds) of missing UFS/MSDOSFS labels, causing the image to fallback to
the mountroot prompt. This appears to only happen when the backing
md(4) device is destroyed before the calling umount(8) on the target
mount, after which the UFS/MSDOSFS label persists.
The workaround is this: If EVERYTHINGISFINE is set to non-empty value,
check for an existing ufs/rootfs and msdosfs/MSDOSBOOT filesystem label
in arm_create_disk(), and rm(1) them if they exist.
The EVERYTHINGISFINE variable is chosen because it is used in exactly
one other place - release/Makefile.mirrors - and there are big scary
warnings at the top of that file as well that it should *not* be used
under normal circumstances. This should not destroy a build machine
that also uses '/dev/ufs/rootfs' as the UFS label, and I have verified
in extensive local testing that the destroyed label is recreated when
the md(4) is unmounted/mounted, but this really should not be enabled
by anyone.
Having said all that, I absolutely *do* plan MFC this to stable/10 for
the 10.2-RELEASE cycle, as so far, I have only observed this behavior
on stable/10, but this is a temporary solution until I can unravel all
of the failure paths to properly trap them.
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
According to the manual page, '-m' should create the user home
directory, however rigorous testing suggests it does not, and
it is unclear if this is an implementation or expectation issue.
Sponsored by: The FreeBSD Foundation
