* Change mips24k -> mips74k for hwpmc, but leave it disabled for now.
* don't build pci by default.
* build pci and qca955x_pci for AP135, as theres a PCIe NIC.
* don't build a hwpmc module, it doesn't really work out well
for the mips boards at the moment.
* add ipfw and DEFAULT_TO_ACCEPT.
The carambola2 exposes all the gpio pins, but some are reserved for
core functions (eg usb, ethernet, etc.) Others are configured by default
to be available as normal GPIO pins to do interesting things with.
GPIO 18->23 is the I2S, SLIC and SPDIF device pins, but none of those
are currently used. So, just allow those to show up.
Tested:
* AR9344, Carambola 2
* (.. bitbang SPI to an Adafruit LCD via libgpio, because FreeBSD could
do with more shiny output devices that aren't network interfaces.)
TODO:
There are some other pins aren't currently included here, but should be.
The LED pins are for the internal switch inside the AR9344.
* GPIO 0+1 are "LED0 + LED1", but they're tied to high for bootstrapping.
* GPIO 13-17 are "LED2..7", but they're tied (H, L, L, L, H) for bootstrapping.
* GPIO 11 and 12 are UART RTS/CTS or I2S; but GPIO 12 is tied L for bootstrap.
The MAC addresses were totally wrong. They're like the DIR-625C1 - at
0x1ffe0004 and 0x1ffe0018. They're however stored as text strings.
The ath0 MAC address is also not set, even though the calibration
partition is valid.
So, pick the board address / first MAC as the ath0 MAC, and derive
arge0/arge1 from that. That way they're hopefully unique enough
for people with multiple devices.
Tested:
* DIR-655A1
TODO:
* Do the same for the DIR-625A1 and DIR-625C1.
This allows the TL-WDR3600 to use the correct MAC address for ath0, ath1
and arge0. arge1 isn't used; until I disable it entirely it'll just
show up with a randomly generated MAC.
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.
* 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.
This avoids universe trying to build MALTA_COMMON and fail due to
the problem addressed in r276773.
Include std.MALTA from the MALTA mipsel and MALTA64 mips64el config files,
where the machine lines exist.
The QCA955x has more mux interrupts going on - and the AR934x actually does,
but I cheated and assigned wlan and pcie to the same interrupt line.
They are, there's just a status register mux that I should've been using.
Luckily this isn't too bad a change in itself - almost all of the
Atheros MIPS configurations use a _BASE file to inherit from.
Except PB92, which I should really fix up at some point.
The AR934x will use the legacy apb for now until I write its replacement.
The QCA955x SoC I'm doing bring-up on will have a separate qca955x_apb.c
implementation that includes hooking into IP2/IP3 and doing further
interrupt demuxing as appropriate.
Special thanks to Nicholas Esborn for the loaner router to get this
target bootstrapped.
Review: D777
Reviewed by: adrian
Sponsored by: Nicholas Esborn <nick@desert.net>
commit 6d3c4c09226ad6bdd662e3e52489ef294a6ce298
Add terasic_mtl vt(4) framebuffer driver
terasic_mtl can be built with syscons(4) and vt(4) attachments, selected
at compile time.
commit 33240259b47a7c990a5a88a19f133a5600432a4c
Clear terasic_mtl text buffer on attach
commit d188c2d2412953f949624aa35cd07082830943c9
Update terasic vt(4) driver for FreeBSD r269783
commit d1cc54eee852fa4fc9d359d5bb2171d24ec73369
Safety belt to ensure vt(4) fb parameters are correct
commit 76e6d468ef45711d7952786095fc4791289ebb4b
Improve terasic_mtl_vt fdt parsing
- Use OF_getencprop to avoid need for explicit endian handling
(submitted by ray@freebsd.org)
- Check for expected length and correct pointer type
commit 3e2524b8995ab66e8a9295e4c87cbc7126eeddf4
Correct device_printf usage
commit 9e53e3c8e0766414e25662c95b09cc51c92443b0
Switch framebuffer to match host endianness
Xorg and xf86-video-scfb work much better with a native-endian
framebuffer.
commit 0f49259d596321ed85288ac0e1fb4ee1c966df48
Switch DE4 to vt(4) and enable kbdmux
commit 5bc96ebc89db7d134ad478335090c8477c1677c7
Add missing \n in device_printf calls
Submitted by: emaste
Sponsored by: DARPA, AFRL
have chosen different (and more traditional) stateless/statuful
NAT64 as translation mechanism. Last non-trivial commits to both
faith(4) and faithd(8) happened more than 12 years ago, so I assume
it is time to drop RFC3142 in FreeBSD.
No objections from: net@
configs. Switch the BERI_NETFPGA_MDROOT to 64bit by default.
Give we have working interrupts also cleanup the extra polling CFLAGS from
the module Makefile.
MFC after: 2 weeks
- Update FDT file for BERI DE4 boards.
- Add needed kernel configuration keywords.
- Rename module to saf1761otg so that the device unit number does not
interfere with the hardware ID in dmesg.
Sponsored by: DARPA, AFRL
