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.)
