There's plenty of hints that I haven't yet fleshed out and are hardcoded
in arswitch_8327.c. They're listed here (from OpenWRT) for completeness.
This is enough to get the thing up, running and pinging.
Note that the mdiobus for the on-switch switch changes - the AR8327
probes first, which exposes mdio1, and thus the arge1 mdiobus will probe
and attach as mdio2. That is what the AR9344 on-chip switch has to
attach to.
Tested:
* Qualcomm Atheros DB120
The on-board NIC is an 3x3 AR9380 with 5GHz only.
* enable pci code in AR9344_BASE
* enable ath_pci and the firmware loading bits in DB120
* add in the relevant hints in DB120.hints to inform the probe/attach
code where the PCIe fixup data is for the onboard chip.
This is only relevant for a default development board. I also have a
DB120 with the on-board PCIe wifi NIC disabled and it's exposed as
a real PCIe slot (to put normal PCIe NICs in); the fixup code will need
to be disabled to make this work correctly.
Tested:
* DB120
The uboot mapping is only 128KiB (0x20000) and not 2MiB (0x200000).
Dynamically adjust kernel and rootfs mappings based on the
geom_uncompress(4) magic.
This makes the built images more reliable by accepting changes on kernel
size transparently and matches the images built with zrouter and
freebsd-wifi-build.
Tested by: gjb
Approved by: adrian (mentor)
Obtained from: Zrouter
board.
This is another AR9331 board similar to the Carambola2. It has different
ethernet and LED wiring though.
They make a variety of boards that mostly differ on the amount of RAM/flash
available. Alfa Networks graciously donated a handful of 64MB RAM/16MB flash
boards so I can finish off 802.11s support for the AR93xx chips and do up
a tech demonstration with it.
This is enough to bring up the board.
Tested:
* Alfa networks UB Hornet board - 64MB ram, 16MB flash version.
Thankyou to Alfa Networks for the development boards!
Sponsored by: Alfa Networks (hardware only)
Switch the majority of device configuration to FDT from hints.
Add BERI_*_BASE configs to reduce duplication in the MDROOT and SDROOT
kernels.
Add NFS and GSSAPI support by default.
MFC after: 3 days
Sponsored by: DARPA/AFRL
the cfi(4) driver. It remained in the tree longer than would be ideal
due to the time required to bring cfi(4) to feature parity.
Sponsored by: DARPA/AFRL
MFC after: 3 days
we can now add all the hardware bits for the DB120.
* arge0/argemdio0 is hooked up to an AR8327 switch - which there's currently
no support for. However, the bootloader on this board does set it up as
a basic switch so we can at least _use_ it ourselves.
So we should at least configure the arge0 side of things, including the GMAC
register.
* .. the GMAC config peels off arge0 from the internal switch and exposes it
as an RGMII to said AR8327.
* arge1/argemdio1 are hooked up to an internal 10/100 switch. So, that also
needs configuring.
* Add support for the NOR flash layout.
* Add support for the wifi (which works, with bugs, but it works.)
What's missing!
* No GPIO stuff yet!
* No sound (I2S) and no NAND flash support yet, sorry!
* The normal DB120 has an external AR95xx wifi chip on PCIe but with the
actual calibration data in the NOR flash. My DB120 has been modified
to let me use the PCIe slot as a normal PCIe slot. I'll add the "default"
settings later when I have access to a non-modified one.
* Other stuff, like why the wifi unit gets upset and spits out stuck beacons
and interrupt storms everywhere. Sigh.
Tested:
* DB120 board - AR9344 (mips74k SoC) booting off of SPI flash into multi-user
mode.
wireless home router.
Notable things:
2x 16 MB flash devices
Atheros Wireless
Atheros Switching
Many thanks to adrian@ for his guidance on this and keeping the drivers in
the base system up to date
Approved by: re (delphij)
This is a nice small outdoor/indoor AP from Ubiquity Networks.
The device has:
AR7241 CPU SoC
AR9287 Wifi
8MB flash
32MB RAM
wifi has been tested to work along with leds.
Submitted by: loos
Approved by: sbruno (mentor, implicit)
Tested by: hiren
form xx:xx:xx:xx:xx:xx complete with ":" characters taking of 18 bytes
instead of 6 integers. Expose a "readascii" tuneable to handle this case.
Remove restriction on eepromac assignement for the first dev instance only.
Add eepromac address for DIR-825 to hints file.
Add readascii hint for DIR-825
Reviewed by: adrian@
* Make Yarrow an optional kernel component -- enabled by "YARROW_RNG" option.
The files sha2.c, hash.c, randomdev_soft.c and yarrow.c comprise yarrow.
* random(4) device doesn't really depend on rijndael-*. Yarrow, however, does.
* Add random_adaptors.[ch] which is basically a store of random_adaptor's.
random_adaptor is basically an adapter that plugs in to random(4).
random_adaptor can only be plugged in to random(4) very early in bootup.
Unplugging random_adaptor from random(4) is not supported, and is probably a
bad idea anyway, due to potential loss of entropy pools.
We currently have 3 random_adaptors:
+ yarrow
+ rdrand (ivy.c)
+ nehemeiah
* Remove platform dependent logic from probe.c, and move it into
corresponding registration routines of each random_adaptor provider.
probe.c doesn't do anything other than picking a specific random_adaptor
from a list of registered ones.
* If the kernel doesn't have any random_adaptor adapters present then the
creation of /dev/random is postponed until next random_adaptor is kldload'ed.
* Fix randomdev_soft.c to refer to its own random_adaptor, instead of a
system wide one.
Submitted by: arthurmesh@gmail.com, obrien
Obtained from: Juniper Networks
Reviewed by: obrien
DB120 development board.
The AR934x SoCs are a MIPS74k based system with increased RAM addressing
space, some scratch-pad RAM, an improved gige switch PHY and 2x2 or 3x3
on-board dual-band wifi.
This support isn't complete by any stretch; it's just enough to bring
the board up for others to tinker with. Notably, the MIPS74k support
is broken. However it boots enough to echo some basic probe/attach
messages, before dying somewhere in the TLB code.
Thankyou to Qualcomm Atheros for their continued support of me doing
open source work with their hardware.
Tested:
* AR9344, mips74k
This is an AR7240 based device with an AR9285 on-board.
I've tested the initial boot and wifi support; however at the moment
the ethernet switch driver doesn't seem to be picking up carrier on the
active ethernet port. Basic flood pinging works however, so I think
we're on the right track.
Thank you to Adrian Woodley <adrian@diskworld.com.au> for purchasing me
one of these devices to bootstrap FreeBSD-HEAD on.
This is based on the AR933x (Hornet) SoC from Qualcomm Atheros.
It's a much nicer board to do development on - 64MB RAM, 16MB flash.
The development board breaks out the GPIO pins, ethernet, serial (via
a USB<->RS232 chip), USB host and of course a small wifi antenna.
Everything but the wifi works thus far.
Until an ADM6996 driver shows up, this allows for the two switch
ports to be used.
Submitted by: Luiz Otavio O Souza <loos.br@gmail.com>
Reviewed by: ray
* arge0 is MII
* arge1 is GMII
* the MDIO bus is on arge1, not arge0
* the default switch config is to have ports 0-3 as the switch group,
with port 4 being an external PHY dedicated to arge0 (ie, 'cpu' port.)
Whilst I'm here, remove unused bits and pieces from the config.
Tested:
* AP121, ping on both arge0 and arge1
* Tested switch port detection using etherswitchcfg
This implements the bus transmit/receive/sigchg/ipend methods with
a polled interrupt handler (ipend) rather than enabling hardware
interrupts.
The FIFO is faked at 16 bytes deep for now, just so the transmit
IO side doesn't suck too bad (the callout frequency limits how quickly
IO is flushed to the sender, rather than scheduling the callout more
frequently whilst there's active TX. But I digress.)
Tested:
* Atheros AP121 (AR9330) reference board, booting to multi-user interactive
mode.
most kernels before FreeBSD 9.0. Remove such modules and respective kernel
options: atadisk, ataraid, atapicd, atapifd, atapist, atapicam. Remove the
atacontrol utility and some man pages. Remove useless now options ATA_CAM.
No objections: current@, stable@
MFC after: never
reducing the number of runtime checks done by the SDK code.
o) Group board/CPU information at early startup by subject matter, so that e.g.
CPU information is adjacent to CPU information and board information is
adjacent to board information.
* add cam as a module to build - but build in scbus/da for now, as
"cam" as a module includes all cam devices. Hardly space saving.
* Don't build FFS snapshot support.
This has an AR7240 SoC with an AR9285 wireless NIC on-board.
Since the kernel partition on the 4MiB flash is 960KiB, quite a bit
is disabled to try and squeeze the build into that. Even lzma'ed,
it's still quite large.
802.11n router.
The flash layout defaults to a 1 MiB section for the kernel so I'm trying
very hard to squeeze a minimialistic (LZMA compressde) kernel image into
that.
I've verified that it boots through to single user mode fine.
Issues:
* USB doesn't yet work as a module - I need to add something else to the
USB AR71xx build before that will work.
* There's no switch PHY support - but for now it quite happily behaves
as a useful dumb switch out of the box. Phew.
* Since a previous flash attempt trashed my radio configuration block,
I haven't yet verified whether the wireless works correctly.
I'll test that out shortly (read: once I re-calibrate the board somehow.)
Thanks to ray@ and the zrouter project for doing some of the initial
hard work in figuring out how to bring this board up.
Terasic DE-4 board. Allow LED configuration to be set using loader
tunables, not just from userspace, and preconfigure LED 8 as a kernel
heartbeat. For now, this is a Nexus-attached, BERI-only driver, but it
could be used with other hard and soft cores on Altera FPGAs as well, in
principle.
Sponsored by: DARPA, AFRL
used with Terasic's DE-4 and other similar FPGA boards. This display
is 800x480 and includes a capacitive touch screen, multi-touch
gesture recognition, etc. This device driver depends on a Cambridge-
provided IP core that allows the MTL device to be hooked up to the
Altera Avalon SoC bus, and also provides a VGA-like text frame buffer.
Although it is compiled as a single device driver, it actually
implements a number of different device nodes exporting various
aspects of this multi-function device to userspace:
- Simple memory-mapped driver for the MTL 24-bit pixel frame buffer.
- Simple memory-mapped driver for the MTL control register set.
- Simple memory-mapped driver for the MTL text frame buffer.
- syscons attachment for the MTL text frame buffer.
This driver attaches directly to Nexus as is common for SoC device
drivers, and for the time being is considered BERI-specific, although
in principle it might be used with other hard and soft cores on
Altera FPGAs.
Control registers, including touchscreen input, are simply memory
mapped; in the future it would be desirable to hook up a more
conventional device node that can stream events, support kqueue(2)/
poll(2)/select(2), etc.
This is the first use of syscons on MIPS, as far as I can tell, and
there are some loose ends, such as an inability to use the hardware
cursor. More fundamentally, it appears that syscons(4) assumes that
either a host is PC-like (i386, amd64) *or* it must be using a
graphical frame buffer. While the MTL supports a graphical frame
buffer, using the text frame buffer is preferable for console use.
Fixing this issue in syscons(4) requires non-trivial changes, as the
text frame buffer support assumes that direct memory access can be
done to the text frame buffer without using bus accessor methods,
which is not the case on MIPS. As a workaround for this, we instead
double-buffer and pretend to be a graphical frame buffer exposing
text accessor methods, leading to some quirks in syscons behaviour.
Sponsored by: DARPA, AFRL
The driver attempts to support all documented parts, but has only been
tested with the 512Mbit part on the Terasic DE4 FPGA board. It should be
trivial to adapt the driver's attach routine to other embedded boards
using with any parts in the family.
Also import isfctl(8) which can be used to erase sections of the flash.
Sponsored by: DARPA, AFRL
The configuration is:
* RGMII, both ports
* arge0 - connected to PHY4 as a dedicated port (CPU port)
* arge1 - connected to the switch ports
I've verified this on my routerstation pro board.
* Add the i2c bitbang bus;
* Add the etherswitch/rtl8366rb drivers;
* "fix" the USB GPIO configuration so USB actually works.
Submitted by: Stefan Bethke <stb@lassitu.de>
The AP93 has:
* AR7240 - mips24k processor with integrated 10/100 switch and
various other peripherals;
* AR9283 - 2x2 2.4GHz 802.11n (with calibration data in flash);
* 64MB RAM;
* 16MB SPI flash.
The switch code detects as an AR8216 at the present moment, which isn't
_entirely_ strictly true. However, the MII/MDIO routing in AP93.hints
works - the arge0 MAC connects to PHY4 in the switch, but via the
switch internal MDIO bus. The switch connects to arge0's MDIO bus,
but only to export the switch registers.
Thanks to stb and ray for the switch work, and ray for helping determine
what the correct switch hints should be for this thing.
some of the IPI mechanisms used by the common MIPS SMP code so we could use
the multicast IPI facilities, on GXemul as well as on several real hardware
platforms, and the ability to have multiple hard IPI types.
entirely of one machdep file lifted from the MALTA port, as well as
a low-level console and tty driver for the gxemul debugging console
device (the emulators stdio). As with many low-level embedded and
hypervisor console devices, it is polled only, so we drive TTY I/O
from a callout; we are perhaps a bit too aware of the MIPS physical
maps in order to attach the console before newbus comes to life.
The sample kernel configuration depends on an MD-based root file
system, which is not provided. However, any 64-bit, big-endian
userspace image (such as one generated for MALTA) should work.
This will hopefully be supplemented by additional device drivers for
gxemul-specific hardware simulations from Juli Mallett. We have
found oldtestmips quite useful for testing and improving aspects of
the MIPS port, so it's worth supporting better in FreeBSD.
Requested by: theraven, jmallett
Sponsored by: DARPA, AFRL
MFC after: 3 weeks
arge1 still works (it's the standalone PHY) but arge0 and the other switch
ports don't work. They're enumerated though, demonstrating that the
mdiobus abstraction is correctly working.
* arge0 doesn't (yet) work via the switch PHY ports; I'm not sure why.
* arge1 maps to the WAN port. That works.
TODO:
* The PLL register needs a different (non-default) value for Gigabit
Ethernet. The board setup code needs to be extended a bit to allow
for non-default pll_1000 values - right now, those values come out
of hard-coded values in the per-chip set_pll_ge() routines.
Obtained from: Linux / OpenWRT
This uses the new firmware(9) method for squirreling away the EEPROM
contents from SPI flash so ath(4) can get to them later.
It won't work out of the box just yet - you have to add this to
if_ath_pci.c:
#define ATH_EEPROM_FIRMWARE
.. until I've added it as a configuration option and updated things.
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.
The on-chip SD slots do not have PCI BARs corresponding to them, so
this has to be handled in the custom SoC memory allocation.
Provide memory resource for rids corresponding to BAR 0 and 1 in
the custom allocation code.
Features:
- network driver for the four 10G interfaces and two management ports
on XLP 8xx.
- Support 4xx and 3xx variants of the processor.
- Source code and firmware building for the 16 mips32r2 micro-code engines
in the Network Accelerator.
- Basic initialization code for Packet ordering Engine.
Submitted by: Prabhath Raman (prabhath at netlogicmicro com)
[refactored and fixed up for style by jchandra]
Support for the Security and RSA blocks on XLP SoC. Even though
the XLP supports many more algorithms, only the ones supported
in OCF have been added.
Submitted by: Venkatesh J. V. (venkatesh at netlogicmicro com)
As of FreeBSD 8, this driver should not be used. Applications that use
posix_openpt(2) and openpty(3) use the pts(4) that is built into the
kernel unconditionally. If it turns out high profile depend on the
pty(4) module anyway, I'd rather get those fixed. So please report any
issues to me.
The pty(4) module is still available as a kernel module of course, so a
simple `kldload pty' can be used to run old-style pseudo-terminals.
required for the ABI the kernel is being built for.
XXX This is implemented in a kind-of nasty way that involves including source
files, but it's still an improvement.
o) Retire ISA_* options since they're unused and were always wrong.
* enable ALQ and net80211/ath ALQ logging by default, to make it possible
to get debug register traces.
* Update some comments
* Enable HWPMC for testing.
bootable image.
The kernel has to fit inside an 896KiB area in a 4MB SPI flash.
So a bunch of stuff can't be included (and more is to come), including
(unfortunately) IPv6.
TODO:
* GPIO modules need to be created
* Shrink the image a bit more by removing some of the CAM layer debugging
strings.
platforms.
This will make every attempt to mount a non-mpsafe filesystem to the
kernel forbidden, unless it is expressely compiled with
VFS_ALLOW_NONMPSAFE option.
This patch is part of the effort of killing non-MPSAFE filesystems
from the tree.
No MFC is expected for this patch.
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)
