Commit graph

9 commits

Author SHA1 Message Date
Mathias Kresin
8f4dfadd5a ramips: add support for indicating the boot state using multiple leds
Use diag.sh version used for other targets supporting different leds
for the different boot states.

The existing led sequences should be the same as before.

Signed-off-by: Mathias Kresin <dev@kresin.me>
2018-10-07 11:34:18 +02:00
Paul Wassi
e348ccc4e6 treewide: fix some cosmetic glitches in dts files
- fix single spaces hidden by a tab
- replace indentation with spaces by tabs
- make empty lines empty
- drop trailing whitespace
- drop unnecessary blank lines

Signed-off-by: Mathias Kresin <dev@kresin.me>
Signed-off-by: Paul Wassi <p.wassi@gmx.at>
2018-08-27 19:31:17 +02:00
Alex Maclean
6031ab345d ramips: move partitions into partition table node
Starting with kernel 4.4, the use of partitions as direct subnodes of the
mtd device is discouraged and only supported for backward compatiblity
reasons.

Signed-off-by: Alex Maclean <monkeh@monkeh.net>
2018-08-04 08:39:35 +02:00
Mathias Kresin
53624c1702 ramips: fix dtc warnings
Fix individual boards dtc warnings or obvious mistakes.

Signed-off-by: Mathias Kresin <dev@kresin.me>
2018-08-04 08:39:35 +02:00
Mathias Kresin
f9b8328d79 ramips: fix pci/pcie related dtc warnings
Add the ranges property to the PCI bridges where missing. Add the unit
address to PCI bridge where missing.

Rework the complete rt3883 pci node. Drop the PCI unit nodes from the
dtsi. They are not used by any dts file and should be rather in the dts
than in the SoC dtsi. Express the PCI-PCI bridge in a clean devicetree
syntax. The ralink,pci-slot isn't used by any driver, drop it. Move the
pci interrupt controller out of the pci node. It doesn't share the same
reg and therefore should be an independent/SoC child node.

Move the pci related rt3883 pinctrl setting to the dtsi instead of
defining the very same for each rt3883 board.

If the device_type property is used for PCI units, the unit is treated
as pci bridge which it isn't. Drop it for PCI units.

Reference pci-bridges or the pci node defined in the dtsi instead of
recreating the whole node hierarchy. It allows to change the referenced
node in the dtsi without the need to touch all dts.

Fix the PCI(e) wireless unit addresses. All our PCI(e) wireless chips
are the first device on the bus. The unit address has to be the bus
address instead of the PCI vendor/device id.

Signed-off-by: Mathias Kresin <dev@kresin.me>
2018-08-04 08:39:35 +02:00
Chuanhong Guo
c9c4b2116c ramips: Use dts alias based status led
Also fix several typos in led node name.

Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
2018-07-16 15:12:18 +02:00
Kevin Darbyshire-Bryant
8110bf18f4 ramips: mir3g dts define usb port Vcc volt regulator GPIO
Define USB port power on/off GPO as voltage regulator type instead of
exposing as a normal GPIO.

The GPO is now controlled by the USB driver via the voltage regulator
definition.  The regulator is of fixed output type (5V for USB) hence the
GPO switches power on/off to USB pin 1 (Vcc)

USB port power is enabled on driver load and disabled on driver unload.

Enable kernel support for fixed voltage regulator types on mt7621.

Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
2018-06-08 09:31:36 +02:00
Kevin Darbyshire-Bryant
f2107fc328 ramips: improve Xiaomi Mi Router 3G support
This commit improves support for the Xiaomi Mi Router 3G originally
added in commit 6e283cdc0d

Improvements:

- Remove software watchdog as hardware watchdog now working as per
  commit 3fbf3ab44f for all mt7621
  devices.

- Reset button polarity corrected - length of press determines reboot
  (short press) vs. reset to defaults (long press) behaviour.

- Enable GPIO amber switch port LEDs on board rear - lit indicates 1Gbit
  link and blink on activity.  Green LEDs driven directly by switch
  indicating any link speed and tx activity.

- USB port power on/off GPIO exposed as 'usbpower'

- Add access to uboot environment settings for checking/setting uboot
  boot order preference from user space.

Changes:

- Front LED indicator is physically made of independent Yellow/Amber,
  Red & Blue LEDs combined via a plastic 'lightpipe' to a front panel
  indicator, hence the colour behaviour is similar to an RGB LED. RGB
  LEDs are not supported at this time because they produce colour results
  that do not then match colour labels, e.g. enabling 'mir3g:red' and
  'mir3g:blue' would result in a purple indicator and we have no such
  label for purple.
  The yellow, red & blue LEDs have been split out as individual yellow,
  red & blue status LEDs, with yellow being the default status LED as
  before and with red's WAN and blue's USB default associations removed.

- Swapped order of vlan interfaces (eth0.1 & eth0.2) to match stock vlan
  layout. eth0.1 is LAN, eth0.2 is WAN

