Add a device tree for JCG JHR-N805R
This router is based on a RT3050 and has 4MB of SPI flash and 16MB of
SDRAM. For details, see https://wikidevi.com/wiki/JCG_JHR-N805R .
Signed-off-by: Reinhard Max <reinhard@m4x.de>
Reviewed-by: Torsten Duwe <duwe@lst.de>
SVN-Revision: 48902
Commit d0f5ab6d95a1 ("ramips: Added support for ZBT-826 / ZBT-1026")
incorrectly changed the mode of the ramips shell scripts from 755 to 644.
I.e., they are not excutable any more and for example devices will be left
with broken configs.
Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com>
SVN-Revision: 48893
Hi,
the board in subject (RT5350F-OLinuXino-EVB) still ships from vendor
with a RC3 image built upon a .dts file which declares GPIO12 and GPIO14
as relay2 and relay1 respectively, as you can see from their rt5350f
branch on GitHub.
For some reason in the official stable build both the GPIOs are swapped
and the wrong names are declared in the gpio-export directive.
I'm submitting this patch which should roll back the wrong changes, so
that we get backward compatibility with any script developed on RC3
which controls the relays.
After patching correct operation is restored:
root@OpenWrt:/# cat /sys/kernel/debug/gpio
GPIOs 0-21, platform/10000600.gpio, 10000600.gpio:
gpio-0 (button ) in hi
gpio-12 (relay2 ) out lo
gpio-14 (relay1 ) out lo
Thank you,
Signed-off-by: Lorenzo Cafaro <lorenzo@ibisco.net>
SVN-Revision: 48796
As indicated in the bug tracker[1], failsafe mode is broken on at least some
devices using the mt7620 switch (and possibly mt7621). The thread explicitly
mentions the Xiaomi MiWifi, and the Nexx WT3020, and an unspecified device
using the mt7621 switch; the issue also applies to the Netgear EX2700.
The problem is that failsafe mode uses eth0, but enable_vlan is always set to 1
by the switch driver. Connecting to and/or pinging the device fails. This patch
fixes the failsafe preinit config, by making sure that vlan support is disabled.
It currently only fixes the switch config on mt7620, but might apply to the
mt7621 as well, so the patch has been designed with this in mind.
A similar (line wrapped) patch was submitted in December by Simon Peter, but never
accepted and/or discussed.
This patch applies to both Chaos Calmer and trunk.
[1] https://dev.openwrt.org/ticket/18768
Signed-off-by: Joseph C. Lehner <joseph.c.lehner@gmail.com>
SVN-Revision: 48772
This patch adds support for building factory and sysupgrade images
for the Netgear EX2700 that don't require modification of u-boot
environment variables.
The bootloader on this device expects the kernel partition to end
on a 64k block boundary. The last 64 byte of the kernel partition
must contain a valid uImage header - in the stock firmware, this is
the uImage header of the root filesystem. For this patch, we're using
the uImage header of a 0 byte partition (ex2700-fakeroot.uImage).
Signed-off-by: Joseph C. Lehner <joseph.c.lehner@gmail.com>
SVN-Revision: 48771
- Fix typo in board_data partition start address
- Increase board_data partition size in order to exploit all flash size
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
SVN-Revision: 48751
This patch adds support for Phicomm PSG1208.This is a router with MT7620A SoC with 8M flash and 64M ram.
The WPS led is uesd as status_led because the power light can't be controlled with GPIO.
It seems that the 5g wifi led is connected to MT7612E and it can't be controlled with GPIO too.
Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
SVN-Revision: 48721
This patch adds support for the Netgear EX2700 and builds an approriate
sysupgrade image.
What's missing is the option to build a factory image flashable via the
router's stock web interface, but this approach is hindered by the fact
that u-boot operforms an additional integrity check, which expects a
uImage header in the last 64 bytes of the "kernel" partition, which
the bootloader expects to be 960k, a size exceeded by the standard
OpenWrt kernel.
Signed-off-by: Joseph C. Lehner <joseph.c.lehner@gmail.com>
SVN-Revision: 48698
The top half of UARTF on the HLK-RM04 is used for GPIO.
mode 1 mode 2
RIN GPIO14
DSR_N GPIO13
DCD_N GPIO12
DTR_N GPIO11
RXD GPIO10
CTS_N GPIO09
TXD GPIO08
RTS_N GPIO07
This patch applies 3'b101 mode to UARTF:
GPIO14
GPIO13
GPIO12
GPIO11
RXD
CTS_N
TXD
RTS_N
Because the base rt5350.dtsi file forces 3'b000 mode, remove the pin setting from this file and apply it directly to the files that inherit from it (WIZFI630A.dts and WT1520.dtsi). This change makes the rt5350.dtsi file consistent with the mt7620a.dtsi file.
Signed-off-by: John Clark <inindev@gmail.com>
SVN-Revision: 48665
The I2C function of the RT5350 SoC on the HLK-RM04 is used for GPIO1 and GPIO2.
Take note that the I2C_SD pin is GPIO1 on the RT5350 and is exposed on the HLK-RM04 as GPIO0
Likewise the I2C_SCLK pin is GPIO2 on the RT5350 and is exposed on the HLK-RM04 as GPIO1
group mode 1 mode 2 hlk-rm04 pin & export
i2c i2c_sd gpio1 (pin 8, hlk-rm04:gpio0)
i2c i2c_sclk gpio2 (pin 9, hlk-rm04:gpio1)
reference:
http://www.hlktech.net/product_detail.php?ProId=39http://cdn.sparkfun.com/datasheets/Wireless/WiFi/RT5350.pdf
Signed-off-by: John Clark <inindev@gmail.com>
SVN-Revision: 48664
The RESET button of the HLK-RM04 is connected to GPIO0, linux function 0x198
The WPS button of the HLK-RM04 is connected to GPIO14, linux function 0x211
Signed-off-by: John Clark <inindev@gmail.com>
SVN-Revision: 48663
The power LED on the HLK-RM04 is hard wired to the power bus and is not under GPIO control, remove the bogus config for it.
(Note that GPIO0 is actually connected to the RESET button.)
Signed-off-by: John Clark <inindev@gmail.com>
SVN-Revision: 48662
The bootloader was updated and now uses 115200 instead of 57600 baud
for the serial console. Change this also in OpenWrt's DTS, so the rate
is consistent for bootloader and linux kernel output.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
SVN-Revision: 48359
The image name for the HiLink HLK-RM04 module has a typo and should read "RM04" rather than "RM02"
Signed-off-by: John Clark <inindev@gmail.com>
SVN-Revision: 48355
LED's were defined wrong in the device tree file, they are hardware driven because they are connected directly to the switch chip and wireless chips respectively, thus no GPIO addresses are assigned to them. It is safe to remove them from the device tree file to stop confusion.
Signed-off-by: Sebastian Careba <nitroshift@yahoo.com>
SVN-Revision: 48055
