1
0
mirror of https://git.FreeBSD.org/src.git synced 2024-12-20 11:11:24 +00:00
Commit Graph

23 Commits

Author SHA1 Message Date
Bjoern A. Zeeb
d2b74735b8 For now remove options FLOWTABLE from the remaining GENERIC kernel
configurations and make it opt-in for those who want it.  LINT will
still build it.

While it may be a perfect win in some scenarios, it still troubles users
(see PRs) in general cases.  In addition we are still allocating resources
even if disabled by sysctl and still leak arp/nd6 entries in case of
interface destruction.

Discussed with:	qingli (2010-11-24, just never executed)
Discussed with: juli (OCTEON1)
PR:		kern/148018, kern/155604, kern/144917, kern/146792
MFC after:	2 weeks
2011-03-19 15:50:34 +00:00
Warner Losh
266a41b11e Use simplified ldscripts rather than specific ones 2011-01-20 19:17:05 +00:00
Warner Losh
5d8f773b87 Kill redundant cpu line 2011-01-17 23:00:23 +00:00
Juli Mallett
15fe2454ae o) Expand the CIU driver to be aware of newly-allocated parts of the IRQ range.
o) Add 'octm', a trivial driver for the 10/100 management ports found on some
   Octeon systems.
o) Make the Simple Executive's management port helper routines compile on
   FreeBSD (namely by not doing math on void pointers.)
o) Add a cvmx_mgmt_port_sendm routine to the Simple Executive to send an mbuf
   so there is only one copy in the transmit path, rather than having to first
   copy the mbuf to an intermediate buffer and then copy that to the Simple
   Executive's transmit ring.
o) Properly work out MII addresses of management ports on the Lanner MR-730.
   XXX The MR-730 also needs some patches to the MII read/write routines, but
       this is sufficient for now.  Media detection will be fixed in the future
       when I can spend more time reading the vendor-supplied patches.
2011-01-10 03:48:41 +00:00
Warner Losh
161b83b959 Remove the 'machine mips' from DEFAULTS. Put the proper 'machine mips
mipsel' or 'machine mips mipseb' into the config file (with a few 64's
tossed in for good measure).  This will let us build the proper
kernels with different worlds as part of make universe.
2010-11-13 22:34:12 +00:00
Juli Mallett
f05957f7c6 o) Make it possible to attach a PHY directly to an octe device rather than
using miibus, since for some devices that use multiple addresses on the bus,
   going through miibus may be unclear, and for devices that are not standard
   MII PHYs, miibus may throw a fit, necessitating complicated interfaces to
   fake the interface that it expects during probe/attach.
o) Make the mv88e61xx SMI interface in octe attach a PHY directly and fix some
   mistakes in the code that resulted from trying too hard to present a nice
   interface to miibus.
o) Add a PHY driver for the mv88e61xx.  If attached (it is optional in kernel
   compiles so the default behavior of having a dumb switch is preserved) it
   will place the switch in a VLAN-tagging mode such that each physical port
   has a VLAN associated with it and interfaces for the VLANs can be created to
   address or bridge between them.
   XXX It would be nice for this to be part of a single module including the
       SMI interface, and for it to fit into a generic switch configuration
       framework and for it to use DSA rather than VLANs, but this is a start
       and gives some sense of the parameters of such frameworks that are not
       currently present in FreeBSD.  In lieu of a switch configuration
       interface, per-port media status and VLAN settings are in a sysctl tree.
   XXX There may be some minor nits remaining in the handling of broadcast,
       multicast and unknown destination traffic.  It would also be nice to go
       through and replace the few remaining magic numbers with macros at some
       point in the future.
   XXX This has only been tested with the MV88E6161, but it should work with
       minimal or no modification on related switches, so support for probing
       them was included.

Thanks to Pat Saavedra of TELoIP and Rafal Jaworowski of Semihalf for their
assistance in understanding the switch chipset.
2010-10-13 09:17:44 +00:00
Juli Mallett
2e9de9047c Make the OCTEON1 configuration look like a normal GENERIC configuration. In
particular, add PCI and USB buses and most devices.  Also move to using ULE,
adding INET6, turning on WITNESS by default, etc.
2010-10-02 01:24:20 +00:00
Warner Losh
747e7efda0 TARGET_64BIT isn't needed anymore, GC it (partial merge from tbemd). 2010-09-13 16:39:33 +00:00
Juli Mallett
cea2b8b915 Update the port of FreeBSD to Cavium Octeon to use the Cavium Simple Executive
library:
o) Increase inline unit / large function growth limits for MIPS to accommodate
   the needs of the Simple Executive, which uses a shocking amount of inlining.
o) Remove TARGET_OCTEON and use CPU_CNMIPS to do things required by cnMIPS and
   the Octeon SoC.
o) Add OCTEON_VENDOR_LANNER to use Lanner's allocation of vendor-specific
   board numbers, specifically to support the MR320.
o) Add OCTEON_BOARD_CAPK_0100ND to hard-wire configuration for the CAPK-0100nd,
   which improperly uses an evaluation board's board number and breaks board
   detection at runtime.  This board is sold by Portwell as the CAM-0100.
