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>
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>
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>
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>
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>
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>
