This is an AR71xx based board with 8MB flash, 64MB RAM, a
Mini-PCI+ slot (see below) and a single 10/100/1000baseT
ethernet port. It also has two USB ports.
This is an easier board than most to add as it doesn't have a
switch PHY on-board. This made it (mostly) trivial to craft a
working configuration.
Things to note:
* This, like most other reference boards, use uboot rather then
redboot. It means that you typically have to manually flash
both the kernel and rootfs partitions.
* Since there's currently no (nice) way to extract out the
ethernet MAC and RAM from the uboot environment, the RAM
will default to 32mb and the MAC will be something very
incorrect. I'll try to fix this up in a subsequent commit
or two, even if it's just some hard-coded nonsense in
ar71xx_machdep.c for now.
* The board is designed for a specific model of mini-PCI+
NIC which never made it into production. Normal mini-PCI
NICs will work fine; if you happen to have the NIC in question
then it will work fine with this board.
bits.
The ROUERSTATION and RSPRO variants contain:
* the board specific bits (eg the RTC for RSPRO, later on it'll
include the GPIO/LED definitions);
* the boot specific bits (eg, on-board flash, usb flash, etc).
For now the AR71XX_BASE file contains the common board config,
drivers and net80211/ath wireless drivers.
I'll follow this up with config files for the other boards I
have (eg the Ubiquiti LSSR71, as well as some Mikrotik boards
that use the AR71XX and atheros reference boards) which will
be quite easy to do now.
* Add in a default GPIO section for AR91XX_BASE.hints, which doesn't
define the GPIO function masks or any GPIO pines.
* Add in the GPIO line definitions for LEDs and GPIO pins for the
TP-WR1043nd.
I've verified the LEDs work fine using gpioset.
the second-last 64k seems to be the default firmware board configuration
area.
Since I have no idea whether uboot uses it or not - and it's prefixed
with an atheros eeprom signature (0xaa55), I figure the safest thing
to do is mark it as read-only.
I've modified my local tplink firmware building program to generate
a board configuration section - which is separate to this partition.
It's located in the 64k _before_ this particular 64k.
The firmware build program from OpenWRT never initialises those
values and the firmware images from tplink also leave it 0x0, so I
don't currently know what the exact, correct details should be.
The default flash layout gives only 1 megabyte for the kernel, gzipped.
The uboot firmware running on this device only supports gzip, not lzma, so
we actually _do_ have to try and slim the kernel down a bit.
But, since I can't actually do that at the present, I'm opting to:
* extend the kernel from 1mb to 2mb;
* have rootfs fill the rest of that, save 64k;
* eventually I'll hide a 64k config partition at the end, between the
end of rootfs and the ART (radio configuration data.)
The uboot firmware doesn't care about the partition layout. It just
expects the kernel application image to sit at 0xbf020000 (right after
the 128k uboot image.) The uboot header isn't actually read either -
it's "faked" from a "tplink" flash image header. So as long as the
map configuration here matches what is being written out via the
tplink firmware generator, everything is a-ok.
A previous commit disabled compiling the AR9130 support in the default
HAL build in the kernel. Since the AR9130 support won't actually function
without AH_SUPPORT_AR9130 (and that abomination needs to be undone at some
point, in order to allow USB 11n NICs to also work), we now have to
explicitly compile it in.
But since the 11n RF backends don't (currently) join the RF linker set,
one has to compile in _an_ RF backend for the HAL to compile.
At some point it would be nice to correctly update the bus glue to make
this "correct", including having the DDR flush occur in the right spot
(ie, any AHB interrupt.)
Create std.XLP for configuration options, which is included by the
conf files. The files XLP, XLPN32 and XLP64 will have mostly ABI related
options.
Also move uart and pci to mips/nlm/std.xlp since all XLP configurations
needs these devices.
Obtained from: prabhath at netlogicmicro com (intial version)
all the architectures.
The option allows to mount non-MPSAFE filesystem. Without it, the
kernel will refuse to mount a non-MPSAFE filesytem.
This patch is part of the effort of killing non-MPSAFE filesystems
from the tree.
No MFC is expected for this patch.
Tested by: gianni
Reviewed by: kib
- update xlp_machdep.c to read arguments from FDT if FDT support is
compiled in.
- define rmi_uart_bus_space, and use it as fdtbus_bs_tag
- update conf files for FDT support
- add default dts file xlp-basic.dts
* Update the hardware access register definitions and functions to bring
them in line with other Netlogic software.
* Update the platform bus to use PCI even for on-chip devices. Add a dummy
PCI driver to ignore on-chip devices which do not need driver.
* Provide memory and IRQ resource allocation code for on-chip devices
which cannot get it from PCI config.
* add support for on-chip PCI and USB interfaces.
* update conf files, enable pci and retain old MAXCPU until we can support
>32 cpus.
Approved by: re(kib), jmallett
From now on, default values for FreeBSD will be 64 maxiumum supported
CPUs on amd64 and ia64 and 128 for XLP. All the other architectures
seem already capped appropriately (with the exception of sparc64 which
needs further support on jalapeno flavour).
Bump __FreeBSD_version in order to reflect KBI/KPI brekage introduced
during the infrastructure cleanup for supporting MAXCPU > 32. This
covers cpumask_t retiral too.
The switch is considered completed at the present time, so for whatever
bug you may experience that is reconducible to that area, please report
immediately.
Requested by: marcel, jchandra
Tested by: pluknet, sbruno
Approved by: re (kib)
This patch adds support for the Netlogic XLP mips64 processors in
the common MIPS code. The changes are :
- Add CPU_NLM processor type
- Add cases for CPU_NLM, mostly were CPU_RMI is used.
- Update cache flush changes for CPU_NLM
- Add kernel build configuration files for xLP.
In collaboration with: Prabhath Raman <prabhathpr at netlogicmicro com>
Approved by: bz(re), jmallett, imp(mips)
* enable 11n
* add ath_ahb so the AHB<->ath glue is linked in
* disable descriptor order swapping, it isn't needed here
* disable interrupt mitigation, it isn't supported here
device in /dev/ create symbolic link with adY name, trying to mimic old ATA
numbering. Imitation is not complete, but should be enough in most cases to
mount file systems without touching /etc/fstab.
- To know what behavior to mimic, restore ATA_STATIC_ID option in cases
where it was present before.
- Add some more details to UPDATING.
stack. It means that all legacy ATA drivers are disabled and replaced by
respective CAM drivers. If you are using ATA device names in /etc/fstab or
other places, make sure to update them respectively (adX -> adaY,
acdX -> cdY, afdX -> daY, astX -> saY, where 'Y's are the sequential
numbers for each type in order of detection, unless configured otherwise
with tunables, see cam(4)).
ataraid(4) functionality is now supported by the RAID GEOM class.
To use it you can load geom_raid kernel module and use graid(8) tool
for management. Instead of /dev/arX device names, use /dev/raid/rX.
This is a MIPS4KC CPU with various embedded peripherals, including
wireless and ethernet support.
This commit includes the platform, UART, ethernet MAC and GPIO support.
The interrupt-driven GPIO code is disabled for now pending GPIO changes
from the submitter.
Submitted by: Aleksandr Rybalko <ray@dlink.ua>
Introduce the AHB glue for Atheros embedded systems. Right now it's
hard-coded for the AR9130 chip whose support isn't yet in this HAL;
it'll be added in a subsequent commit.
Kernel configuration files now need both 'ath' and 'ath_pci' devices; both
modules need to be loaded for the ath device to work.
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
- Remove sys/conf/ldscript.mips.64 and sys/conf/ldscript.mips.n32 and use
ldscript.mips for all ABIs. The default OUTPUT_FORMAT of the toolchain
is correct.
- Remove LDSCRIPT_NAME entires from XLR n32 and n64 conf files.
- Remove TARGET_BIG_ENDIAN from XLR conf files.
- Fix machine entry in XLRN32
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.
running an o32 kernel safely, and would have to add interrupt disabling and
reenabling to a bunch of macros in the Simple Executive sources to support it.
The only reason one would run an o32 kernel on Octeon would be to run o32 world,
which is better worked towards by adding o32 binary compatibility to n64 kernels
along with, eventually, supporting multilib systems so o32 binaries can run
alongside n32 and n64 ones.
Discussed with: imp
- Major update to xlr_i2c.c: do multi-byte ops correctly, remove unnecessary
code, add mutex to protect bus operations, style(9) fixes.
- Drivers for I2C devices on XLR/XLS engineering boards, ds1374u RTC, max6657
temparature sensor and at24co2n EEPROM.
Submitted by: Sreekanth M. S. (kanthms at netlogicmicro com)
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.
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.
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.
am now able to run 32 cores ok.. but I still will hang
on buildworld with a NFS problem. I suspect I am missing
a patch for the netlogic rge driver.
JC check and see if I am missing anything except your
core-mask changes
Obtained from: JC
physical addresses.
o) Set a local maxmem in sb_machdep.c to avoid trying to use pages over 2^64
under 32-bit ABIs. Our pmap needs corrected to use vm_paddr_t consistently,
then we can make vm_paddr_t 64-bit under 32-bit ABIs and add code in pmap
to limit phys_avail by the maximum PFN that a 32-bit PTE can hold.
that turned out to be unrelated, and the rest was, as pointed out by Neel,
just wrong-headed.
o) Tweak mem.c to fix use of /dev/kmem for direct-mapped addresses.
this in the Sibyte PCI hostbridge driver instead.
The nexus driver sees resource allocation requests for memory and irq
resources only. These are legitimate resources on all MIPS platforms.
Suggested by: imp
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
The platform that supports SMP currently is a SWARM with a dual-core Sibyte
processor. The kernel config file to use is SWARM_SMP.
Reviewed by: imp, rrs
locks up in make buildworld.
You need to follow the mips wiki for building
the nfs partition and setup things to mount there
(in the conf and in your bootp setup).
I think these are the relevant changes, but definitely are a superset
of them. Software archaeologists are invited to check the branch
itself for the details.
r199695 | imp | 2009-11-23 00:49:50 -0700 (Mon, 23 Nov 2009) | 2 lines
Specify loader script and load address
r198263 | neel | 2009-10-19 22:31:20 -0600 (Mon, 19 Oct 2009) | 7 lines
The default KERNLOADADDR does not work on MALTA hardware. On my platform the
"First free SDRAM address" reported by YAMON is 0x800b6e61.
So use a conservative KERNLOADADDR of 0x80100000.
Approved by: imp (mentor)
r194163 | imp | 2009-06-14 00:12:21 -0600 (Sun, 14 Jun 2009) | 2 lines
Kludge: pretend to be ISA_MIPS32 for the moment.
r192864 | gonzo | 2009-05-26 16:40:12 -0600 (Tue, 26 May 2009) | 4 lines
- Replace CPU_NOFPU and SOFTFLOAT options with CPU_FPU. By default
we assume that there is no FPU, because majority of SoC does
not have it.
r187461 | gonzo | 2009-01-19 21:24:03 -0700 (Mon, 19 Jan 2009) | 3 lines
- KERNLOADADDR should be defined with makeoption.
Redboot loads kernel now
r187418 | gonzo | 2009-01-18 19:37:10 -0700 (Sun, 18 Jan 2009) | 4 lines
- Add trampoline stuff for bootloaders that do not support ELF
- Replace arm'ish KERNPHYSADDR/KERNVIRTADDR with
KERNLOADADDR/TRAMPLOADADDR and clean configs
the mi_startup (or to the last of it).. and
hit a panic after :
uart0: <16550 or compatible> on iodi0
Trap cause = 2 (TLB miss....)
I did have to take the pci bus OUT of the
build to get this far, hit a cache error with
the PCI code in. Interesting thing is the machine
reboots too ;-)
Yes, this puts things in the wrong place, doesn't compile and is
woefully incomplete. However, it will allow us to more easily track
against the upstream sources without needing to import the entire
Cavium tree under vendor.
This port is based on FreeBSD 7.0 as of April 2007 and the pre-import
MIPS tree (aka mips2), so much work is necessary here.
registers with ar71xx_bus_space_reversed. Note, that byte order
of values is handled by drivers. bus_spaces fixes only position
of register in word.
- Replace .hints hack for AR71XX UART with ar71xx_bus_space_reversed.
module; the ath module now brings in the hal support. Kernel
config files are almost backwards compatible; supplying
device ath_hal
gives you the same chip support that the binary hal did but you
must also include
options AH_SUPPORT_AR5416
to enable the extended format descriptors used by 11n parts.
It is now possible to control the chip support included in a
build by specifying exactly which chips are to be supported
in the config file; consult ath_hal(4) for information.
machine arm
device mem
device uart_ns8250
options GEOM_BSD
options GEOM_MBR
Remove the first three from all kernel configuration files
(sometimes commented-out) and change geom_bsd and geom_mbr
from standard to optional.
Note this includes changes to all drivers and moves some device firmware
loading to use firmware(9) and a separate module (e.g. ral). Also there
no longer are separate wlan_scan* modules; this functionality is now
bundled into the wlan module.
Supported by: Hobnob and Marvell
Reviewed by: many
Obtained from: Atheros (some bits)
mips32r2 and mips64r2 (and close relatives) processors. There
presently is support for ADMtek ADM5120, A mips 4Kc in a malta board,
the RB533 routerboard (based on IDT RC32434) and some preliminary
support for sibtye/broadcom designs. Other hardware support will be
forthcomcing.
This port boots multiuser under gxemul emulating the malta board and
also bootstraps on the hardware whose support is forthcoming...
Oleksandr Tymoshenko, Wojciech Koszek, Warner Losh, Olivier Houchard,
Randall Stewert and others that have contributed to the mips2 and/or
mips2-jnpr perforce branches. Juniper contirbuted a generic mips port
late in the life cycle of the misp2 branch. Warner Losh merged the
mips2 and Juniper code bases, and others list above have worked for
the past several months to get to multiuser.
In addition, the mips2 work owe a debt to the trail blazing efforts of
the original mips branch in perforce done by Juli Mallett.
