summaryrefslogtreecommitdiffstats
path: root/sys/mips
Commit message (Collapse)AuthorAgeFilesLines
* Move the 32-bit compatible procfs types from freebsd32.h to <sys/procfs.h>jhb2015-04-081-1/+3
| | | | | | | | | | | | | | | and export them to userland. - Define __HAVE_REG32 on platforms that define a reg32 structure and check for this in <sys/procfs.h> to control when to export prstatus32, etc. - Add prstatus32_t and prpsinfo32_t typedefs for the 32-bit structures. libbfd looks for these types, and having them fixes 'gcore' in gdb of a 32-bit process on a 64-bit platform. - Use the structure definitions from <sys/procfs.h> in gcore's elf32 core dump code instead of duplicating the definitions. Differential Revision: https://reviews.freebsd.org/D2142 Reviewed by: kib, nathanw (powerpc bits) MFC after: 1 week
* Convert the DIR-825C1 to use the new map based MAC address configuration.adrian2015-04-051-2/+26
| | | | | | Tested: * DIR-825C1
* Update the board MAC address configuration for the DIR-655A1.adrian2015-04-051-6/+32
| | | | | | | | | | | | | | | | | | | 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.
* Fix integer truncation bug in malloc(9)rstone2015-04-011-2/+2
| | | | | | | | | | | | | | | | | A couple of internal functions used by malloc(9) and uma truncated a size_t down to an int. This could cause any number of issues (e.g. indefinite sleeps, memory corruption) if any kernel subsystem tried to allocate 2GB or more through malloc. zfs would attempt such an allocation when run on a system with 2TB or more of RAM. Note to self: When this is MFCed, sparc64 needs the same fix. Differential revision: https://reviews.freebsd.org/D2106 Reviewed by: kib Reported by: Michael Fuckner <michael@fuckner.net> Tested by: Michael Fuckner <michael@fuckner.net> MFC after: 2 weeks
* Migrate the TL-WR1043nd v2 to use the new map based MAC hints mechanism.adrian2015-04-011-2/+19
| | | | | This programs separate, correct mac addresses for the ethernet and wlan interfaces.
* Add hints to set the board MAC address and derived values for each interface.adrian2015-03-281-3/+23
| | | | | | 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.
* Begin moving support for board MAC addresses over to being explicitly defined.adrian2015-03-284-49/+214
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A lot of these dinky atheros based MIPS boards don't have a nice, well, anything consistent defining their MAC addresses for things. The Atheros reference design boards will happily put MAC addresses into the wifi module calibration data like they should, and individual ethernet MAC addresses into the calibration area in flash. That makes my life easy - "hint.arge.X.eeprommac=<addr>" reads from that flash address to extract a MAC, and everything works fine. However, aside from some very well behaved vendors (eg the Carambola 2 board), everyone else does something odd. eg: * a MAC address in the environment (eg ubiquiti routerstation/RSPRO) that you derive arge0/arge1 MAC addresses from. * a MAC address in flash that you derive arge0/arge1 MAC addresses from. * The wifi devices having their own MAC addresses in calibration data, like normal. * The wifi devices having a fixed, default or garbage value for a MAC address in calibration data, and it has to be derived from the system MAC. So to support this complete nonsense of a situation, there needs to be a few hacks: * The "board" MAC address needs to be derived from somewhere and squirreled away. For now it's either redboot or a MAC address stored in calibration flash. * Then, a "map" set of hints to populate kenv with some MAC addresses that are derived/local, based on the board address. Each board has a totally different idea of what you do to derive things, so each map entry has an "offset" (+ve or -ve) that's added to the board MAC address. * Then if_arge (and later, if_ath) should check kenv for said hint and if it's found, use that rather than the EEPROM MAC address - which may be totally garbage and not actually work right. In order to do this, I've undone some of the custom redboot expecting hacks in if_arge and the stuff that magically adds one to the MAC address supplied by the board - instead, as I continue to test this out on more hardware, I'll update the hints file with a map explaining (a) where the board MAC should come from, and (b) what offsets to use for each device. The aim is to have all of the tplink, dlink and other random hardware we run on have valid MAC addresses at boot, so (a) people don't get random B:S:D:x:x:x ethernet MACs, and (b) the wifi MAC is valid so it works rather than trying to use an invalid address that actually upsets systems (think: multicast bit set in BSSID.) Tested: * TP-Link TL_WDR3600 - subsequent commits will add the hints map and the if_ath support. TODO: * Since this is -HEAD, and I'm all for debugging, there's a lot of printf()s in here. They'll eventually go under bootverbose. * I'd like to turn the macaddr routines into something available to all drivers - too many places hand-roll random MAC addresses and parser stuff. I'd rather it just be shared code. However, that'll require more formal review. * More boards.
* Remove the second MODULES_OVERRIDE; add if_vlan to the list.adrian2015-03-281-2/+1
|
* Add the MAC address hints for arge0/arge1 on the CARAMBOLA2.adrian2015-03-281-0/+2
| | | | Obtained from: Linux OpenWRT
* Set VM_KMEM_SIZE_SCALE=1 for the AR91xx SoCs.adrian2015-03-281-0/+3
| | | | | | | | | | | 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
* Add 64 byte linesize cache flushing routines for L1 instruction, L1 databr2015-03-264-11/+423
| | | | | | and L2 data caches. Sponsored by: HEIF5
* Remove duplicate AH_DEBUG_ALQ option.gjb2015-03-261-1/+0
| | | | Sponsored by: The FreeBSD Foundation
* Add initial D-Link DIR-655 (A1) support.adrian2015-03-222-0/+209
| | | | | | | | | | | | | | 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.."
* re-enable building modules for the AR933xadrian2015-03-211-1/+3
| | | | | | | | * 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.
* Fix the LED configuration so the switch PHY LEDs work fine.adrian2015-03-211-3/+3
| | | | | | | | Tested: * TP-Link TL-WDR3600; yes, by testing all five ethernet ports. Obtained from: Linux OpenWRT
* Migrate these configs to use the geom map search function.adrian2015-03-213-11/+11
| | | | | Now that the search function reliably works, this allows for smaller images.
* Add support for the TP-Link TL-WDR4300 and TL-WDR3600.adrian2015-03-212-0/+258
| | | | | | | | | | | | | | | | | | 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.
* Re-enable the modules for now; I'm using them in some other test builds.adrian2015-03-211-2/+2
|
* Now that the switch PHY fully works, don't limit arge0 to only being upadrian2015-03-211-1/+1
| | | | | | if the WAN port is up. This way I can use it for arbitrary ports/vlans.
* Add GPIO function mux configuration for AR934x SoCs.adrian2015-03-211-0/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* add QCA955x PCIe configuration registers.adrian2015-03-211-0/+10
| | | | | These are /not/ absolute addresses, as the QCA955x SoC has 2 PCIe RC's (and 1 PCIe EP.)
* Note that the AR724x PCIe registers are actually from the PCI_CTRLadrian2015-03-211-1/+1
| | | | register range.
* Correct the ixgbe entries in mips and powerpc, and add the modulejfv2015-03-181-1/+2
| | | | entries in i386/amd64 in the Makefile
* Use ar71xx_mac_addr_random_init() instead of a hand-rolled randomadrian2015-03-151-9/+2
| | | | MAC address.
* Start fleshing out some MAC address helper functions.adrian2015-03-153-0/+146
| | | | | | | | | | | 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.
* Use sbuf_printf() for sysctl strings instead of static buffers and snprintf.ian2015-03-142-24/+16
|
* Use SYSCTL_OUT_STR() to return strings.ian2015-03-141-1/+1
| | | | PR: 195668
* Compile some modules - I'm going to eventually just compile all theadrian2015-03-141-1/+1
| | | | | | | modules, but these are a subset of things that are worth playing with in deployed APs. (ipfw in particular is rather nice.)
* Add board support for the TP-Link TL-WR1043nd v2.adrian2015-03-142-0/+200
| | | | | | | This is a QCA9558 based design with on-chip 2GHz 3x3 11n wifi, AR8327N switch, 64MB RAM and 8MB flash. Of course, it runs FreeBSD.
* Now that if_arge.c handles actual 'locked' media settings, enableadrian2015-03-081-1/+5
| | | | the WAN port to look like it has its own PHY on PHY4 (port5).
* Modify the if_arge code to use a /fixed/ media mode when it's configured.adrian2015-03-081-6/+38
| | | | | | | | | | | | 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.
* Add ethernet MAC DDR flush hookups for QCA955x.adrian2015-03-041-4/+5
| | | | | | Tested: * AP135
* Add DDR flush registers for QCA955x.adrian2015-03-041-0/+7
|
* Fix both arge0 and arge1 to work correctly on the AP135.adrian2015-03-041-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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.
* Add support for the AP135 2.0 reference platform.adrian2015-03-022-0/+226
| | | | | | | | | | 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
* Bring over the initial QCA955x SoC support framework.adrian2015-03-022-0/+226
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* [QCA955x] make the USB EHCI interrupts shareable.adrian2015-03-021-1/+1
| | | | | | | | 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.
* Add initial QCA955x support to if_arge.c.adrian2015-03-021-1/+21
| | | | | | Tested: * AP135 development board, QCA9558 SoC.
* Add a MII mode for SGMII.adrian2015-03-021-0/+1
| | | | | | This appears on the AR934x and later chips, although it's not something that's programmed via the arge0/arge1 register space. It's just cosmetic.
* Add very initial QCA955x awareness to the GPIO code.adrian2015-03-011-3/+11
| | | | | | 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.
* Flesh out some more QCA955x ethernet PLL setup.adrian2015-03-011-28/+10
|
* Add Ethernet PLL values for the QCA955x.adrian2015-03-011-0/+5
| | | | | | These are the same as the AR934x. Obtained from: Linux openwrt
* Make QCA955X_GMAC_REG_ETH_CFG defined like most other registers like this.adrian2015-03-011-1/+1
|
* Add QCA955x support to the EHCI setup path.adrian2015-03-011-0/+4
| | | | | | Tested: * QCA AP135 development board, USB rootfs.
* Whitespace fixes for sys/mips/nlm/devjchandra2015-02-2816-131/+121
| | | | | Clean up whitespace issues under sys/mips/nlm/dev. No functional change in this commit.
* Whitespace fixes for files in sys/mips/nlmjchandra2015-02-2831-190/+191
| | | | | Clean up whitespace issues under sys/mips/nlm (except dev). No functional change in this commit.
* Add subclass of simplebus for Broadcom XLPjchandra2015-02-275-443/+363
| | | | | | | | | 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
* Move PCI bus below simplebus for Broadcom XLPjchandra2015-02-271-12/+10
| | | | | This will enable us to do common allocation code for memory and interrupts for SoC devices as well as PCI devices.
* Improve additional interrupt ACK for Broadcom XLPjchandra2015-02-273-33/+35
| | | | | | | | | | 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.
* Remove run-time allocation of XLP IRQsjchandra2015-02-264-138/+118
| | | | | Follow the same static IRQ to Interrupt Table Entry mapping as the other OS supported on XLP.
OpenPOWER on IntegriCloud