#
552311f4 |
| 17-Jul-2013 |
Xin LI <delphij@FreeBSD.org> |
IFC @253398
|
#
2565edc4 |
| 09-Jul-2013 |
Andriy Gapon <avg@FreeBSD.org> |
amd64: use -mno-omit-leaf-frame-pointer in addition to -fno-omit-frame-pointer
... in kernel builds. This is to make behavior of clang consistent with behavior of gcc.
MFC after: 2 weeks
|
#
cfe30d02 |
| 19-Jun-2013 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Merge fresh head.
|
Revision tags: release/8.4.0, release/9.1.0 |
|
#
300675f6 |
| 27-Nov-2012 |
Alexander Motin <mav@FreeBSD.org> |
MFC
|
#
e477abf7 |
| 27-Nov-2012 |
Alexander Motin <mav@FreeBSD.org> |
MFC @ r241285
|
#
a10c6f55 |
| 11-Nov-2012 |
Neel Natu <neel@FreeBSD.org> |
IFC @ r242684
|
#
23090366 |
| 04-Nov-2012 |
Simon J. Gerraty <sjg@FreeBSD.org> |
Sync from head
|
#
d6b3aaf8 |
| 16-Oct-2012 |
Oleksandr Tymoshenko <gonzo@FreeBSD.org> |
Split sdhci driver in two parts: sdhci and sdhci_pci. sdchi encapsulates a generic SD Host Controller logic that relies on actual hardware driver for register access.
sdhci_pci implements driver for
Split sdhci driver in two parts: sdhci and sdhci_pci. sdchi encapsulates a generic SD Host Controller logic that relies on actual hardware driver for register access.
sdhci_pci implements driver for PCI SDHC controllers using new SDHCI interface
No kernel config modifications are required, but if you load sdhc as a module you must switch to sdhci_pci instead.
show more ...
|
#
9215d178 |
| 13-Sep-2012 |
Brooks Davis <brooks@FreeBSD.org> |
Introduce a new make variable COMPILER_TYPE that specifies what type of compiler is being used (currently clang or gcc). COMPILER_TYPE is set in the new bsd.compiler.mk file based on the value of th
Introduce a new make variable COMPILER_TYPE that specifies what type of compiler is being used (currently clang or gcc). COMPILER_TYPE is set in the new bsd.compiler.mk file based on the value of the CC variable or, should it prove informative, by running ${CC} --version and examining the output.
To avoid negative performance impacts in the default case and correct value for COMPILER_TYPE type is determined and passed in the environment of submake instances while building world.
Replace adhoc attempts at determining the compiler type by examining CC or MK_CLANG_IS_CC with checks of COMPILER_TYPE. This eliminates bootstrapping complications when first setting WITH_CLANG_IS_CC.
Sponsored by: DARPA, AFRL Reviewed by: Yamaya Takashi <yamayan@kbh.biglobe.ne.jp>, imp, linimon (with some modifications post review) MFC after: 2 weeks
show more ...
|
#
24bf3585 |
| 04-Sep-2012 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Merge head r233826 through r240095.
|
#
7750ad47 |
| 22-Aug-2012 |
Marcel Moolenaar <marcel@FreeBSD.org> |
Sync FreeBSD's bmake branch with Juniper's internal bmake branch.
Requested by: Simon Gerraty <sjg@juniper.net>
|
#
4da573d9 |
| 15-Aug-2012 |
Oleksandr Tymoshenko <gonzo@FreeBSD.org> |
Merging of projects/armv6, part 3
r238211: Support TARGET_ARCH=armv6 and TARGET_ARCH=armv6eb
This adds a new TARGET_ARCH for building on ARM processors that support the ARMv6K multiprocessor extens
Merging of projects/armv6, part 3
r238211: Support TARGET_ARCH=armv6 and TARGET_ARCH=armv6eb
This adds a new TARGET_ARCH for building on ARM processors that support the ARMv6K multiprocessor extensions. In particular, these processors have better support for TLS and mutex operations.
This mostly touches a lot of Makefiles to extend existing patterns for inferring CPUARCH from ARCH. It also configures: * GCC to default to arm1176jz-s * GCC to predefine __FreeBSD_ARCH_armv6__ * gas to default to ARM_ARCH_V6K * uname -p to return 'armv6' * make so that MACHINE_ARCH defaults to 'armv6' It also changes a number of headers to use the compiler __ARM_ARCH_XXX__ macros to configure processor-specific support routines.
Submitted by: Tim Kientzle <kientzle@freebsd.org>
show more ...
|
#
de720122 |
| 15-Jul-2012 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Merge head r236710 through r238467.
|
#
6cf87ec8 |
| 13-Jul-2012 |
Xin LI <delphij@FreeBSD.org> |
IFC @238412.
|
#
b652778e |
| 11-Jul-2012 |
Peter Grehan <grehan@FreeBSD.org> |
IFC @ r238370
|
#
cd95660f |
| 03-Jul-2012 |
David E. O'Brien <obrien@FreeBSD.org> |
Revert r222186 per instructions for FreeBSD 10. (a 10-CURRENT share/mk is already required to build a 10-CURRENT kernel on 9-STABLE)
|
#
31ccd489 |
| 28-May-2012 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Merge head r233826 through r236168.
|
#
6a068746 |
| 15-May-2012 |
Alexander Motin <mav@FreeBSD.org> |
MFC
|
#
4574da7f |
| 01-May-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
Bring over the first part of the etherswitch framework - an MDIO bus and MDIO/MII rendezvous proxy.
* Add an 'mdio' bus, which is the "IO" side of an MII bus (but by design can be anything which i
Bring over the first part of the etherswitch framework - an MDIO bus and MDIO/MII rendezvous proxy.
* Add an 'mdio' bus, which is the "IO" side of an MII bus (but by design can be anything which implements the underlying register access API.) * Add 'miiproxy' and 'mdioproxy', which provides a rendezvous mechanism for MII busses to appear hanging off arbitrary busses (ie, that aren't necessarily a traditional looking MII bus.)
MII busses can now hang off anything that implements an mdiobus.
For the AR71xx SoC, there's one MDIO bus but two MII busses. So to properly support two or more real PHYs, this can be done:
# arge0 MDIO bus - there's no arge1 MDIO bus for AR71xx hint.argemdio.0.at="nexus0" hint.argemdio.0.maddr=0x19000000 hint.argemdio.0.msize=0x1000 hint.argemdio.0.order=0
# Create two mdioproxy instances hint.mdioproxy.0.at="mdio0" hint.mdioproxy.1.at="mdio0"
# .. and with a follow-up patch hint.arge.0.mdio=mdioproxy0 hint.arge.1.mdio=mdioproxy0
TODO:
* Do a sweep or two and add appropriate locking in mdio/mdioproxy/miiproxy.
Submitted by: Stefan Bethke <stb@lassitu.de> Reviewed by: ray
show more ...
|
#
38f1b189 |
| 26-Apr-2012 |
Peter Grehan <grehan@FreeBSD.org> |
IFC @ r234692
sys/amd64/include/cpufunc.h sys/amd64/include/fpu.h sys/amd64/amd64/fpu.c sys/amd64/vmm/vmm.c
- Add API to allow vmm FPU state init/save/restore.
FP stuff discussed with: kib
|
Revision tags: release/8.3.0_cvs, release/8.3.0 |
|
#
8833b15f |
| 03-Apr-2012 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Merge head r232686 through r233825 into projects/pf/head.
|
#
84db023e |
| 29-Mar-2012 |
Juli Mallett <jmallett@FreeBSD.org> |
Assume a big-endian default on MIPS and drop the "eb" suffix from MACHINE_ARCH. This makes our naming scheme more closely match other systems and the expectations of much third-party software. MIPS
Assume a big-endian default on MIPS and drop the "eb" suffix from MACHINE_ARCH. This makes our naming scheme more closely match other systems and the expectations of much third-party software. MIPS builds which are little-endian should require and exhibit no changes. Big-endian TARGET_ARCHes must be changed: From: To: mipseb mips mipsn32eb mipsn32 mips64eb mips64
An entry has been added to UPDATING and some foot-shooting protection (complete with warnings which should become errors in the near future) to the top-level base system Makefile.
show more ...
|
#
867099fa |
| 08-Mar-2012 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Merge head up to r232685 to projects/pf/head.
|
#
2651e350 |
| 04-Mar-2012 |
Dimitry Andric <dim@FreeBSD.org> |
Revert r232473. I have been convinced by Doug Barton and Bjoern Zeeb that it is better to error out when people attempt to build using the wrong bsd.*.mk files, than to silently ignore the problem.
Revert r232473. I have been convinced by Doug Barton and Bjoern Zeeb that it is better to error out when people attempt to build using the wrong bsd.*.mk files, than to silently ignore the problem.
This means, that after this commit, if you want to build kernel modules by hand (or via a port) from a head source tree, you *must* make sure the files in /usr/share/mk are in sync with that tree. If that isn't possible, for example when you are running on an older FreeBSD branch, you can:
- Run "make buildenv" from your head source tree, to have the correct environment setup. (It's advisable to have run "make buildworld", or at a minimum "make toolchain" first.) - Alternatively, set MAKESYSPATH to the share/mk directory under your head source tree. If your build tools are too old, other problems may still occur. - Alternatively, use "make -m" and specify the share/mk directory under your head source tree. Again, build tools that are too old may still result in trouble.
MFC after: 2 weeks
show more ...
|
#
2677e7fe |
| 03-Mar-2012 |
Dimitry Andric <dim@FreeBSD.org> |
After r232322, it turned out many people (and some ports) are building kernel modules using their old installed /usr/share/mk/bsd.*.mk files, instead of the updated ones in their source tree. This l
After r232322, it turned out many people (and some ports) are building kernel modules using their old installed /usr/share/mk/bsd.*.mk files, instead of the updated ones in their source tree. This leads to errors like:
"sys/conf/kmod.mk", line 111: Malformed conditional (${MK_CLANG_IS_CC} == "no" && ${CC:T:Mclang} != "clang")
Obviously, these errors will go away after a "make installworld", or alternatively, by using "make buildenv" before attempting to manually build modules.
However, since it is apparently an expected use case to build using old .mk files, change the way we test for clang, so it also works when the MK_CLANG_IS_CC macro doesn't exist.
Note the conditional expressions are becoming rather unreadable now, but I will attempt to fix that on a followup commit.
MFC after: 2 weeks
show more ...
|