- Add 'lwlll' vlan layout to mt7530 switch driver to prevent packet
  leakage between kernel switch init and uci swconfig

uboot behaviour & system 'recovery'

uboot expects to find bootable kernels at nand addresses 0x200000 &
0x600000 known by uboot as "system 1" and "system 2" respectively.
uboot chooses which system to hand control to based on 3 environment
variables: flag_last_success, flag_try_sys1_failed & flag_try_sys2_failed

last_success represents a preference for a particular system and is set
to 0 for system 1, set to 1 for system 2.  last_success is considered *if*
and only if both try_sys'n'_failed flags are 0 (ie. unset) If *either*
failed flags are set then uboot will attempt to hand control to the
non failed system. If both failed flags are set then uboot will check
the uImage CRC of system 1 and hand control to it if ok.  If the uImage
CRC of system is not ok, uboot will hand control to system 2
irrespective of system 2's uImage CRC.

NOTE: uboot only ever sets failed flags, it *never* clears them. uboot
sets a system's failed flag if that system's was selected for boot but
the uImage CRC is incorrect.

Fortunately with serial console access, uboot provides the ability to
boot an initramfs image transferred via tftp, similarly an image may
be flashed to nand however it will flash to *both* kernels so a backup
of stock kernel image is suggested. Note that the suggested install
procedure below set's system 1's failed flag (stock) thus uboot ignores
the last_success preference and boots LEDE located in system 2.

Considerable thought has gone into whether LEDE should replace both
kernels, only one (and which one) etc. LEDE kernels do not include a
minimal rootfs and thus unlike the stock kernel cannot include a
method of controlling uboot environment variables in the event of
rootfs mount failure. Similarly uboot fails to provide an external
mechanism for indicating boot system failure.

Installation - from stock.

Installation through telnet/ssh:
- copy lede-ramips-mt7621-mir3g-squashfs-kernel1.bin and
  lede-ramips-mt7621-mir3g-squashfs-rootfs0.bin to usb disk or wget it
  from LEDE download site to /tmp
- switch to /extdisks/sda1/ (if copied to USB drive) or to /tmp if
  wgetted from LEDE download site
- run: mtd write lede-ramips-mt7621-mir3g-squashfs-kernel1.bin kernel1
- run: mtd write lede-ramips-mt7621-mir3g-squashfs-rootfs0.bin rootfs0
- run: nvram set flag_try_sys1_failed=1
- run: nvram commit
- run: reboot

Recovery - to stock.

Assuming you used the above installation instructions you will have a
stock kernel image in system 1. If it can be booted then it may be used
to perform a stock firmware recovery, thus erasing LEDE completely. From
a 'working' LEDE state (even failsafe)

Failsafe only:
- run: mount_root
- run: sh /etc/uci-defaults/30_uboot-envtools
Then do the steps for 'All'

All:
- run: fw_setenv flag_try_sys2_failed 1
- run: reboot

The board will reboot into system 1 (stock basic kernel) and wait with
system red light slowly blinking for a FAT formatted usb stick with a
recovery image to be inserted.  Press and hold the reset button for
around 1 second. Status LED will turn yellow during recovery and blue
when recovery complete.

Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
2017-09-28 09:20:36 +02:00
Pavel Kubelun
6e283cdc0d ramips: add Xiaomi Mi Router 3G support
This commit adds support for Xiaomi Mi WiFi Router 3G.

Short specification:
 - MT7621AT + MT7603EN + 7612EN
 - 256MB DDR3 RAM
 - 128MB NAND flash
 - 1+2 x 1000M Ethernet
 - 1x USB 3.0 port
 - reset button
 - yellow, blue, red leds

Installation through telnet/ssh:
- copy lede-ramips-mt7621-mir3g-squashfs-kernel1.bin and
lede-ramips-mt7621-mir3g-squashfs-rootfs0.bin to usb disk or wget it
from LEDE download site to /tmp
- switch to /extdisks/sda1/ (if copied to USB drive) or to /tmp if
wgetted from LEDE download site
- run: mtd write lede-ramips-mt7621-mir3g-squashfs-kernel1.bin kernel1
- run: mtd write lede-ramips-mt7621-mir3g-squashfs-rootfs0.bin rootfs0
- run: mtd erase kernel0
- run: reboot

Originally stock firmware has following partitions:
 - ...
 - kernel0 (primary kernel image)
 - kernel1 (secondary kernel image, used by u-boot in failsafe routine)
 - rootfs0 (primary rootfs)
 - rootfs1 (secondary rootfs in case primary fails)
 - overlay (used as ubi overlay)

This commit squashes rootfs0, rootfs1 and overlay partitions into 1, so
it can be used by LEDE fully for package installation, resulting in 117,5MiB.

This device lacks hw watchdog, so adding softdog instead (stock does the same).

Signed-off-by: Pavel Kubelun <be.dissent@gmail.com>
2017-08-23 14:59:12 +02:00