Commit Graph

10 Commits (a8bae35914f12383ab60b43e8114bdba7fc355b9)

Author SHA1 Message Date
Christian Lamparter 2630aae36f ipq40xx: device-tree overhaul
- replace licence texts with SPDX-License-Identifier where
   applicable.

 - make node-names more generic to fit with Device-Tree Release v0.2
   Section 2.2.2 Generic Names Recommendation.

 - utilize wifi0/1, blsp1_uart1 labels

Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
2018-12-17 00:21:34 +01:00
John Crispin 95672e0433 ipq40xx: use patches that were sent upstream
Signed-off-by: John Crispin <john@phrozen.org>
2018-07-25 12:13:18 +02:00
John Crispin 1e48e56c50 ipq40xx: drop bus driver, its a no-op and only does lots of alloc/free
Signed-off-by: John Crispin <john@phrozen.org>
2018-07-24 10:50:13 +02:00
Christian Lamparter 4363b5362f ipq40xx: flesh out MR33's pcie dts definitions
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
2018-06-08 09:31:36 +02:00
Sven Eckelmann 856f0d5d0d ipq40xx: use upstream board-2.bin
The BDFs for all boards were upstreamed to the ath10k-firmware
repository and are now part of ath10k-firmware 2018-04-19.

Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com>
2018-04-23 22:07:22 +02:00
Sven Eckelmann c4c2a8f00c ipq40xx: Move reserved-memory DT to qcom-ipq4019.dtsi
The tz and smem reserved-memory information handled in the upstream Linux
sources by the SoC specific dtsi and not by the the boards dts. Using the
same approach in OpenWrt avoids unneccessary duplication.

Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com>
2018-04-20 20:58:52 +02:00
Sven Eckelmann 0d62432834 ipq40xx: Remove unused reserved-memory nodes
The reserved-memory regions are mostly undocumented by QCA and are named
very unspecific in the QSDK device trees. It was tried to clean them up by
commit 71ed9f10a3 ("ipq40xx: Use detailed reserved memory for A42") and
similar changes.

The features which require these regions were mostly unknown but
Senthilkumar N L <snlakshm@qti.qualcomm.com> and Sricharan Ramabadhran
<srichara@qti.qualcomm.com> provided some more insight in some of them:

* crash dump feature
  - a couple of regions used when 'qca,scm_restart_reason' dt node has the
    value 'dload_status' not set to 1
    + apps_bl <0x87000000 0x400000>
    + sbl <0x87400000 0x100000>
    + cnss_debug <0x87400000 0x100000>
    + cpu_context_dump <0x87b00000 0x080000>
  - required driver not available in Linux
  - safe to remove
* QSEE app execution
  - region tz_apps <0x87b80000 0x280000>
  - required driver not available in Linux
  - safe to remove
* communication with TZ/QSEE
  - region smem <0x87b80000 0x280000>
  - driver changes not yet upstreamed
  - must not be removed because any access can crash kernel/program
* trustzone (QSEE) private memory
  - region tz <0x87e80000 0x180000>
  - must not be removed because any access can crash kernel/program

Removing the unnecessary regions saves some kilobyte of reserved-memory and
cleans up the device tree:

* 2560 KiB
  - 8devices Jalapeno
  - AVM FRITZ!Box 4040
  - Compex WPJ428
  - Meraki MR33 Access Point
  - OpenMesh A42
* 14336 KiB
  - GL.iNet GL-B1300
  - Qualcomm Technologies, Inc. IPQ40xx/AP-DK01.1-C1

Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com>
2018-04-20 20:58:52 +02:00
Sven Eckelmann 1fcd625c0a ipq40xx: Remove phy reset gpio from Cisco Meraki MR33
There is currently no code to read the phy reset gpios for the ethernet
PHY. It would also have been better to use the more common name
"phy-reset-gpios" for this property.

