d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
8e01fdea2b
freebsd-dev/sys/mips/conf/AP135.hints

175 lines
4.8 KiB
Plaintext
Raw Normal View History

Add support for the AP135 2.0 reference platform. 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
2015-03-02 02:27:25 +00:00
# This is a placeholder until the hardware support is complete.
# I'm assuming this is an AP135-020. The AP136-010 in openwrt has
# the ethernet ports wired up to the switch in the reverse way.
# $FreeBSD$
# QCA955X_ETH_CFG_RGMII_EN (1 << 0)
hint.qca955x_gmac.0.gmac_cfg=0x1
# mdiobus0 on arge0
hint.argemdio.0.at="nexus0"
hint.argemdio.0.maddr=0x19000000
hint.argemdio.0.msize=0x1000
hint.argemdio.0.order=0
Fix both arge0 and arge1 to work correctly on the AP135. * 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.
2015-03-04 03:48:11 +00:00
# mdiobus1 on arge1 - required to bring up arge1?
hint.argemdio.1.at="nexus0"
hint.argemdio.1.maddr=0x1a000000
hint.argemdio.1.msize=0x1000
hint.argemdio.1.order=0
Add support for the AP135 2.0 reference platform. 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
2015-03-02 02:27:25 +00:00
# AR8327 - connected via mdiobus0 on arge0
hint.arswitch.0.at="mdio0"
hint.arswitch.0.is_7240=0 # definitely not the internal switch!
hint.arswitch.0.is_9340=0 # not the internal switch!
hint.arswitch.0.numphys=5 # all ports are PHYs
hint.arswitch.0.phy4cpu=0
hint.arswitch.0.is_rgmii=0 # not needed
hint.arswitch.0.is_gmii=0 # not needed
# This is where it gets a bit odd. port 0 and port 6 are CPU ports.
# The current code only supports one CPU port. So hm, what should
# we do to hook PAD6 up to be RGMII but a PHY, not a MAC?
# The other trick - how do we get arge1 (hooked up to GMAC0) to work?
# That's currently supposed to be hooked up to CPU port 0.
# Other AR8327 configuration parameters
# AP136-020 parameters
# GMAC0 AR8327 -> GMAC1 (arge1) SoC, SGMII
# AR8327_PAD_MAC_SGMII
hint.arswitch.0.pad.0.mode=3
#hint.arswitch.0.pad.0.rxclk_delay_sel=0
hint.arswitch.0.pad.0.sgmii_delay_en=1
# GMAC6 AR8327 -> GMAC0 (arge0) SoC, RGMII
# AR8327_PAD_MAC_RGMII
# XXX I think this hooks it up to the internal MAC6
hint.arswitch.0.pad.6.mode=6
hint.arswitch.0.pad.6.txclk_delay_en=1
hint.arswitch.0.pad.6.rxclk_delay_en=1
# AR8327_CLK_DELAY_SEL1
hint.arswitch.0.pad.6.txclk_delay_sel=1
# AR8327_CLK_DELAY_SEL2
hint.arswitch.0.pad.6.rxclk_delay_sel=2
# XXX there's no LED management just yet!
hint.arswitch.0.led.ctrl0=0x00000000
hint.arswitch.0.led.ctrl1=0xc737c737
hint.arswitch.0.led.ctrl2=0x00000000
hint.arswitch.0.led.ctrl3=0x00c30c00
hint.arswitch.0.led.open_drain=1
# force_link=1 is required for the rest of the parameters
# to be configured.
hint.arswitch.0.port.0.force_link=1
hint.arswitch.0.port.0.speed=1000
hint.arswitch.0.port.0.duplex=1
hint.arswitch.0.port.0.txpause=1
hint.arswitch.0.port.0.rxpause=1
# force_link=1 is required for the rest of the parameters
# to be configured.
hint.arswitch.0.port.6.force_link=1
hint.arswitch.0.port.6.speed=1000
hint.arswitch.0.port.6.duplex=1
hint.arswitch.0.port.6.txpause=1
hint.arswitch.0.port.6.rxpause=1
# arge0 - hooked up to AR8327 GMAC6, RGMII
Fix both arge0 and arge1 to work correctly on the AP135. * 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.
2015-03-04 03:48:11 +00:00
hint.arge.0.phymask=0x0
Add support for the AP135 2.0 reference platform. 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
2015-03-02 02:27:25 +00:00
hint.arge.0.miimode=3 # RGMII
Fix both arge0 and arge1 to work correctly on the AP135. * 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.
2015-03-04 03:48:11 +00:00
hint.arge.0.media=1000
hint.arge.0.fduplex=1
Add support for the AP135 2.0 reference platform. 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
2015-03-02 02:27:25 +00:00
hint.arge.0.pll_1000=0x56000000
# MAC for arge0 is the first 6 bytes of the ART
hint.arge.0.eeprommac=0x1fff0000
# arge1 - lock up to 1000/full
hint.arge.1.phymask=0x0
hint.arge.1.media=1000
hint.arge.1.fduplex=1
hint.arge.1.miimode=5 # SGMII
hint.arge.1.pll_1000=0x03000101
# MAC for arge1 is the second 6 bytes of the ART
hint.arge.1.eeprommac=0x1fff0006
# ath0: Where the ART is - last 64k in the flash
hint.ath.0.eepromaddr=0x1fff0000
hint.ath.0.eepromsize=16384
# ath1: it's different; it's a PCIe attached device, so
# we instead need to teach the PCIe bridge code about it
# (ie, the 'early pci fixup' stuff that programs the PCIe
# host registers on the NIC) and then we teach ath where
# to find it.
# ath1 hint - pcie slot 0
hint.pcib.0.bus.0.0.0.ath_fixup_addr=0x1fff4000
hint.pcib.0.bus.0.0.0.ath_fixup_size=16384
# ath0 - eeprom comes from here
hint.ath.1.eeprom_firmware="pcib.0.bus.0.0.0.eeprom_firmware"
# flash layout:
#
# bootargs=console=ttyS0,115200 root=31:02 rootfstype=jffs2 init=/sbin/init mtdparts=ath-nor0:256k(u-boot),64k(u-boot-env),6336k(rootfs),1408k(uImage),8256k(mib0),64k(ART)
# 256KiB u-boot
hint.map.0.at="flash/spi0"
hint.map.0.start=0x00000000
hint.map.0.end=0x00040000 # 256k u-boot
hint.map.0.name="u-boot"
hint.map.0.readonly=1
# 64KiB u-boot-env
hint.map.1.at="flash/spi0"
hint.map.1.start=0x00040000
hint.map.1.end=0x00050000 # 64k u-boot-env
hint.map.1.name="u-boot-env"
hint.map.1.readonly=1
# 6336KiB rootfs
hint.map.2.at="flash/spi0"
hint.map.2.start=0x00050000
hint.map.2.end=0x00680000 # 6336k rootfs
hint.map.2.name="rootfs"
hint.map.2.readonly=1
# 1344KiB uImage
hint.map.3.at="flash/spi0"
hint.map.3.start=0x00680000
hint.map.3.end=0x007d0000 # 1408k uImage, 64k off the end..
hint.map.3.name="uImage"
hint.map.3.readonly=1
# 64KiB cfg
hint.map.4.at="flash/spi0"
hint.map.4.start=0x007d0000
hint.map.4.end=0x007e0000
hint.map.4.name="cfg"
hint.map.4.readonly=0
# 8256 KiB mib0
hint.map.5.at="flash/spi0"
hint.map.5.start=0x007e0000
hint.map.5.end=0x00ff0000 # 64k mib0
hint.map.5.name="mib0"
hint.map.5.readonly=1
# 64KiB ART
hint.map.6.at="flash/spi0"
hint.map.6.start=0x007f0000
hint.map.6.end=0x01000000 # 64k ART
hint.map.6.name="ART"
hint.map.6.readonly=1
Reference in New Issue Copy Permalink