aboutsummaryrefslogtreecommitdiffstats
path: root/target/linux/ramips/dts/D240.dts
Commit message (Collapse)AuthorAgeFilesLines
* ramips: dts: Unify naming of gpio-led nodesPetr Štetiar2019-02-051-1/+1
| | | | | | | | | | | | | | In DTS Checklist[1] we're now demanding proper generic node names, as the name of a node should reflect the function of the device and use generic name for that[2]. Everybody seems to be copy&pasting from DTS files available in the repository today, so let's unify that naming there as well and provide proper examples. 1. https://openwrt.org/submitting-patches#dts_checklist 2. https://github.com/devicetree-org/devicetree-specification/blob/master/source/devicetree-basics.rst#generic-names-recommendation Signed-off-by: Petr Štetiar <ynezz@true.cz> Signed-off-by: Christian Lamparter <chunkeey@gmail.com> [split up]
* ramips: dts: Unify naming of gpio-keys nodesPetr Štetiar2019-02-051-1/+1
| | | | | | | | | | | | | | In DTS Checklist[1] we're now demanding proper generic node names, as the name of a node should reflect the function of the device and use generic name for that[2]. Everybody seems to be copy&pasting from DTS files available in the repository today, so let's unify that naming there as well and provide proper examples. 1. https://openwrt.org/submitting-patches#dts_checklist 2. https://github.com/devicetree-org/devicetree-specification/blob/master/source/devicetree-basics.rst#generic-names-recommendation Signed-off-by: Petr Štetiar <ynezz@true.cz> Signed-off-by: Christian Lamparter <chunkeey@gmail.com> [split up]
* ramips: specify "firmware" partition formatINAGAKI Hiroshi2018-11-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Specify firmware partition format by compatible string. formats in ramips: - denx,uimage - tplink,firmware - seama It's unlikely but the firmware splitting might not work any longer for the following boards, due to a custom header: - EX2700: two uImage headers - BR-6478AC-V2: edimax-header - 3G-6200N: edimax-header - 3G-6200NL: edimax-header - BR-6475ND: edimax-header - TEW-638APB-V2: umedia-header - RT-N56U: mkrtn56uimg But it rather looks like the uImage splitter is fine with the extra header. The following dts are not touched, due to lack of a compatible string in the matching firmware splitter submodule: - CONFIG_MTD_SPLIT_JIMAGE_FW DWR-116-A1.dts DWR-118-A2.dts DWR-512-B.dts DWR-921-C1.dts LR-25G001.dts - CONFIG_MTD_SPLIT_TRX_FW WCR-1166DS.dts WSR-1166.dts - CONFIG_MTD_SPLIT_MINOR_FW RBM11G.dts RBM33G.dts - CONFIG_MTD_SPLIT_LZMA_FW AR670W.dts - CONFIG_MTD_SPLIT_WRGG_FW DAP-1522-A1.dts Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
* ramips: add Sanlinking Technologies D240 pinmux quirkMathias Kresin2018-11-261-0/+16
| | | | | | | | | | | | | | The sd function of the nd_sd group configures two of the groups pins as gpios. The pins are used as PCIe reset/power. Due to the driver load order, the pins are configured way to late if triggered by the sd-card driver. To not introduce another kind of driver load order dependency and configure the pins as early as possible, means during pinmux driver load. Signed-off-by: Mathias Kresin <dev@kresin.me>
* ramips: add support for indicating the boot state using multiple ledsMathias Kresin2018-10-071-1/+4
| | | | | | | | | 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>
* ramips: set usb led trigger via devicetreeMathias Kresin2018-10-071-0/+2
| | | | | | | | | | Assign the usbdev trigger via devicetree for all subtargets and drop the userspace handling of the usb leds. With the change all usb ports are triggering the usb led instead of only usb 1.1 XOR usb 2.0 XOR usb 3.0 as it was before. Signed-off-by: Mathias Kresin <dev@kresin.me>
* ramips: fix mt7620a ND/SD pins pinmuxesMathias Kresin2018-09-061-1/+1
| | | | | | | | | | Drop the nd_sd gpio pinmux in case sdcard is used. They're mutually exclusive and for most of the boards not even used as GPIOs. If the pins are in sdcard mode, the pins ND_WE_N and ND_CS_N are still GPIOs (#45 and #46). Signed-off-by: Mathias Kresin <dev@kresin.me>
* treewide: fix some cosmetic glitches in dts filesPaul Wassi2018-08-271-1/+0
| | | | | | | | | | | - 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>
* ramips: move partitions into partition table nodeAlex Maclean2018-08-041-23/+27
| | | | | | | | 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>
* ramips: fix dtc warningsMathias Kresin2018-08-041-2/+0
| | | | | | Fix individual boards dtc warnings or obvious mistakes. Signed-off-by: Mathias Kresin <dev@kresin.me>
* ramips: Use dts alias based status ledChuanhong Guo2018-07-161-1/+5
| | | | | | Also fix several typos in led node name. Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
* ramips: fix D240 mini-PCIe power control GPIOsKristian Evensen2017-09-131-3/+14
| | | | | | | | | | | | | | | | In commit b11c51916cb9 ("ramips: Improve Sanlinking D240 config") I made a mistake with regards GPIO numbering. And in addition to specifying the wrong GPIO for controling the power of one of the mini-PCIe, I recently discovered that the power of both slots can be controlled. This patch specifies the correct GPIO for the left-most mini-PCIe slot of the D240 (labeled power_mpcie2 since the slot is attached to SIM2), and adds a GPIO that can be used to control the power of the other mini-PCIe slot (labeled power_mpcie1). Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com> [do not use the gpio active macros for the gpio-export value] Signed-off-by: Mathias Kresin <dev@kresin.me>
* ramips: update device tree source filesL. D. Pinney2017-08-031-1/+1
| | | | | | | | Use the GPIO dt-bindings macros and add compatible strings in the ramips device tree source files. Signed-off-by: L. D. Pinney <ldpinney@gmail.com> Signed-off-by: Mathias Kresin <dev@kresin.me>
* ramips: Improve Sanlinking D240 configKristian Evensen2017-03-111-0/+11
| | | | | | | | | | | | | | | | | * The left most mini-PCIe slot (the one attached to SIM2) can be power-cycled by setting GPIO 0 to high/low. * The D240 only needs the MT76x2 module, so update makefile to reflect this. Note that until the default mt7620 target is updated, then kmod-mt76 (and thus kmod-mt7603) will be selected by default. v2->v3: * Indentation error. v1->v2: * Rename gpio and remove redundant comment (thanks Piotr Dymacz) Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com>
* ramips: replace remaining instances of ralink, port-mapDaniel Golle2017-02-151-1/+1
| | | | | | | | | | | | Some boards were apparently forgotten when ralink,portmap was renamed to mediatek,portmap -- probably because they used the long obsolete ralink,port-map attribute. If this commit breaks ethernet wan/lan assignment, this is because the port-map attribute wasn't actually parsed, you'll have to replace "wllll" by "llllw" in the dts file belonging to that board (and send a patch doing that!) Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* ramips: add support for Sanlinking D240Kristian Evensen2017-02-051-0/+157
The Sanlinking Technologies D240 (http://www.sanlinking.com/en/29-dual-4g-wifi-router.html) is basically the same device as the ZBT WE826, so adding support for it in LEDE is straight forward. The differences is that the D240 has two mini-PCIe slots (instead of one), blue LEDs and supports PoE. Specification: * CPU: MT7620A * 1x 10/100Mbps POE (802.3af/802.3at) Ethernet, 4x 10/100Mbps. * 16 MB Flash. * 128 MB RAM. * 1x USB 2.0 port. * 2x mini-PCIe slots. * 2x SIM slots. * 1x 2.4Ghz WIFI. * 1x button. Wifi, USB, switch and both mini-PCIe slots are working. I have not been able to test the SD card reader. The device comes pre-installed with an older version of OpenWRT, including Luci. In order to install LEDE, you need to follow the existing procedure for updating OpenWRT/LEDE using Luci. I.e., you need to access the UI and update the firmware using the sysupgrade-image. Remember to select that you do not want to keep existing settings. The default router address is 192.168.10.1 and username/password admin/root (at least on my devices). If you brick the device, the procedure for recovery is the same as for the WE826. Please see the wiki page for that device for instructions. Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com>