XDTP is used as the default SYSROOT for clang and thus should be an absolute path.
PR: arm/188249
Submitted by: Edgar Martinez <wink15987@gmail.com>
Reviewed by: imp
- Add cpu_cpwait to comply with the convention.
- Add missing TLB invalidations, especially in pmap_kenter & pmap_kremove
with distinguishing between D and ID pages.
- Modify pmap init/bootstrap invalidations to ID, just to be safe.
- Fix TLB-inv and PTE_SYNC ordering.
This combines changes submitted by ian@, cognet@, and Wojciech Macek,
which have all been tested together as a unit.
Perform sychronization (by "isb" barrier) after TTB is set. This
is done to ensure that TLB invalidation always executes after
TTB modification and operates on valid CP15 data (per specification).
Submitted by: Wojciech Macek <wma@semihalf.com>
Reviewed by: ian@, cognet@
This mimics the behaviour in clang and lets us build cleanly
the libdispatch port on platforms where the base gcc is still
the default compiler.
Bump __FreeBSD_version for ports.
Tested by: theraven
MFC after: 3 days
before changing the divisor bits in the register. We were writing a zero
to the register, which clears the enable, but also cleared the divisor bits
at the same time. That's a violation of the sdhci spec, which says the
divisor can only be changed when the clock is disabled. This has worked
okay on most hardware for years, but the TI OMAP controller would misbehave
after changing the divisor improperly.
Submitted by: Svatopluk Kraus <onwahe@gmail.com>
- Don't allow high-speed mode on OMAP4 due to hardware erratum.
- Check the proper bit in the status register when waiting for the
controller to come out of reset.
- Add handling for the "non-removable" fdt property by always returning
"card is present" status.
- Add the non-removable property for the MMC card on a Beaglebone Black.
- Add the non-removable property for Pandaboard as a workaround.
For Pandaboard the card detect pin is handled by the twl6030 fpga device
which gets an interrupt on pin change and then has to query the fpga
for the actual status. We don't have code to do that yet.
Submitted by: Svatopluk Kraus <onwahe@gmail.com>
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
Ensure that first_func is set to 0 on every iteration of the PCI slot
enumeration loop after the first. There is a continue statement that would
cause first_func to stay at 1 any PCI device where slot 0 has no functions
until we find a slot that does have a function. This would cause us to
not enumerate the first PCI function on the device.
Credit to markj@ for spotting the bug.
X-MFC-With: r264011
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.
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
3580 Want zvols to return volblocksize when queried for physical block size
illumos/illumos-gate@a0b60564df
It is irrelevant for FreeBSD, just reducing diff.
errors.
Reset the GPIO module during the initialization. This is guaranteed to be
the same as a hardware reset. Tested on AM335x (BBB) and checked against
the omap3 and omap4 TRM.
Do a better job freeing resources when there are errors and on
ti_gpio_detach().
It is an adapted merge from the vendor branch of:
701 UNMAP support for COMSTAR (in part related to ZFS)
2130 zvol DKIOCFREE uses nested DMU transactions
- if TARGET_ARCH is not defined and XDEV_ARCH is defined then early define
TARGET_ARCH to the valud of XDEV_ARCH: This allow the xdev-build target
to be able to correctly chose the compiler it needs to build
- Allow overwriting XDTP to allow a user to not chose where the xdev env will
live in
- Fix build for gcc only xdev (like ia64) by providing the proper -B to the
toolchain and not relying on gcc being installed already in base
- Fix TOOLS_PREFIX so the generated toolchain has the right default sysroot when
installed intead of getting the DESTDIR one
- Fix supporting DESTDIR
- Also overwrite CXX (needed for cross building c++ libraries with clang) and
CPP (needed to cross build some libraries when gcc is the target default
compiler but gcc is not installed on the building host)
Discussed with: imp
