Move the definitions of the fdt functions from a uboot header to a new fdt
header. There is nothing in the fdt spec that ties it to U-Boot.
While here sort and fix the signature of fdt_setup_fdtp.
MFC 273934:
Start to allow platforms other than U-Boot to use the FDT code in loader by
moving U-Boot specific code from libfdt.a to a new libuboot_fdt.a. This
needs to be a new library for linking to work correctly.
Differential Revision: https://reviews.freebsd.org/D1054
Reviewed by: ian, rpaulo (earlier version)
Clean up the types of a few strings to make them const when they are never
written to.
MFC r273914:
The command name is a constant, use the correct type.
Fix incorrect reading of 32-bit modinfo by 64-bit loaders.
The various structures in the mod_metadata set of a FreeBSD kernel and
modules contain pointers. The FreeBSD loader correctly deals with a
mismatch in loader and kernel pointer size (e.g. 32-bit i386/ppc
loader, loading 64-bit amd64/ppc64 kernels), but wasn't dealing with
the inverse case where a 64-bit loader was loading a 32-bit kernel.
Make SERIAL support optional again. Enable it for i386 because a huge
percentage of machines has a 16550. Disable it for pc98 since only a
tiny fraction of them have one.
The U-Boot README says fdt_addr_r is the right env var for fdt data
loaded into ram, but vendors also use fdtaddr and fdt_addr. Check the
recommended variable first and fall back to the others.
- Add a basic iomux driver for imx6.
- Implement the same public interface in imx51 and imx6 iomux
- The iomux driver is no longer optional, remove it from kernel configs.
- Implement the imx_iomux_get/set_gpr() interface for imx6.
- Stop setting the iomux device status to disabled, now that we have a driver.
o Enable GPIO device driver for i.MX6.
It was originally written for i.MX5 and compatible with newer chip.
o Extend device tree information
o style(9) fixes
o Rename gpio driver file.
Fixes and enhancements for the if_cgem driver...
- miibus fixes as suggested by Yonghyeon Pyun.
- enable VLAN MTU support.
- fix a few WITNESS complaints in cgem_attach().
- have cgem_attach() properly init the ifnet struct before calling
mii_attach() to fix panic when using e1000phy.
- fix ethernet address changing.
- fix transmit queue overflow handling.
- tweak receive queue handling to reduce receive overflows.
- bring out MAC statistic counters to sysctls.
- add e1000phy to config file.
- implement receive hang work-around described in reference guide.
- change device name from if_cgem to cgem to be consistent with other
interfaces.
Fix the Zedboard/Zynq ethernet driver to handle media speed changes so
that it can connect to switches at speeds other than 1gb.
The loader previously failed to display on MacBooks and other
systems where the UEFI firmware remained in graphics mode.
Submitted by: Rafael Espindola
Approved by: re
r264391 (nwhitehorn):
Add a simple EFI stub loader. This is a quick and dirty of boot1.chrp
from the PowerPC port with all the Open Firmware bits removed and
replaced by their EFI counterparts. On the whole, I think I prefer
Open Firmware.
This code is supposed to be an immutable shim that sits on the EFI
system partition, loads /boot/loader.efi from UFS and tells the real
loader what disk/partition to look at. It finds the UFS root partition
by the somewhat braindead approach of picking the first UFS partition
it can find. Better approaches are called for, but this works for now.
This shim loader will also be useful for secure boot in the future,
which will require some rearchitecture.
r264403 (nwhitehorn):
Fix buildworld. I had some local bits in my build tree that caused
this to work by accident.
r264404 (nwhitehorn):
Add my copyright here. Most of this is unmodified from the original
sparc64 version, but at least some indication of changes that postdate
the actual invention of EFI is probably a good idea.
r264414 (nwhitehorn):
Apparently some of the i386 boot blocks are so close to full that
adding single lines to ufsread.c spills them over. Duplicate a whole
bunch of code to get file sizes into boot1.efi/boot1.c rather than
modifying ufsread.c.
r264975 (nwhitehorn):
Add generation of an EFI filesystem to hold boot1.efi. This is a near-
exact copy of the code from boot1.chrp again.
The resulting image is installed to /boot/boot1.efifat. If dd'ed to an
800K "efi" partition, it should result in a bootable system.
r268975 (sbruno): Remove boot1.efi during clean target.
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
This MFC consists of the following SVN revisions:
258741 261568 261603 261668 263115 263117 263968 264078 264087 264088
264092 264095 264115 264132 264208 264261 264262 264263 264319 265028
265057 268974
Detailed commit messages:
r258741: Note that libstand is 32-bit on amd64 and powerpc64
r261568: Build libstand as a 64-bit library on amd64
The 32-bit bootloaders now link against libstand.a in
sys/boot/libstand32, so there is no need to force /usr/lib/libstand.a
to be 32-bit.
r261603: Don't force efi to a 32-bit build on amd64
r261668: Build libstand as a 64-bit library on ppc64
The 32-bit bootloaders now link against libstand.a in
sys/boot/libstand32, so there is no need to force /usr/lib/libstand.a
to be 32-bit.
This is equivalent to r261568 for amd64.
r263115: Add amd64 EFI headers
r263117: Connect 64-bit boot ficl to the build
It is not yet used, but this will ensure it doesn't get broken.
r263968: Use EFI types for EFI values (silences warnings).
EFI UINTN is actually a 64-bit type on 64-bit processors.
r264078: Put each source file on a separate line
This will simplify rebasing the amd64 UEFI patch set.
r264087: Build boot/ficl as 64-bit library on amd64
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.
r264088: Merge efilib changes from projects/uefi
r247216: Add the ability for a device to have an "alias" handle.
r247379: Fix network device registration.
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.
r247381: Remove a scatalogical debug printf that crept in.
r264092: Add -fPIC for amd64
r264095: Support UEFI booting on amd64 via loader.efi
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.
r264115: Fix printf format mismatches
r264132: Connect sys/boot/amd64 to the build
r264208: Do not build the amd64 UEFI loader with GCC
The UEFI loader causes buildworld to fail when building with (in-tree)
GCC, due to a typedef redefinition. As it happens the in-tree GCC
cannot successfully build the UEFI loader anyhow, as it does not support
__attribute__((ms_abi)). Thus, just avoid trying to build it with GCC,
rather than disconnecting it from the build until the underlying issue
is fixed.
r264261: Correct a variable's type for 64-bit Ficl
FICL_INT is long.
r264262: Fix printf args for 64-bit archs
r264263: Add explicit casts to quiet warnings in libefi
r264319: Fix EFI loader object tree creation on 9.x build hosts
Previously ${COMPILER_TYPE} was checked in sys/boot/amd64, and the efi
subdirectory was skipped altogether for gcc (since GCC does not support
a required attribute). However, during the early buildworld stages
${COMPILER_TYPE} is the existing system compiler (i.e., gcc on 9.x build
hosts), not the compiler that will eventually be used. This caused
"make obj" to skip the efi subdirectory. In later build stages
${COMPILER_TYPE} is "clang", and then the efi loader would attempt to
build in the source directory.
r265028 (dteske): Disable the beastie menu for EFI console ...
which doesn't support ANSI codes (so things like `at-xy', `clear', and
other commands don't work making it impossible to generate a living
menu).
r265057 (nwhitehorn): Turn off various fancy instruction sets...
as well as deduplicate some options. This makes the EFI loader build
work with CPUTYPE=native in make.conf on my Core i5.
r268974 (sbruno): Supress clang warning for FreeBSD printf %b and %D formats
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
r269029 (sbruno):
Update so that clean target in sys/boot will delete the symlink
created for machine
r269036 (sbruno):
Delete the entire cleandepend/cleanmachine target thing now that its
been cleared out in r269029
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.
r261614: Build a 32-bit libstand under sys/boot/ for ppc64
This change is equivalent to r261567 for i386/amd64.
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
The size of the GPT table can not be less than one sector.
MFC r270521:
Since the size of GPT entry may differ from the sizeof(struct gpt_ent),
use the size from GPT header to iterate entries.
FreeBSD, historically, has always used 8-bit addresses for i2c devices
(7-bit device address << 1), always leaving the room for the read/write
bit.
This commit convert ti_i2c and revert r259127 on bcm2835_bsc to make them
compatible with 8-bit addresses. Previous to this commit an i2c device
would have different addresses depending on the controller it was attached
to (by example, when compared to any iicbb(4) based i2c controller), which
was a pretty annoying behavior.
Also, update the PMIC i2c address on beaglebone* DTS files to match the
new address scheme.
Now the userland utilities need to do the correct slave address shifting
(but it is going to work with any i2c controller on the system).
Discussed with: ian
MFC r267834:
Clarify the expected usage of I2C 7-bit slave addresses on ioctl(2)
interface.
While here add the cross reference to iic(4) on iicbus(4).
CR: D210
Suggested by: jmg
Merge if_nf10bmac(4), a driver to support an NetFPGA-10G Embedded
CPU Ethernet Core.
The current version operates on a simple PIO based interface connected
to a NetFPGA-10G port.
To avoid confusion: this driver operates on a CPU running on the FPGA,
e.g. BERI/mips, and is not suited for the PCI host interface.
Adjust the register layout to allow for 64bit registers in the
future for nf10bmac(4). Also, add support for and enable RX interrupts.
Allow switching between 32bit and 64bit bus width data access at compile
time by setting NF10BMAC_64BIT and using a REGWTYPE #define to set correct
variable and return value widths.
Adjust comments to indicate the 32 or 64bit register widths.
Relnotes: yes
Sponsored by: DARPA/AFRL
For BERI on NetFPGA assume HZ=100 by default.
Remove the uart support in favour of a "jtag-uart" interface imitation
providing a much simpler interface, directly exported to the host,
allowing the toolchain to be shared with BERI on Altera. [1]
Submitted by: Jong Hun HAN (jong.han cl.cam.ac.uk) [1]
Sponsored by: DARPA/AFRL
265941,265951,266390,266550,266910:
Various bhyve fixes:
- Don't save host's return address in 'struct vmxctx'.
- Permit non-32-bit accesses to local APIC registers.
- Factor out common ioport handler code.
- Use calloc() in favor of malloc + memset.
- Change the vlapic timer frequency to be in the ballpark of contemporary
hardware.
- Allow the guest to read the TSC via MSR 0x10.
- A VMCS is always inactive when it exits the vmx_run() loop. Remove
redundant code and the misleading comment that suggest otherwise.
- Ignore writes to microcode update MSR. This MSR is accessed by RHEL7
guest.
Add KTR tracepoints to annotate wrmsr and rdmsr VM exits.
- Provide an alias for the userboot console and name it 'comconsole'.
- Use EV_ADD to create an mevent and EV_ENABLE to enable it.
- abort(3) the process in response to a VMEXIT_ABORT.
- Don't include the guest memory segments in the bhyve(8) process core dump.
- Make the vmx asm code dtrace-fbt-friendly.
- Allow vmx_getdesc() and vmx_setdesc() to be called for a vcpu that is in
the VCPU_RUNNING state.
- Enable VMX in the IA32_FEATURE_CONTROL MSR if it not enabled and the MSR
isn't locked.
Allow customization of the brand displayed in the boot menu.
If the user specifies in /boot/loader.conf:
loader_brand="mycustom-brand"
Then "mycustom-brand" will be executed instead of "fbsd-logo".
Submitted by: alfred
Obtained from: FreeNAS
Tell VM we now have ARM platforms with physically discontiguous memory.
Define the full 1024M of ram on the imx51 and imx53 boards.
Use a more professional uart device description.
Actually save the mpcore clock frequency retrieved from fdt data.
imx6..
- Don't call sdhci_init_slot() until after handling the FDT properties
related to detecting card presence.
- Flag several sysctl variables as tunables.
- Rework the cpu frequency management code for imx6 to add "operating
points" and min/max frequency controls.
generic timer...
- Setup both secure and non-secure timer IRQs.
We don't know our ARM security state, so one of them will operate.
- Don't set frequency, since it's unpossible in non-secure state.
Only rely on DTS clock-frequency value or get clock from timer.
