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>
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>
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>
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>
Use only the jedec,spi-nor compatible string. Everything else either
never worked or is only support to keep compatibility.
Remove the linux,modalias property. It is obsolete since kernel 4.4.
Signed-off-by: Mathias Kresin <dev@kresin.me>
All compiled device tree files not mentioned are binary identical to the
former ones.
Fix the obvious decimal/hex confusion for the power key of ramips/M2M.dts.
Due to the include of the input binding header, the BTN_* node names in:
- ramips/GL-MT300A.dts
- ramips/GL-MT300N.dts
- ramips/GL-MT750.dts
- ramips/Timecloud.dts
will be changed by the compiler to the numerical equivalent.
Move the binding include of lantiq boards to the file where they are
used the first time to hint the user where the values do come from.
Signed-off-by: Mathias Kresin <dev@kresin.me>
Add node aliases to dtsi files.
Reword dts files so they're more in-line with upstream.
Fix some more warnings and errors reported by dtc
Signed-off-by: Stanislav Galabov <sgalabov@gmail.com>
The following patch fixes:
* wrong indentations
* doubled gpio-keys-polled nodes (DIR-300-B7, DIR-320-B1, DIR-610-A1)
* duplicate spacings
* empty lines at end of files and after last child nodes
* trailing and leading whitespace
* unnecessary and commented-out code
* missing empty lines between nodes and between properties and nodes
* unnecessary empty lines between nodes properties [1]
in .dts{,i} files, for ramips target.
[1] Some of empty lines in SOCs dtsi files were left untouched, because they seem to be there for a reason (readability?).
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
SVN-Revision: 46613
This patch is a follow up for my previous patch:
"ramips: add support for Intenso Memory 2 Move USB 3.0".
It fixes a couple of errors in the DTS (one of which broke
the gpio-buttons). The kmod-leds-gpio dependency has been
dropped as it is already part of the ramips target.
Furthermore the ramdisk/uImage image is generated by default
for the rt3050 subtarget. This image is needed to flash
OpenWrt for the first time onto the device via TFTP.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
SVN-Revision: 44072
This adds support for a rt5350-based "portable nas" solution
from Intenso. The board comes with 32M RAM and 8M Flash, the
built-in HDD is connected/accessible via a usb3.0<->sata
bridge VLI VL701.
The device has 1 Ethernet port (100M/10M), 1 micro b usb 3.0
socket (for charging the battery, or accessing the hdd directly).
Wireless connectivity is provided by the rt5350 SoC [i.e.:
802.11n 1x1 2.4 GHz with a pcb antenna.]
Serial, leds, wifi, ethernet and usb are tested and
as far as I can tell: they are working fine (tm).
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
SVN-Revision: 44001
