These are no longer needed after the recent 'beforebuild: depend' changes
and hooking DIRDEPS_BUILD into a subset of FAST_DEPEND which supports
skipping 'make depend'.
Sponsored by: EMC / Isilon Storage Division
I previously disconnected kgzdr based on a misunderstanding.
I'd still like to transition to supporting only the loader(8)-based
boot path for handling compressed kernels, but that can follow the
standard deprecation procedure.
This reverts r291113.
Requested by: dteske
hate adding yet another define, but it is the lessor of the evil
choices available. Kill another evil by removing PATH_BOOT3 and
replacing it with PATH_LOADER or PATH_LOADER_ZFS as appropriate.
PR: 206659
Set WARNS if not set for EFI boot code and fix the issues highlighted by
setting it.
Most components are set to WARNS level 6 with few being left at lower
levels due to the amount of changes needed to fix at higher levels.
Error types fixed:
* Missing / invalid casts
* Missing inner structs
* Unused vars
* Missing static for internal only funcs
* Missing prototypes
* Alignment changes
* Use of uninitialised vars
* Unknown pragma (intrinsic)
* Missing types etc due to missing includes
* printf formatting types
Reviewed by: emaste (in part)
MFC after: 2 weeks
X-MFC-With: r293268
Sponsored by: Multiplay
Differential Revision: https://reviews.freebsd.org/D4839
When called to early, new_currdev->d_type was not yet set
zfs_fmtdev() would then return null
While here, guard call to init_zfs_bootenv with if d_type == DEVT_ZFS
Reported by: tsoome at me.com
MFC after: 3 days
Sponsored by: ScaleEngine Inc.
Add a few other safeguards to ensure things do not break when the
boot device cannot be determined
Reported by: flo
MFC after: 3 days
Sponsored by: ScaleEngine Inc.
If the system was booted with ZFS, a new menu item (#7) appears
It contains an autogenerated list of ZFS Boot Environments
This allows the user to switch to an alternate root file system
Use Cases:
- Revert a failed upgrade
- Concurrently run different versions of FreeBSD with common home directory
- Easier integration with the sysadmin/beadm utility
Requested by: many
Reviewed by: dteske
MFC after: 10 days
Relnotes: yes
Sponsored by: ScaleEngine Inc.
Differential Revision: https://reviews.freebsd.org/D3167
magic number to use V86_CY() instead. These should have been fixed as
part of the cleanup in r226746 but were missed.
The md5 sums of the object files were unchanged, so there should be no
functional change.
PR: 205424
Submitted by: Alexander Kuleshov <kuleshovmail@gmail.com>
MFC after: 1 week
pxeboot in tftp loader mode (when built with LOADER_TFTP_SUPPORT) now
prefix all the path to open with the path obtained via the option 'root-path'
directive.
This allows to be able to use the traditional content /boot out of box. Meaning
it now works pretty much like all other loaders. It simplifies hosting hosting
multiple version of FreeBSD on a tftp server.
As a consequence, pxeboot does not look anymore for a pxeboot.4th (which was
never provided)
Note: that pxeboot in tftp loader mode is not built by default.
Reviewed by: rpokala
Relnotes: yes
Sponsored by: Gandi.net
Differential Revision: https://reviews.freebsd.org/D4590
This is not properly respecting WITHOUT or ARCH dependencies in target/.
Doing so requires a massive effort to rework targets/ to do so. A
better approach will be to either include the SUBDIR Makefiles directly
and map to DIRDEPS or just dynamically lookup the SUBDIR. These lose
the benefit of having a userland/lib, userland/libexec, etc, though and
results in a massive package. The current implementation of targets/ is
very unmaintainable.
Currently rescue/rescue and sys/modules are still not connected.
Sponsored by: EMC / Isilon Storage Division
Tracking these leads to situations where meta mode will consider the
file to be out of date if /bin/sh or /bin/ln are newer than the source
file. There's no reason for meta mode to do this as make is already
handling the rebuild dependency fine.
Sponsored by: EMC / Isilon Storage Division
This was [re-]added in r127458 (apparently with disconnected history as well)
and never connected to the build.
It is no longer relevant for modern systems from the past 20 years.
Discussed with: jhb
Sponsored by: EMC / Isilon Storage Division
bytes of boot2. Since we're in 16-bit mode, we can't copy all 128kB at
once; instead we loop four times and copy 32 kB each time.
This change was made necessary by an upcoming increase in the size of the
boot2 binary; should it increase further, the COPY_BLKS value can be
adjusted without anyone needing to remember 8086 assembly language again.
Requested by: allanjude
Tested by: allanjude
MFC after: 1 week
Go ahead and defined -D_STANDALONE for all targets (only strictly
needed for some architecture, but harmless on those it isn't required
for). Also add -msoft-float to all architectures uniformly rather
that higgley piggley like it is today.
Differential Revision: https://reviews.freebsd.org/D3496
There have been .local version of each for user modifications for some time
This allows users to receive future updates to these files
PR: 183765
Submitted by: Bertram Scharpf, Nikolai Lifanov (patch)
Reviewed by: dteske, loos, eadler
Approved by: bapt (mentor)
MFC after: 1 month
Relnotes: yes
Sponsored by: ScaleEngine Inc.
Differential Revision: https://reviews.freebsd.org/D3176
- Add prototype for boot2 main()
- Don't make assignment within if statement, split it into two.
No functional or binary change -- verified with sha256(1).
MFC after: 2 weeks
Off by default, build behaves normally.
WITH_META_MODE we get auto objdir creation, the ability to
start build from anywhere in the tree.
Still need to add real targets under targets/ to build packages.
Differential Revision: D2796
Reviewed by: brooks imp
This was not (and still is not) connected to the build, but the EFI
loader is in the process of being built for other than amd64 so these
files ought to live in their eventual MD location.
stage, just like for the regular world stage.
Reviewed by: rodrigc, imp, bapt, emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D2187
Return EINVAL instead of EFTYPE if we have a multiboot kernel loaded but
failed to load the modules. This makes it clear that the kernel/module
should be handled by the multiboot handler but something went wrong.
Sponsored by: Citrix Systems R&D
Zero the list of modules array before using it, or else we might pass
uninitialized data in unused fields of the struct that will make Xen choke.
Also add a check to make sure malloc succeeds.
Sponsored by: Citrix Systems R&D
-mno-align-long-strings when compiling with base gcc. This is checked
by comparing the version number against 4.2.1, which is not exactly
right, but good enough. (There is no other way to check whether we are
using the non-standard gcc in base, as far as I know.)
Reported by: rodrigc
MFC after: 3 days
- Add a quirk to allow ignoring e820 extended memory detection.
- Improve memory detection through e801.
- Add bootloader command "biosmem".
See differential revision for more details.
Reviewed by: jhb, adrian
Approved by: adrian
Differential Revision: https://reviews.freebsd.org/D1741
Motivation is to introduce BIOS specific quirks early in the boot
process. smbios_match can be called before malloc is avaible, that's
why parts of smbios_detect have been moved into a separate function
smbios_probe that will be called by smbios_detect as well as
smbios_match.
Reviewed by: jhb
Approved by: jhb
Differential Revision: https://reviews.freebsd.org/D1679
__attribute__((format(...))), and the -fformat-extensions flag was
removed, introduce a new macro in bsd.sys.mk to choose the right variant
of compile flag for the used compiler, and use it.
Also add something similar to kern.mk, since including bsd.sys.mk from
that file will anger Warner. :-)
Note that bsd.sys.mk does not support the MK_FORMAT_EXTENSIONS knob used
in kern.mk, since that knob is only available in kern.opts.mk, not in
src.opts.mk. We might want to add it later, to more easily support
external compilers for building world (in particular, sys/boot).
(This change was supposed to be included in r277508.)
sys/boot/i386/libfirewire/firewire.c:
Fix configuration ROM generation count wrapping logic
so that the generation count is never outside of
allowed limits (0x2 -> 0xF).
Submitted by: gibbs
MFC after: 1 week
MFC with: 277508
Sponsored by: Spectra Logic
MFSpectraBSD: 1110685 on 2015/01/05
The data in MODINFOMD_MODULEP is packed by the loader as a 4 byte type, but
the amd64 kernel expects a vm_paddr_t, which is of size 8 bytes. Fix this by
saving it as 8 bytes in the loader and retrieving it using the proper type
in the kernel.
Sponsored by: Citrix Systems R&D
Implement a subset of the multiboot specification in order to boot Xen
and a FreeBSD Dom0 from the FreeBSD bootloader. This multiboot
implementation is tailored to boot Xen and FreeBSD Dom0, and it will
most surely fail to boot any other multiboot compilant kernel.
In order to detect and boot the Xen microkernel, two new file formats
are added to the bootloader, multiboot and multiboot_obj. Multiboot
support must be tested before regular ELF support, since Xen is a
multiboot kernel that also uses ELF. After a multiboot kernel is
detected, all the other loaded kernels/modules are parsed by the
multiboot_obj format.
The layout of the loaded objects in memory is the following; first the
Xen kernel is loaded as a 32bit ELF into memory (Xen will switch to
long mode by itself), after that the FreeBSD kernel is loaded as a RAW
file (Xen will parse and load it using it's internal ELF loader), and
finally the metadata and the modules are loaded using the native
FreeBSD way. After everything is loaded we jump into Xen's entry point
using a small trampoline. The order of the multiboot modules passed to
Xen is the following, the first module is the RAW FreeBSD kernel, and
the second module is the metadata and the FreeBSD modules.
Since Xen will relocate the memory position of the second
multiboot module (the one that contains the metadata and native
FreeBSD modules), we need to stash the original modulep address inside
of the metadata itself in order to recalculate its position once
booted. This also means the metadata must come before the loaded
modules, so after loading the FreeBSD kernel a portion of memory is
reserved in order to place the metadata before booting.
In order to tell the loader to boot Xen and then the FreeBSD kernel the
following has to be added to the /boot/loader.conf file:
xen_cmdline="dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga"
xen_kernel="/boot/xen"
The first argument contains the command line that will be passed to the Xen
kernel, while the second argument is the path to the Xen kernel itself. This
can also be done manually from the loader command line, by for example
typing the following set of commands:
OK unload
OK load /boot/xen dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga
OK load kernel
OK load zfs
OK load if_tap
OK load ...
OK boot
Sponsored by: Citrix Systems R&D
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D517
For the Forth bits:
Submitted by: Julien Grall <julien.grall AT citrix.com>
gzip, and split). "Real" filesystems should always be listed first so
that the "bare" filename is tried before alternate filenames. For PXE
booting in particular this can remove a lot of spurious pathname lookups.
While here, move splitfs to the bottom after the bzip and gzip filesystems
as it is the least often used.
Tested by: Prokash Sinha <psinha@panasas.com>
MFC after: 1 week
Commit my version of style(9) pass over the firewire code. Now that
other people have started changing the code carrying this is as a
local patch is not longer a viable option.
MFC after: 1 month
bootloader. Implement the following routines:
pcibios-device-count count the number of instances of a devid
pcibios-read-config read pci config space
pcibios-write-config write pci config space
pcibios-find-devclass find the nth device with a given devclass
pcibios-find-device find the nth device with a given devid
pcibios-locator convert bus device function ti pcibios locator
These commands are thin wrappers over their PCI BIOS 2.1 counterparts. More
informaiton, such as it is, can be found in the standard.
Export a nunmber of pcibios.X variables into the environment to report
what the PCI IDENTIFY command returned.
Also implmenet a new command line primitive (pci-device-count), but don't
include it by default just yet, since it depends on the recently added
words and any errors here can render a system unbootable.
This is intended to allow the boot loader to do special things based
on the hardware it finds. This could be have special settings that are
optimized for the specific cards, or even loading special drivers. It
goes without saying that writing to pci config space should not be
done without a just cause and a sound mind.
Sponsored by: Netflix
1. 50+% of NO_PIE use is fixed by adding -fPIC to INTERNALLIB and other
build-only utility libraries.
2. Another 40% is fixed by generating _pic.a variants of various libraries.
3. Some of the NO_PIE use is a bit absurd as it is disabling PIE (and ASLR)
where it never would work anyhow, such as csu or loader. This suggests
there may be better ways of adding support to the tree. Many of these
cases can be fixed such that -fPIE will work but there is really no
reason to have it in those cases.
4. Some of the uses are working around hacks done to some Makefiles that are
really building libraries but have been using bsd.prog.mk because the code
is cleaner. Had they been using bsd.lib.mk then NO_PIE would not have
been needed.
We likely do want to enable PIE by default (opt-out) for non-tree consumers
(such as ports). For in-tree though we probably want to only enable PIE
(opt-in) for common attack targets such as remote service daemons and setuid
utilities. This is also a great performance compromise since ASLR is expected
to reduce performance. As such it does not make sense to enable it in all
utilities such as ls(1) that have little benefit to having it enabled.
Reported by: kib
place for the NFS-based PXE loader. Information like rootpath
or rootip aren't that useful for TFTP and the gateway IP is
typically already printed by the firmware.
2. Only set boot.nfsroot.* environment variables for NFS. This
makes it possible for the OS to work either way by checking
for the presence or absence of environment variables.
3. Set boot.netif.server when using TFTP so that the OS can fetch
files as well. A typical use case for this is network-based
installations with the installation process implemented on
top of FreeBSD.
4. The pxelinux loader has a set of alternative names it tries
for configuration files. Make it easier to do something
similar in Forth by providing the IP address as a 32-bit hex
number in the pxeboot.ip variable and the MAC address with
dashes in the pxeboot.hwaddr environment variable.
Obtained from: Juniper Networks, Inc.
particular, allow loaders to define the name of the RC script the
interpreter needs to use. Use this new-found control to have the
PXE loader (when compiled with TFTP support and not NFS support)
read from ${bootfile}.4th, where ${bootfile} is the name of the
file fetched by the PXE firmware.
The normal startup process involves reading the following files:
1. /boot/boot.4th
2. /boot/loader.rc or alternatively /boot/boot.conf
When these come from a FreeBSD-defined file system, this is all
good. But when we boot over the network, subdirectories and fixed
file names are often painful to administrators and there's really
no way for them to change the behaviour of the loader.
Obtained from: Juniper Networks, Inc.
Setting PSE together with PAE or in long mode just makes the PSE bit
completely ignored, so don't set it.
Sponsored by: Citrix Systems R&D
Reviewed by: kib
percentage of machines has a 16550. Disable it for pc98 since only a
tiny fraction of them have one. These changes save 293 bytes when
building with clang, but preserves the ability to build with serial if
you really want. We now have 92 bytes free (412 with the in-tree gcc).
This is currently an opt-in build flag. Once ASLR support is ready and stable
it should changed to opt-out and be enabled by default along with ASLR.
Each application Makefile uses opt-out to ensure that ASLR will be enabled by
default in new directories when the system is compiled with PIE/ASLR. [2]
Mark known build failures as NO_PIE for now.
The only known runtime failure was rtld.
[1] http://www.bsdcan.org/2014/schedule/events/452.en.html
Submitted by: Shawn Webb <lattera@gmail.com>
Discussed between: des@ and Shawn Webb [2]
thicket of .if ${COMPILER_TYPE} == "clang" that controls
warnings. Also, use CFLAGS.clang in a couple places in preference to
having a similar construct that's related to the CWARNFLAGS changes.
and finish the job. ncurses is now the only Makefile in the tree that
uses it since it wasn't a simple mechanical change, and will be
addressed in a future commit.
This is largely the work from the projects/uefi branch, with some
additional refinements. This is derived from (and replaces) the
original i386 efi implementation; i386 support will be restored later.
Specific revisions of note from projects/uefi:
r247380:
Adjust our load device when we boot from CD under UEFI.
The process for booting from a CD under UEFI involves adding a FAT
filesystem containing your loader code as an El Torito boot image.
When UEFI detects this, it provides a block IO instance that points at
the FAT filesystem as a child of the device that represents the CD
itself. The problem being that the CD device is flagged as a "raw
device" while the boot image is flagged as a "logical partition". The
existing EFI partition code only looks for logical partitions and so
the CD filesystem was rendered invisible.
To fix this, check the type of each block IO device. If it's found to
be a CD, and thus an El Torito boot image, look up its parent device
and add that instead so that the loader will then load the kernel from
the CD filesystem. This is done by using the handle for the boot
filesystem as an alias.
Something similar to this will be required for booting from other
media as well as the loader will live in the EFI system partition, not
on the partition containing the kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r247216:
Use the UEFI Graphics Output Protocol to get the parameters of the
framebuffer.
Sponsored by: The FreeBSD Foundation
The 32-bit bootloaders on amd64 now use the 32-bit version in ficl32,
as is done with libstand32. The native 64-bit ficl will be used by the
upcoming UEFI loader.
Sponsored by: The FreeBSD Foundation
A 32-bit libstand is needed on 64-bit platforms for use by various
bootloaders. Previously only the 32-bit version was built, installed as
/usr/lib/libstand.a.
A new 64-bit libstand consumer will arrive in the near future, so move
the bootloader-specific 32-bit version to sys/boot/libstand32/.
Explicitly link against this version in the 32-bit loaders.
Sponsored by: The FreeBSD Foundation
Hetzel <swhetzel@gmail.com> on the -doc mailing list.
Also modify the Author section to be clear that I wrote the man page,
not gptboot.
MFC after: 3 days