Signed-off-by: Sven Eckelmann <sven@narfation.org>
2018-03-23 20:31:49 +01:00
Sven Eckelmann 9ca81646b9 ipq40xx: Use constant to set gpio active low/high
The GPIO configuration in the DTS have as third parameter the active
low/high configuration. This parameter is not easy to parse by humans when
it is only set to 0/1. It is better to use the predefined constants
GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW.

Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com>
2018-03-23 20:31:49 +01:00
Chris Blake 4943afd781 ipq40xx: add Cisco Meraki MR33 Support
This patch adds support for Cisco Meraki MR33

hardware highlights:

SOC:	IPQ4029 Quad-Core ARMv7 Processor rev 5 (v7l) Cortex-A7
DRAM:	256 MiB DDR3L-1600 @ 627 MHz Micron MT41K128M16JT-125IT
NAND:	128 MiB SLC NAND Spansion S34ML01G200TFV00 (106 MiB usable)
ETH:	Qualcomm Atheros AR8035 Gigabit PHY (1 x LAN/WAN) + PoE
WLAN1:	QCA9887 (168c:0050) PCIe 1x1:1 802.11abgn ac Dualband VHT80
WLAN2:	Qualcomm Atheros QCA4029 2.4GHz 802.11bgn 2:2x2
WLAN3:	Qualcomm Atheros QCA4029 5GHz 802.11a/n/ac 2:2x2 VHT80
LEDS:	1 x Programmable RGB+White Status LED (driven by Ti LP5562 on i2c-1)
	1 x Orange LED Fault Indicator (shared with LP5562)
	2 x LAN Activity / Speed LEDs (On the RJ45 Port)
BUTTON:	one Reset button
MISC:	Bluetooth LE Ti cc2650 PG2.3 4x4mm - BL_CONFIG at 0x0001FFD8
	AT24C64 8KiB EEPROM
	Kensington Lock

Serial:
	WARNING: The serial port needs a TTL/RS-232 3V3 level converter!
	The Serial setting is 115200-8-N-1. The board has a populated
	1x4 0.1" header with half-height/low profile pins.
	The pinout is: VCC (little white arrow), RX, TX, GND.

Flashing needs a serial adaptor, as well as patched ubootwrite utility
(needs Little-Endian support). And a modified u-boot (enabled Ethernet).
Meraki's original u-boot source can be found in:
<https://github.com/riptidewave93/meraki-uboot/tree/mr33-20170427>

Add images to do an installation via bootloader:
 0. open up the MR33 and connect the serial console.

 1. start the 2nd stage bootloader transfer from client pc:

  # ubootwrite.py --write=mr33-uboot.bin
  (The ubootwrite tool will interrupt the boot-process and hence
   it needs to listen for cues. If the connection is bad (due to
   the low-profile pins), the tool can fail multiple times and in
   weird ways. If you are not sure, just use a terminal program
   and see what the device is doing there.

 2. power on the MR33 (with ethernet + serial cables attached)
    Warning: Make sure you do this in a private LAN that has
    no connection to the internet.

 - let it upload the u-boot this can take 250-300 seconds -

 3. use a tftp client (in binary mode!) on your PC to upload the sysupgrade.bin
    (the u-boot is listening on 192.168.1.1)
    # tftp 192.168.1.1
    binary
    put openwrt-ipq40xx-meraki_mr33-squashfs-sysupgrade.bin

 4. wait for it to reboot

 5. connect to your MR33 via ssh on 192.168.1.1

For more detailed instructions, please take a look at the:
"Flashing Instructions for the MR33" PDF. This can be found
on the wiki: <https://openwrt.org/toh/meraki/mr33>
(A link to the mr33-uboot.bin + the modified ubootwrite is
also there)

Thanks to Jerome C. for sending an MR33 to Chris.

Signed-off-by: Chris Blake <chrisrblake93@gmail.com>
Signed-off-by: Mathias Kresin <dev@kresin.me>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
2018-03-14 19:04:52 +01:00