Without this the autotuning fails for small amounts of RAM (32mb),
which all the AR91xx shipping products seemed to have.
Thanks to gjb for reminding me to re-test this stuff.
Tested:
* AR91xx, TP-Link TL-WR1043nd v1
This is based on the AP135 design - QCA9558 SoC, 3x3 2GHz wifi, but no
5GHz (11n or 11ac) chip is available.
It however still has 128MiB of RAM, 16MiB of NOR flash and the AR8327N
gigabit switch - so it's quite a beefy router device.
Tested:
* Well, a unit, naturally
Obtained from: Completely messing up an amazon.com order and getting this instead, and asking "hey, wonder if I could.."
* add ipfw
* delete ath / ath_ahb for now, until I can have Warner beat me
with the clue stick about putting in conditional build things into
the ath Makefile so the module builds can just have the HAL bits
that are relevant for a particular target.
These are actually almost the same units; except one is 3x3 5GHz, and
one is 2x2 5GHz.
Tested:
* TP-Link TL-WDR3600
TODO:
* The ath0/ath1 MAC addresses are ye garbage (00:02:03:04:05:06); fixing
that will take a little more time. It works fine with the ath0/ath1
MAC addresses set manually.
* Go through and yank the AR9344 on-board switch config (arswitch1);
it's not required here for this AP.
The AR934x (and maybe others in this family) have a more complicated
GPIO mux. The AR71xx just has a single function register for a handful
of "GPIO or X" options, however the AR934x allows for one of roughly
100 behaviours for each GPIO pin.
So, this adds a quick hints based mechanism to configure the output
functions, which is required for some of the more interesting board
configurations. Specifically, some use external LNAs to improve
RX, and without the MUX/output configured right, the 2GHz RX side
will be plain terrible.
It doesn't yet configure the "input" side yet; I'll add that if
it's required.
Tested:
* TP-Link TL-WDR3600, testing 2GHz STA/AP modes, checking some
basic RX sensitivity things (ie, "can I see the AP on the other
side of the apartment that intentionally has poor signal reception
from where I am right now.")
Whilst here, fix a silly bug in the maxpin routine; I was missing
a break.
A lot of these embedded boards don't have a unique MAC address per
device stored somewhere unique - sometimes they'll have one MAC
for both arge NICs; someties they'll have one MAC for both arge NICs
/and/ the ath NICs. In these instances, we need to derive device
specific MAC addresses from the base MAC address.
These functions will be used by some follow-up code that'll slot
into if_arge and if_ath.
Otherwise, the initial media speed would change if a PHY is hooked up,
sending PHY speed notifications. For the AP135 at least, the RGMII
PHY has a static speed/duplex configured and if the PHY plumbing
attaches the PHY to the if_arge interface, the first link speed change
from 1000/full will set the MAC to something that isn't useful.
This shouldn't affect any other platforms - everything I looked at is
using hard-coded speed/duplex as static, as they're facing a switch
with no PHY attached.
* Force the arge0 interface to not use a PHY for speed negotiation
for now. It'd be nice to do it, but right now the RGMII interface
to the switch needs to stay at 1000/full in order to match what
the switch side of the port is programmed as.
So until that's all sorted out, disconnect arge0 from the PHY
and leave it at fixed at 1000/full.
I noticed this when I tried using a busted ethernet cable that
forced the PHY to negotiate 100/full. The switch was fine and
it negotiated to 100/full, but then arge0 saw the link update
and set the speed to 100/full when the switch side of that
hook up was set to 1000/full. Tsk.
* When using argemdio, the mdio device resets and initialises
the MAC, /not/ the arge_attach (or, as I discovered, arge_init.)
So arge1 wasn't being fully initialised and thus no traffic
would ever flow.
So until I tidy up that mess, just create an argemdio bus for
arge1. It's totally fine; it won't do anything or find anything
attached to it.
Tested:
* AP135 reference board - both arge0 and arge1 now work.
This is a QCA9558 SoC (2ghz 3x3) with an atheros 11ac PCIe 5GHz 3x3
NIC and an AR8327 gigabit ethernet switch.
TODO:
* The AR8327 gigabit switch support bugfixes are forthcoming.
* 11ac support and 11ac NIC support
This is enough to bring up the basic SoC support.
What works thus far:
* The mips74k core, pll setup, and UART (or else well, stuff would
be really difficult..)
* both USB 2.0 EHCI controllers
* on-board 2GHz 3x3 wifi (the other variant has 2GHz/5GHz wifi on-chip);
* arge0 - not yet sure why arge1 isn't firing off interrupts and thus
handling traffic, but I will soon figure it out and fix it here.
Tested:
* AP135 reference design, QCA9558 SoC, pretending to be an 11n
2GHz AP.
TODO:
* There's an interrupt mux hooking up devices to IP2 and IP3 - but it's
not a read-and-clear or write-to-clear register. So, trying to use it
naively like I have been ends up with massive interrupt storms.
For now the things that share those interrupts can just take them as
shared interrupts and try to play nice.
* There's two PCIe root complexes /and/ one of them can actually be
a PCIe device endpoint. Yes, you heard right. I have to teach the
AR724x PCIe bridge code to handle multiple instances with multiple
memory/irq regions, and then there'll be RC support, but EP support
isn't on my TODO list.
* I'm not sure why arge1 isn't up and running. I'll go figure that
out soon and fix it here.
Thankyou to Qualcomm Atheros for providing me with hardware and
an abundance of documentation about these things.
There's two EHCI controllers in the QCA955x SoCs - they have different
interrupts available via various demux registers, but they both tie to
IP3.
So for now, allow them to be sharable so they can hang off of IP3.
There's a lot more to come - the QCA955x has a bunch more GPIO MUX
configuration, reminiscent of what the ARM chips let you do - but
it'll have to come later.
This will override the resource allocation of simplebus, and also
merge the resource allocation code which was in xlp_pci.c.
With this change the SoC devices that does not have proper PCI
resources will be on the FDT simplebus. We can remove
sys/mips/nlm/dev/cfi_pci_xlp.c and sys/mips/nlm/dev/uart_pci_xlp.c
Handling some interrupts in XLP (like PCIe and SATA) involves writing to
vendor specific registers as part of interrupt acknowledgement.
This was earlier done with xlp_establish_intr(), but a better solution
is to provide a function xlp_set_bus_ack() that can be used with
cpu_establish_hardintr(). This will allow platform initialization code to
setup these ACKs without changing the standrard drivers.
Gather all the IRQ definitions to interrupt.h. Earlier these were in xlp.h
and pic.h. Update the definition of XLP_IRQ_IS_PICINTR to check for last
irq as well.
const. On x86, even after the machine context is supposedly read into
the struct ucontext, lazy FPU state save code might only mark the FPU
data as hardware-owned. Later, set_fpcontext() needs to fetch the
state from hardware, modifying the *mcp.
The set_mcontext(9) is called from sigreturn(2) and setcontext(2)
implementations and old create_thread(2) interface, which throw the
*mcp out after the set_mcontext() call.
Reported by: dim
Discussed with: jhb
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
