Zybo needs its own DTB and has a different PHY, so add it to
the base kernel. Details on building bootable SD images at
http://www.thomasskibo.com/zedbsd/
Submitted By: Thomas Skibo
the temporary file to vers.c at the end of the script
The previous logic wrote out to vers.c multiple times, so the file
could be incorrectly interpreted as being completely written out
after one of the echo calls with recursive make, when in reality it
was only partially written.
Also, in the event the build was interrupted when creating vers.c
(small race window), it would have a leftover file that needed to
be cleaned up before resuming the build.
MFC after: 3 weeks
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
hold the kernel, modules, and any other loaded data. This memory block
is relocated to the kernel's expected location during the transfer of
control from the loader to the kernel.
The GENERIC kernel on amd64 has recently grown such that a kernel + zfs.ko
no longer fits in the default staging size. Bump the default size from
32MB to 48MB to provide more breathing room.
PR: 201679
Reviewed by: imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D3666
no option but to use the smbios information to fill in the blanks.
It's a good thing UGA is a protocol of the past and GOP has all the
info we need.
Anyway, the logic has been tweaked a little to get the easier bits
of information up front. This includes the resolution and the frame
buffer address. Then we look at the smbios information and define
expected values as well as the missing bits (frame buffer offset and
stride). If the values obtained match the expect values, we fill in
the blanks and return. Otherwise we use the existing detection logic
to figure it out.
Rename the environment variables from uga_framebuffer abd uga_stride
to hw.efifb.address and hw.efifb.stride. The latter names are more
in line with other variable names.
We currently have hardcoded settings for:
1. Mid-2007 iMac (iMac7,1)
2. Late-2007 MacBook (MacBook3,1)
striking a delicate balance between exhaustive searching and
banking on assumptions. The environment variables can be used
as a fall-back anyway. With this change, all known and tested
Macs with only UGA should have a working console out of the
box... for now...
in the frame buffer when we flip pixels. Allow the detection
to be bypassed by setting the uga_framebuffer and uga_stride
variables. The kernel console works fine even when we can't
detect pixel changes in the frame buffer, which indicates
that the problem could be with reading from the frame buffer
and not writing to it.
PCI BARs does not necessarily correspond to the upper-left
most pixel. Scan the frame buffer for which byte changed
when changing the pixel at (0,0).
Use the same technique to determine the stride. Except for
changing the pixel at (0,0), we change the pixel at (0,1).
PR: 202730
Tested by: hartzell (at) alerce.com
so they were disabled during DTS transition. Though there are
no standard devices/drivers on them people might use iic(4) userland
interface to access these buses.
command called 'uga' to show whether UGA is implemented by the
firmware and what the settings are. It also includes filling
the efi_fb structure from the UGA information when GOP isn't
implemented by the firmware.
Since UGA does not provide information about the stride, we
set the stride to the horizontal resolution. This is likely
not correct and we should determine the stride by trial and
error. For now, this should show something on the console
rather than nothing.
Refactor this file to maximize code reuse.
PR: 202730
command has the following sub-commands:
list - list all possible modes (paged)
get - return the current mode
set <mode> - set the current mode to <mode>
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
"fdt_file" and "fdtfile" U-Boot variables. Add one more check for
"fdt_file" loader(8) variable.
loader(8) variable takes precedence over u-boot env one
like RPI-B and RPI-2.
Description of problem:
USB transfers can process data in their callbacks sometimes causing
unacceptable latency for other USB transfers. Separate BULK completion
callbacks from CONTROL, INTERRUPT and ISOCHRONOUS callbacks, and give
BULK completion callbacks lesser execution priority than the
others. This way USB audio won't be interfered by heavy USB ethernet
usage for example.
Further serve USB transfer completion in a round robin fashion,
instead of only serving the most CPU hungry. This has been done by
adding a third flag to USB transfer queue structure which keeps track
of looping callbacks. The "command" callback function then decides
what to do when looping.
MFC after: 2 weeks
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
For example, without this patch, the following three lines
in /boot/loader.conf would result in /boot/root.img being preloaded
twice, and two md(4) devices - md0 and md1 - being created.
initmd_load="YES"
initmd_type="md_image"
initmd_name="/boot/root.img"
Reviewed by: marcel@
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D3204
but it's hard to find and easy to miss.
Reviewed by: wblock@
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D3183
The UEFI loader on the 10.1 release install disk (disc1) modifies an
existing EFI_DEVICE_PATH_PROTOCOL instance in an apparent attempt to
truncate the device path. In doing so it creates an invalid device
path.
Perform the equivalent action without modification of structures
allocated by firmware.
PR: 197641
MFC After: 1 week
Submitted by: Chris Ruffin <chris.ruffin@intel.com>
The Allwinner SoC has an AHCI device on its internal main bus rather
than the PCI bus. This SoC is somewhat underdocumented, and its SATA
controller is no exception. The methods to support this chip were
harvested from the Linux Allwinner SDK, and then constants invented to
describe what's going on based on low-level constants contained in the
SATA standard and guess work.
This SoC requires a specific AHCI channel setup in order to start the
operations on the channel properly.
Clock setup and AHCI channel setup idea came from NetBSD.
Tested on Cubieboard 2 and Banana pi (and attachment on Cubieboard by
Pratik Singhal).
Differential Revision: https://reviews.freebsd.org/D737
Submitted by: imp
Reviewed by: imp, ganbold, mav, andrew
- 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
function, which is expected to set returned env to NULL upon reaching the end
of the environment list but fails to do so in certain cases. The respective
u-boot code looks like the following (HEAD at the time of this commit):
--- api.c ---
496 static int API_env_enum(va_list ap)
...
510 *next = last;
511
512 for (i = 0; env_get_char(i) != '\0'; i = n + 1) {
513 for (n = i; env_get_char(n) != '\0'; ++n) {
514 if (n >= CONFIG_ENV_SIZE) {
515 /* XXX shouldn't we set *next = NULL?? */
516 return 0;
517 }
518 }
-------------
The net result is that any unfortunate user of the loader's ub_env_enum()
function hitting this condition would be trapped in the infinite loop, as
the main use pattern of ub_env_enum() is basically the following:
while ((env = ub_env_enum(env)) != NULL) { DO STUFF }
Which would stuck forever with the last element.
fails to properly consider memory regions when the loader is
located below of those regions or engulfs their lower limit. This
results in "not enough RAM to load kernel" panic, which is totally
bogus. On top of that, there are some variables that can be left
unitialized in those cases, which might cause it fail with memory
access violation instead of panic while trying to load kernel to
a wrong or non-existing address of memory.
Augment the code to properly deal with the loader being below or
at the lower bound of the memory region in question. Also, don't
leave ununitialized variables behind.
Reviewed by: ian
- Add driver for TDA19988 HDMI framer
- Add simple interface to communicate with HDMI sink: read EDID and set videomode
- Add event-based API to notify LCD controller when HDMI sink is available
- Add HDMI framer node and add refernce to it to lcdc node. This part of
DTS tree is custom and does not match Linux DTS because Linux uses
combination of pseudo-node in DTS and hardcoded driver information
that does not map to our model.
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
A hole block pointer can be encountered at any level and the hole
can cover multiple data blocks, but we are reading the data blocks
one by one, so we care only about the current one.
PR: 199804
Reported by: Toomas Soome <tsoome@me.com>
Submitted by: Toomas Soome <tsoome@me.com> (earlier version)
Tested by: Toomas Soome <tsoome@me.com>
MFC after: 11 days
Additionally, sort all real filesystems before the virtual ones.
Differential Revision: https://reviews.freebsd.org/D2709
Reviewed by: grehan
MFC after: 5 days
based device.
Following u-boot commands allow FreeBSD boot on
Yiyate Android TV Box (aml8726-m3):
tv open 480p
mmc rescan 0
fatload mmc 0 0x80100000 kernel.bin
go 0x80100000
The current FreeBSD driver doesn't program the video
clocks so the u-boot tv command is necessary in order
for the frame buffer to be useful (otherwise it can
be skipped).
The SD card for the Yiyate Android TV Box doesn't need
anything special beyond creating a FAT16 and a UFS
filesystem.
Differential Revision: https://reviews.freebsd.org/D2636
Submitted by: John Wehle
files to vendor-provided ones. It should make easier to adopt platform
code to new revisions of hardware and to use DTS overlays for various
Beaglebone extensions (shields/capes).
Original dts filenames were not changed, they're now wrappers over dts
files provided by TI. So make sure you update .dtb files on your
devices as part of kernel update
GPIO addressing was changed: instead of one global /dev/gpioc0 there
are per-bank instances of /dev/gpiocX. Each bank has 32 pins so for
instance pin 121 on /dev/gpioc0 in old addressing scheme is now pin 25
on /dev/gpioc3
On Pandaboard serial console devices was changed from /dev/ttyu0 to
/dev/ttyu2 so you'll have to update /etc/ttys to get login prompt
on serial port in multiuser mode. Single user mode serial console
should work as-is
Differential Revision: https://reviews.freebsd.org/D2146
Reviewed by: rpaulo, ian, Michal Meloun, Svatopluk Kraus
This is based on the patch sent by Alexander Fedorov with the following
fixes/improvements:
- Better error handling;
- Clock is derived from PLL6 (obtained from netbsd);
- No more unnecessary busy loops on interrupt handler;
- style(9) fixes and code cleanup.
I also want to thanks Martin Galvan who has sent an alternative
implementation with some interesting fixes.
Tested on CubieBoard2, Banana-Pi (thanks to netgate!) and Cubieboard1
(Pratik Singhal).
This is intended to pave the way for the upcoming GSoC work (and make
easier the build of images for the supported boards).
PR: 196081
Submitted by: Alexander Fedorov <alexander.fedorov@rtlservice.com>
determined at runtime so there's no need to set the values in
each DTS.
Tested on YYHD18 (aml8726-m3), VSATV102 (aml8726-m6), and
ODROIDC1 (aml8726-m8b).
Differential Revision: https://reviews.freebsd.org/D2588
Submitted by: John Wehle
interface open continuously instead of closing it after each filesystem
access and reopening it before the next (causing it to re-obtain network
params each time). This vastly speeds up netbooting.
it from the uboot net_init() implementation. The routine uses the standard
U-Boot env vars plus a freebsd-specific variable named "rootpath" (the
corresponding u-boot variable for that would be "bootfile" except that it
refers to ubldr, so a new name was needed to communicate the path to ubldr).
This allows ubldr to load a kernel from nfs without requiring a dhcp or
bootp server to provide the server ip and rootpath parameters.
than bootp and rarp.
The code which splits a serverip:/rootpath string into rootip and a plain
pathname is now a separate net_parse_rootpath() function that can be
called by others. The code that sets the kernel env vars needed for
nfs_diskless is moved into net_open() so that the variables get set no
matter where the params came from.
There was already code in net_open() that allowed for the possibility that
some other entity has set up the network-related global variables. It uses
the rootip variable as the key, assuming that if it is set all the other
required variables are set too. These changes don't alter the existing
behavior, they just make it easier to actually write some new code to get
the params from another source (such as the U-Boot environment).
Previously, ubldr would use the virtual addresses in the elf headers by
masking off the high bits and assuming the result was a physical address
where the kernel should be loaded. That would sometimes discard
significant bits of the physical address, but the effects of that were
undone by archsw copy code that would find a large block of memory and
apply an offset to the source/dest copy addresses. The result was that
things were loaded at a different physical address than requested by the
higher code layers, but that worked because other adjustments were applied
later (such as when jumping to the entry point). Very confusing, and
somewhat fragile.
Now the archsw copy routines are just simple copies, and instead
archsw.arch_loadaddr is implemented to choose a load address. The new
routine uses some of the code from the old offset-translation routine to
find the largest block of ram, but it excludes ubldr itself from that
range, and also excludes If ubldr splits the largest block of ram in
two, the kernel is loaded into the bottom of whichever resulting block is
larger.
As part of eliminating ubldr itself from the ram ranges, export the heap
start/end addresses in a pair of new global variables.
This change means that the virtual addresses in the arm kernel elf headers
now have no meaning at all, except for the entry point address. There is
an implicit assumption that the entry point is in the first text page, and
that the address in the the header can be turned into an offset by masking
it with PAGE_MASK. In the future we can link all arm kernels at a virtual
address of 0xC0000000 with no need to use any low-order part of the
address to influence where in ram the kernel gets loaded.
The Alpine Platform-On-Chip offers multicore processing
(quad ARM Cortex-A15), 1/10Gb Ethernet, SATA 3, PCI-E 3,
DMA engines, Virtualization, Advanced Power Management and other.
This code drop involves basic platform support including:
SMP, IRQs, SerDes, SATA. As of now it is missing the PCIe support.
Part of the functionality is provided by the low-level code (HAL)
delivered by the chip vendor (Annapurna Labs) and is a subject to
change in the future (is planned to be moved to sys/contrib directory).
The review log for this commit is available here:
https://reviews.freebsd.org/D2340
Reviewed by: andrew, ian, imp
Obtained from: Semihalf
Sponsored by: Annapurna Labs
static-linked to run at a fixed position, is still installed to maintain
compatibility with existing configurations. The makefile now also creates
and installs ubldr.bin, a stripped binary (no elf headers) with an entry
point offset of 0 that can be loaded by u-boot at any address and launched
with "go ${loadaddr}".
To use ubldr.bin, U-Boot must still be built with the CONFIG_API option,
but no longer needs the CONFIG_ELF option.
return a value.
Despite what I said in my prior commit, it turns out this one platform
was checking the return value from the old self-reloc code (which returned
a hard-coded 0).
The function was defined as taking 4 parameters and returning EFI_STATUS,
but all existing callers (in asm code) passed only two parameters and don't
use the return value. The function signature now matches that usage, and
doesn't refer to efi-specific types.
Parameters and variables now use the cannonical typenames set up by elf.h
(Elf_Word, Elf_Addr, etc) instead of raw C types. Hopefully this will
prevent suprises as new platforms come along and use this code.
The function was renamed from _reloc() to self_reloc() to emphasize its
difference from the other elf relocation code found in boot/common.
Differential Revision: https://reviews.freebsd.org/D2490
The commit from r279799 missed the adaptation of md_load in
sparc64/loader/main.c. This resulted in Memory Address Align issues at the
early boot stage.
Tested on a netbooted Fire 120.
a text file with a list of physical memory addresses to exclude, and have it
loaded at boot time via the provided example in loader.conf. The tunable
'vm.blacklist' remains, but using an external file means that there's no
practical limit to the size of the list. This change also improves the
scanning algorithm for processing the list, scanning the list only once
instead of scanning it for every page in the system. Both the sysctl and
the file can be unsorted and contain duplicates so long as each entry is
numeric (decimal or hex) and is separated by a space, comma, or newline
character. The sysctl 'vm.page_blacklist' is now provided to report what
memory locations were successfully excluded.
Reviewed by: imp, emax
Obtained from: Netflix, Inc.
MFC after: 3 days
The 'pwr' LED is connected to GPIO pin 35 (active high) and the 'act' LED
is connected to GPIO pin 47 (active high).
Remove the GPIO pin 47 from reserved pins list, previously it was used to
signaling the SD Card presence and now it is used by act LED.
This should be a non-functional change. A future change should
address the functional differences between these three and converge
on a single source.
Differential Revision: https://reviews.freebsd.org/D2058
Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
A new loader.conf(5) option of geom_eli_passphrase_prompt="YES" will now
allow you to enter your geli(8) root-mount credentials prior to invoking
the kernel.
See check-password.4th(8) for details.
Differential Revision: https://reviews.freebsd.org/D2105
Reviewed by: imp, kmoore
Discussed on: -current
MFC after: 3 days
X-MFC-to: stable/10
Relnotes: yes
x86 symlink on i386 and amd64. Before this incorrect symlinks were being
created on armi and i386.
Differential Revision: https://reviews.freebsd.org/D2283
Reviewed by: emaste, imp
Sponsored by: The FreeBSD Foundation
earlier migration away from sloppy mode-endings (r280925,280974-280976)
due to a red-herring in diagnosing HardenedBSD boot lockup.
Thanks to: lattera (shawn.webb@hardenedbsd<dot>org)
MFC after: 3 days
X-MFC-to: stable/10
X-MFC-with: r280925,280974-280976,281176-281179
NB: This deeply effected HardenedBSD which had a default value set.
Embarassingly, I allowed the `type' primitive to be passed -1/-1 for
c-addr/u stack input (the effect of which is to pull INT_MAX bytes
from character address negative one in which hilarity ensues over a
black screen in full-on bootlock). Much thanks to Shawn Webb [lattera]
for helping me diagnose.
NB: The mode-ending revisions were initially suspected (and reverted)
but proved to be a red-herring. Proper mode endings will be returning.
Thanks to: lattera (@HardenedBSD [<dot><com>])
Reported by: lattera
MFC after: 3 days
X-MFC-to: stable/10
loader.efi still needs work, but boot1.efi now builds.
Differential Revision: https://reviews.freebsd.org/D2244
Reviewed by: rpaulo
Sponsored by: The FreeBSD Foundation
Much of this file is common to the architectures we support, so share
an implementation by adding a little #ifdef-ery.
Differential Revision: https://reviews.freebsd.org/D2241
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
It's necessary to reset the screen to make sure any vendor pixels are
gone when we start boot1. In the Lenovo X1 (3rd gen), this is the
only way to clear the screen. Previously, the Lenovo logo would only
disappear after the kernel started scrolling the display.
After resetting the screen, EFI could put us in the worst LCD mode
(oversized characters), so we now find the largest mode we can use and
hope it's the most appropriate one (it's not trivial to tell what's
the correct LCD resolution at this point). It's worth noting that the
final stage loader has a 'mode' command that can be used to switch
text modes.
While there, enable the software cursor, just like in the legacy boot
mode.
MFC after: 1 week
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
support for booting arm and arm64 from UEFI.
Differential Revision: https://reviews.freebsd.org/D2164
Reviewed by: emaste, imp (previous version)
Sponsored by: The FreeBSD Foundation
Summary:
Add "GELI Passphrase:" prompt to boot loader.
A new loader.conf(5) option of geom_eli_passphrase_prompt="YES" will now
allow you to enter your geli(8) root-mount credentials prior to invoking
the kernel.
See check-password.4th(8) for details.
Differential Revision: https://reviews.freebsd.org/D2105
Reviewed by: (your name[s] here)
MFC after: 3 days
X-MFC-to: stable/10
Relnotes: yes
Test Plan:
Drop a head copy of check-password.4th into /boot and then apply the patch
(only the patch to /boot/check-password.4th is required; no other changes are
required but you do have to have a HEAD copy of check-password.4th to
apply the patch).
NB: The rest of your /boot files can be up to 2 years old but no older.
NB: The test won't work unless your kernel has the following change
https://svnweb.freebsd.org/base?view=revision&revision=273489
Now, put into /boot/loader.conf:
geom_eli_passphrase_prompt="YES"
and reboot.
You should be prompted for a GELI passphrase before the menu (if enabled),
just after loading loader.conf(5).
NB: It doesn't matter if you're using GELI or not. However if you are using
GELI and a sufficiently new enough release (has SVN r273489) and you entered
the proper passphrase to mount your GELI encrypted root device(s), you should
notice that the boot process did not stop (you went from loader all the way to login).
Reviewers: cperciva, allanjude, scottl, kmoore
Subscribers: jkh, imp
Differential Revision: https://reviews.freebsd.org/D2105
vocabularies delay-processing, password-processing, version-processing,
frame-drawing, menu-infrastructure, menu-namespace, menu-command-helpers,
and menusets-infrastructure. The net effect is to remove almost 200
definitions from the main forth vocabulary reducing the dictionary size
by over 50%. The chances of hitting "dictionary full" should be greatly
reduced by this patch.
MFC after: 3 days
X-MFC-to: stable/10
will depend on ficl having been built, and are set via bsd.arch.inc.mk we
need to place this after ficl.
As Makefile.amd64 is now late enough we can add the i386 directory to this.
NB: Using NULL for default values in-case someone
or something uncomments it and reboots. See
check-password.4th(8) for additional details.
MFC after: 3 days
X-MFC-to: stable/10 stable/9
When taking user input, don't show asterisks as the user types
but instead spin a twiddle. Implement Ctrl-U to clear user input.
If the buffer is empty, either because the user has yet to type
anything, presses Ctrl-U at any time, or presses backspace enough
to end in an empty buffer, the twiddle is erased to provide feed-
back to the user.
MFC after: 3 days
X-MFC-to: stable/10 stable/9
locking out everyone in the case of setting a password longer than
the maximum (currently 16 characters). Now the required password is
truncated to the maximum input that can be read from the user.
PR: kern/198760
MFC after: 3 days
MFH: stable/10 stable/9
port loader.efi to both 32 and 64-bit ARM where we can use this file with
minimal changes.
Differential Revision: https://reviews.freebsd.org/D2031
Reviewed by: imp
several types of data into the mem-info array (DRAM, SRAM, flash). We
need to extract just the DRAM entries for translation into fdt memory
properties.
Also, increase the number of regions we can handle from 5 to 16.
Submitted by: Michal Meloun
- Add bzipfs to the list of supported filesystems in the EFI loader.
- Increase the heap size allocated for the EFI loader from 2MB to 3MB.
Differential Revision: https://reviews.freebsd.org/D2053
Reviewed by: benno, emaste, imp
MFC after: 2 weeks
Sponsored by: Cisco Systems, Inc.
redzone below the stack pointer for scratch space and requires
interrupt and signal frames to avoid overwriting it. However, EFI uses
the Windows ABI which does not support this. As a result, interrupt
handlers in EFI push their interrupt frames directly on top of the
stack pointer. If the compiler used the red zone in a function in the
EFI loader, then a device interrupt that occurred while that function
was running could trash its local variables. In practice this happens
fairly reliable when using gzipfs as an interrupt during decompression
can trash the local variables in the inflate_table() function
resulting in corrupted output or hangs.
Fix this by disabling the redzone for amd64 EFI binaries. This
requires building not only the loader but any libraries used by the
loader without redzone support.
Thanks to Jilles for pointing me at the redzone once I found the stack
corruption.
Differential Revision: https://reviews.freebsd.org/D2054
Reviewed by: imp
MFC after: 2 weeks
Sponsored by: Cisco Systems, Inc.
(for example, a large mfsroot). Note that for EFI the kernel and
modules (as well as other metadata files such as splash screens or
memory disk images) are loaded into a statically-sized staging area.
When the EFI loader exits it copies this staging area down to the
location the kernel expects to run at.
- Add bounds checking to the copy routines to fail attempts to access
memory outside of the staging area. Previously loading a combined
kernel + modules larger than the staging size (32MB) would overflow
the staging area trashing whatever memory was afterwards. Under
Intel's OVMF firmware for qemu this resulted in fatal faults in the
firmware itself. Now the attempt will fail with ENOMEM.
- Allow the staging area size to be configured at compile time via
an EFI_STAGING_SIZE variable in src.conf or on the command line.
It accepts the size of the staging area in MB. The default size
remains 32MB.
MFC after: 2 weeks
Sponsored by: Cisco Systems, Inc.
an FDT. This is how Linux and OS X boot and can avoid some issues with
using Open Firmware at runtime. The code is highly experimental and disabled
by default; it can be turned on by setting the loader environment variable
"usefdt" to a non-NULL value.
confusion, the _setjmp.S in libstand was never being used and was instead
being shadowed by the libc version. Since the libc version now uses FPRs,
it caused loader to crash.
-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
first, EFI will use its definitions for {,U}INT{8,16,32,64} and
BOOLEAN. When EFI is included first, define ACPI_USE_SYSTEM_INTTYPES
to tell ACPI that these are already defined.
Differential Revision: https://reviews.freebsd.org/D1905
When building some of the boot loaders with clang, and DEBUG_FLAGS or
CFLAGS having '-g' in it, clang outputs several assembly directives that
are too new for our version of binutils.
Therefore, assemble the resulting .s files with clang instead. A more
general solution can be implemented when a GNU as-compatible driver for
clang's integrated assembler appears.
Tested by: gjb
contains one. Published dts source often includes a minimal default
memory definition and expects it to be overridden by the bootloader after
determining the actual physical memory in the system.
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
In UEFI it appears all available NICS are present to pass network traffic.
This gives the capability to load the loader.efi from disk then set
currdev="net3:" and then all I/O will over over the 2nd NIC. On this
machine is appears the first handle is the first NIC in IPv4 mode and
then the 2nd handle is the first NIC in IPv6 mode. The 3rd handle is
the 2nd NIC in IPv4 mode. The fix is to index into the handle based
on the unit cached from boot device passed into the loader.
Some testing info from a test boot via kenv:
currdev="net3:"
loaddev="net3:"
boot.netif.name="igb1"
__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).
o Digital Audio Multiplexer (AUDMUX)
o Smart Direct Memory Access Controller (SDMA)
o Synchronous Serial Interface (SSI)
Disable by default as it depends on SDMA firmware.
Sponsored by: Machdep, Inc.
(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
driver on Rockchip boards. It currently supports PIO mode
and dma mode needs external dma controller to be used.
Submitted by: jmcneill
Approved by: stas (mentor)
Use the proper types in parse_modmetadata for the p_start and p_end
parameters. This was causing problems in the ARM 32bit loader.
Sponsored by: Citrix Systems R&D
Reported and Tested by: ian
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>
associating an optional PNP hint table with this module. In the
future, when these are added, these changes will silently ignore the
new type they would otherwise warn about. It will always be safe to
ignore this data. Get this into the builds today for some future
proofing.
MFC After: 3 days
To cut off the power we need to start the shutdown sequence by writing
the OFF bit on PMIC.
Once the PMIC is programmed the SoC needs to toggle the PMIC_PWR_ENABLE
pin when it is ready for the PMIC to cut off the power. This is done by
triggering the ALARM2 interrupt on SoC RTC.
The RTC driver only works in power management mode which means it won't
provide any kind of time keeping functionality. It only implements a way
to trigger the ALARM2 interrupt when requested.
Differential Revision: https://reviews.freebsd.org/D1489
Reviewed by: rpaulo
MFC after: 2 weeks
loader on PS3 and POWER8 systems. This is reasonably portable to other
architectures, especially FDT-based ones, if similar features are useful
elsewhere.
Netboot support is missing for now and will be added in a future commit,
at which time loader.ps3 will be garbage collected.
Done at: Hackathon
standard file in the following ways:
- modules_path includes /boot/dtb
- It doesn't contain 533 lines, of which 500 are either commented out,
empty, or something_which_doesnt_work_on_arm_anyway=NO
The standard defaults file takes 40+ seconds to process on an arm beaglebone
board. This one takes just a couple seconds.
This gets installed instead of the original because of the .PATH magic in
the makefile.