o) Add support for the RTC available on some Octeon boards.
o) Add support for the Octeon PCI bus.  Note that rman_[sg]et_virtual for IO
   ports can not work unless building for n64.
o) Clean up the CompactFlash driver to use Simple Executive macros and
   structures where possible (it would be advisable to use the Simple Executive
   API to set the PIO mode, too, but that is not done presently.)  Also use
   structures from FreeBSD's ATA layer rather than structures copied from
   Linux.
o) Print available Octeon SoC features on boot.
o) Add support for the Octeon timecounter.
o) Use the Simple Executive's routines rather than local copies for doing reads
   and writes to 64-bit addresses and use its macros for various device
   addresses rather than using local copies.
o) Rename octeon_board_real to octeon_is_simulation to reduce differences with
   Cavium-provided code originally written for Linux.  Also make it use the
   same simplified test that the Simple Executive and Linux both use rather
   than our complex one.
o) Add support for the Octeon CIU, which is the main interrupt unit, as a bus
   to use normal interrupt allocation and setup routines.
o) Use the Simple Executive's bootmem facility to allocate physical memory for
   the kernel, rather than assuming we know which addresses we can steal.
   NB: This may reduce the amount of RAM the kernel reports you as having if
       you are leaving large temporary allocations made by U-Boot allocated
       when starting FreeBSD.
o) Add a port of the Cavium-provided Ethernet driver for Linux.  This changes
   Ethernet interface naming from rgmxN to octeN.  The new driver has vast
   improvements over the old one, both in performance and functionality, but
   does still have some features which have not been ported entirely and there
   may be unimplemented code that can be hit in everyday use.  I will make
   every effort to correct those as they are reported.
o) Support loading the kernel on non-contiguous cores.
o) Add very conservative support for harvesting randomness from the Octeon
   random number device.
o) Turn SMP on by default.
o) Clean up the style of the Octeon kernel configurations a little and make
   them compile with -march=octeon.
o) Add support for the Lanner MR320 and the CAPK-0100nd to the Simple
   Executive.
o) Modify the Simple Executive to build on FreeBSD and to build without
   executive-config.h or cvmx-config.h.  In the future we may want to
   revert part of these changes and supply executive-config.h and
   cvmx-config.h and access to the options contained in those files via
   kernel configuration files.
o) Modify the Simple Executive USB routines to support getting and setting
   of the USB PID.
2010-07-20 19:25:11 +00:00
Juli Mallett
56c96c364e Add bpf and random to Octeon configurations, since they're needed to run
dhclient and ssh respectively.

Reviewed by:	imp
2010-03-11 22:29:45 +00:00
Neel Natu
40e359dc3a Get rid of unused options: KERNPHYSADDR, KERNVIRTADDR, PHYSADDR, PHYS_ADDR_64BIT
Discussed with: gonzo, imp
2010-02-20 06:39:14 +00:00
Attilio Rao
c1210a7d97 Adjust style (following the already existing rules) for the newly
introduced option DEADLKRES.

Reported by:	danfe, julian, avg
2010-02-15 23:44:48 +00:00
Attilio Rao
88cbfa852e Add the options DEADLKRES (introducing the deadlock resolver thread) in
the 'debugging' section of any HEAD kernel and enable for the mainstream
ones, excluding the embedded architectures.
It may, of course, enabled on a case-by-case basis.

Sponsored by:	Sandvine Incorporated
Requested by:	emaste
Discussed with:	kib
2010-02-10 16:30:04 +00:00
Warner Losh
1e027851aa Make a note that this file is the 64-bit version and experimental and
point people at the OCTEON1-32 file instead.
2010-01-27 16:21:32 +00:00
Warner Losh
e93f9d43a8 Cope with the octeon1->cavium move. 2010-01-11 04:40:38 +00:00
Warner Losh
04c50bba10 Include opt_cputype.h for all .c and .S files referencing TARGET_OCTEON.
Spell ld script name right.

# for the most part, we need to enhance infrastructure to obviate the need
# for such an intrusive option.
2009-11-24 16:32:31 +00:00
Warner Losh
715f0e291b Get rid of redundant .kernel in these names. 2009-11-24 14:57:50 +00:00
Warner Losh
6d53fe9b81 Use new ldscript.mips.mips64
Also, declare this to be a 64-bit target.

We get to the final link now and die in the linker script..
2009-08-15 04:29:18 +00:00
Warner Losh
220d1e7fb0 Go for broke: configure this to build mips64 N64 binary. 2009-07-05 06:49:56 +00:00
Warner Losh
78e0ef6f04 Kludge: pretend to be ISA_MIPS32 for the moment. 2009-06-14 06:12:21 +00:00
Warner Losh
0d633f654d o Move the driveid.h file
o lots of tweaks to header paths.
o comment out SMP for the moment

# we now make it through the .c make depend, the .s needs more work.
2009-06-14 04:26:56 +00:00
Warner Losh
b9bf0e01e9 Actually rename the files this time. Also, start to fix OCTEON1 so it
can configure.
2009-06-14 03:44:43 +00:00
Warner Losh
b502e57d9e Move the octeon port to its more correct location. Any port for the
OCTEON2 family of processors should live in mips/octeon2.  Not enough
is know abotu the former to know if the same port can be used for both
yet.
2009-06-14 03:01:39 +00:00