when MBR contains only PMBR entry or it is bootcamp-compatible.
If MBR has PMBR entry and some other, the loader rejects it.
Make these checks to be less strict. If loader decided that PMBR
isn't suitable for GPT, it will use MBR.
Reported by: Paul Thornton
Tested by: Paul Thornton
MFC after: 1 week
- Display slice and partition as <auto> instead of 0 or -1 when they're
not set to specific values (the paritition=-1 was confusing folks).
- When loaderdev isn't set in the u-boot environment, say so rather
than displaying unknown device ''.
- Print the loader(8) ident/version info earlier, so that all device-
related info appears together afterwards.
The one change here that isn't purely cosmetic is to call setheap()
earlier. The comment says "Initialise heap as early as possible", now
that's more accurate. It shouldn't make any functional difference, but
may be safer if future changes lead to trying to allocate memory earlier.
setting the u-boot environment variable loaderdev=. It used to accept only
'disk' or 'net'. Now it allows specification of unit, slice, and partition
as well. In addition to the generic 'disk' it also accepts specific
storage device types such as 'mmc' or 'sata'.
If there isn't a loaderdev env var, the historical behavior is maintained.
It will use the first storage device it finds, or a network device if
no working storage device exists.
99% of the work on this was done by Patrick Kelsey, but I made some
changes, so if anything goes wrong, blame me.
Submitted by: Patrick Kelsey <kelsey@ieee.org>
by having uboot_autoload() do the fdt setup (which may load a file) rather
than waiting until we're actually in the process of launching the kernel.
As part of making this happen...
- Define LOADER_FDT_SUPPORT on the uboot/lib compile command line when
MK_FDT is set.
- Make fdt_setup_fdtb() public.
- Declare public fdt_whatever() functions in a header instead of using
scattered extern decls in .c files.
(1) Invoke cpp to bring in files via #include (although the old
/include/ stuff is supported still).
(2) bring in files from either vendor tree or freebsd-custom files
when building.
(3) move all dts* files from sys/boot/fdt/dts to
sys/boot/fdt/dts/${MACHINE} as appropriate.
(4) encode all the magic to do the build in sys/tools/fdt/make_dtb.sh
so that the different places in the tree use the exact same logic.
(5) switch back to gpl dtc by default. the bsdl one in the tree has
significant issues not easily addressed by those unfamiliar with
the code.
Apparently, LIBZFS is set to a non-empty string when WITHOUT_CDDL/WITHOUT_ZFS
are set, I think this is a bug, but work around this feature for now.
Reviewed by: grehan
Quartz is a tiny module utilized Freescale VF6xx
system-on-chip and development kit produced by
Device Solutions.
Quartz is available in a form of LGA (38x38x2mm)
or as a module with high-density connectors.
Sponsored by: Device Solutions
while this won't actually be used for anything (yet), it doesn't hurt to
ensure it is exposed to the tinderbox.
Requested by: imp, jmallett
MFC after: 3 weeks
fragments; while this won't actually be used for anything (yet), it
doesn't hurt to ensure it is exposed to the tinderbox.
Requested by: imp, jmallett
MFC after: 3 weeks
The first I2C controller is only used to manage the on-board devices (PMIC
and HDMI framer) and its bus is not exposed on the expasion headers.
With this change the following pins on the P9 expansion headers are now
reserved as I2C pins:
Pin 17 - I2C1 SCL
Pin 18 - I2C1 SDA
Pin 19 - I2C2 SCL
Pin 20 - I2C2 SDA
The I2C2 is the bus that should be used to read the contents of cape
eeproms.
Approved by: adrian (mentor, implicit)
these binaries aren't immediately useful on other MIPSes, still build them
as part of mips64 world in order to expose them to tinderbox.
MFC after: 3 weeks
Sponsored by: DARPA, AFRL
a 64-bit architecture, rather than trying to share the 32-bit MIPS ficl
configuration.
When building ficl on MIPS, don't conflate 32-bit and 64-bit ISAs -- unlike
x86, we don't want a 32-bit loader on a 64-bit CPU. Use quite conservative
code generation -- e.g., softfloat, no GOT, etc -- suitable for early boot.
MFC after: 3 weeks
Sponsored by: DARPA, AFRL
The name is taken from the u-boot env vars fdtfile or fdt_file. If the
name isn't fully-qualified a search is done in module_path locations.
The search order for a usable dtb in fdt_setup_fdtp() is now
- A dtb loaded with an explicit "load -t dtb" command.
- A dtb already loaded into memory somehow[*] and pointed to by fdt_to_load.
- A dtb in the memory pointed to by the u-boot env vars fdtaddr or fdt_addr.
- A file named by the u-boot env vars fdtfile or fdt_file.
- A static dtb compiled into the kernel.
* Presumably by some arch-specific command or code.
arguments from type,filename to filename,type to be consistant with other
public file_whatever() functions, and change it to return a pointer to
the preloaded_file struct describing the file. Adjust existing callers.
The old code basically said it was going to use some particular blob
without knowing whether it could successfully do so, then it would invoke
the function to do that and return its status. If it failed, you were
done, even if other blobs might be available. Now the code attempts to use
some particular blob and if that succeeds it says so and returns success,
otherwise it moves on to try another potential blob.
One specific problem this solves is when u-boot sets an fdtaddr variable
to point to some memory address, then doesn't actually load a blob at
that address. Now the header check will fail, and the code will move
on to the fallback dtb compiled into the kernel (if any).
If a "loaderdev=<device>" env variable is set and the named device
exists, it is used. If the device doesn't exist, fall back to the
historic "probe" loop that prefers disk devices over network devices.
If the env var is not set, preserve the historic behavior of using the
first working disk device provided by u-boot, or a network device if no
functional disk device is found and a network device exists.
The old probe loop is reworked so that it checks all bootable devices
provided by u-boot rather than taking an early-out on the first device
found. This results in the cosmetic change of listing all potential boot
devices for the user, but the behavior of which device it chooses is the
same as it has always been.
Modelled after the i386 zfsloader. However, with no
2nd stage zfsboot to search for a bootable dataset,
attempt a ZFS boot if there is more than one ZFS
dataset found during the disk probe.
sys/boot/userboot/zfs
- build the ZFS boot library
sys/boot/userboot/userboot/
conf.c
- Add the ZFS pool and filesystem tables
devicename.c
- correctly format ZFS devices
main.c
- increase the size of the libstand malloc pool
to account for the increased usage from ZFS buffers
- probe for a ZFS dataset, and if one is
found, attempt to boot from it.
usr.sbin/bhyveload/bhyveload.c
- allow multiple invocations of the '-d' option
to specify multiple disks e.g. a raidz set.
Up to 32 disks are supported.
Tested with various combinations of GPT, MBR, single
and multiple disks, RAID-Z, mirrors.
Reviewed by: neel
Discussed with: avg
Tested by: Michael Dexter and others
MFC after: 3 weeks
source shows that board vendors seem to be about evenly split on this.
This commit is a trivial change to note that while the previous change
was supposed to be whitespace only, this functional change also crept in.
The added lines were:
/* Board vendors use both fdtaddr and fdt_addr names. Grrrr. */
if (s == NULL)
s = ub_env_get("fdt_addr");
The temperature monitor device is enabled to sample the die temperature at
16hz. The temperature is published via sysctl. A callout routine at 10hz
monitors the temperature and throttles back the cpu if the temperature
goes over a user-settable throttle point (by default 10C less than the
critical high-point temperature for the chip). The hardware is supposed
to be able to deliver an interrupt when the temperature exceeds a settable
limit, but the interrupt never arrives so for now a callout does the job.
At attach time we read the maximum cpu frequency the chip is allowed to run
at and the cpu is set to run at that speed. It's reported at attach time.
A sysctl variable reports the current speed when queried.
New sysctl values:
dev.imx6_anatop.0.cpu_mhz: 984
dev.imx6_anatop.0.temperature: 37.9C
dev.imx6_anatop.0.throttle_temperature: 95.0C
Steven Lawrance did the initial heavy lifting on this, but I changed
enough stuff that I'm the one to blame if anything breaks.
Submitted by: Steven Lawrance <stl@koffein.net>