Use the generic board detection method:
- Board name: First compatible string from the device tree
- Board model: Model property from the device tree
Change occurrences of board name in userspace by the compatible
string, and removed target specific board detection script
Replace the definition of SUPPORTED_DEVICES in Device/Default
to extract the dt compatible string from each device definition.
Additionally, for devices supported by lede-17.01, append
the value of BOARD_NAME to SUPPORTED_DEVICES in the device
definition.
Signed-off-by: Luis Araneda <luaraneda@gmail.com>
No image build code for the Guruplug, Sheevaplug and NSA310S exists. Drop
support for the boards for now.
Signed-off-by: Mathias Kresin <dev@kresin.me>
The LinkIt Smart 7688/LinkIt Smart 7688 Duo are identical beside the
extra ATmega32U4 - accessible via UART - on the the Duo.
Since all relevant hardware is identical, drop the Duo special handling
in userspace.
Signed-off-by: Mathias Kresin <dev@kresin.me>
Use the first compatible string as board name in userspace. Add the new
board name as well as the former used board name to the image metadata
to keep compatibilty with already deployed installations.
Don't add the former used boardname for boards which exists only in
master or evaluation boards.
Signed-off-by: Mathias Kresin <dev@kresin.me>
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>
IPQ806x AP148 and DB149 boards didn't have the UCI ubootenv
section initialized, so the usage of fw_printenv required manual
configuration. With this change, the "fw_printenv" and "fw_setenv"
command will automatically work on NOR and NAND based platforms.
Signed-off-by: Ram Chandra Jangir <rjangir@codeaurora.org>
EnGenius ENS202EXT is an outdoor wireless access point with
2-port 10/100 switch, detachable antennas and proprietery PoE.
The device is based on Qualcomm/Atheros AR9341 v1.
Specifications:
- 535/400/200 MHz (CPU/DDR/AHB)
- 64 MB of RAM
- 16 MB of FLASH
- UART (J1) header on PCB (unpopulated)
- 2x 10/100 Mbps Ethernet
- 2.4 GHz, up to 26dBm
- 2x external, detachable antennas
- 7x LED, 1x button
Flash instructions:
You have three options:
- Use the vendor firmware upgrade page on the web interface and give
it the factory.img. This is the easiest way to go about it.
- If you have serial access during u-boot, interrupt the normal boot
(any key before timeout) and run 'run failsafe_boot'; this will bring
you to a minimal openwrt luci image on ip 192.168.1.1 useful if you've
bricked the normal firmware.
- Use the vendor's management cli, which can be accessed via telnet
with the same credentials as the web login (default admin:admin), then
issue the following commands:
*** Hi admin, welcome to use cli(V-1.6.7) ***
---========= Commands Help =========---
stat -- Status
sys -- System
wless2 -- 2.4G-Wireless
mgmt -- Management
tree -- Tree
help -- Help
reboot -- Reboot
ens202ext>mgmt
Management
---========= Commands Help =========---
admin -- Administration
mvlan -- Management VLAN settings
snmp -- SNMP settings
backup -- Backup/Restore settings
autorb -- Auto reboot settings
fwgrade -- Firmware upgrade
time -- Time settings
wifisch -- Wifi schedule
log -- Log
diag -- Diagnostics
disc -- Device Discovery
logout -- Logout
help -- Help
exit -- Exit
ens202ext/mgmt>fwgrade
Management --> Firmware upgrade
---========= Commands Help =========---
fwup -- Firmware upgrade
help -- Help
exit -- Exit
ens202ext/mgmt/fwgrade>fwup http://web.server/lede-ar71xx-generic-ens202ext-squashfs-factory.bin
Signed-off-by: Marty Plummer <ntzrmtthihu777@gmail.com>
Use fixed led names and add each board variant instead of manipulating
the board name.
It makes the ramips board name function less different to the one used
in other targets and allows to merge them with a common function.
Signed-off-by: Mathias Kresin <dev@kresin.me>
The Pistachio target is a MIPS interaptiv based SoC developed by
Imagination Technologies. It includes blocks for i2c, spi, audio,
usb and WiFi.
This also adds the base support for the 'Creator Ci40 (marduk)'
device which uses the Pistachio SoC to create an IoT hub by
including Bluetooth, WiFi and 6lowpan on one board. Additionally 2x
Mikrobus ports are available to expand with further RF technologies
or add sensors. You can find out more here http://creatordev.io.
Note, this commit is just the initial board support hence the
following are not expected to work yet:
* WiFi
* Bluetooth
* 6lowpan
* Audio
* Mikrobus uarts, user leds (clock dependency of 6lowpan chip)
The aim of this commit is to essentially have the same level of
support that currently exists in the mainline kernel.
Signed-off-by: Abhijit Mahajani <Abhijit.Mahajani@imgtec.com>
Signed-off-by: Francois Berder <francois.berder@imgtec.com>
Signed-off-by: Ian Pozella <Ian.Pozella@imgtec.com>
Signed-off-by: Mayank Sirotiya <Mayank.Sirotiya@imgtec.com>
Signed-off-by: Sean Kelly <Sean.Kelly@imgtec.com>
accessing the u-boot's envs on this device is required to read the mac address.
These are the envs of the new u-boot, not of the stock one.
Signed-off-by: Alberto Bursi <alberto.bursi@outlook.it>
Few minor code formatting style fixes, including:
- keep one board per line
- always use "|\" (for consistency)
- remove redundant double quotes and empty lines
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
tools/env/fw_env.c misses to include stdint.h.
Apparently musl doesn't mind and includes this header by default,
but glibc does not and causes the build to fail.
Signed-off-by: Josua Mayer <josua.mayer97@gmail.com>
Xiaomi MiWiFi Nano is based on Mediatek MT7628 with 64MB ram 16MB flash
Signed-off-by: Noble Pepper <openwrtmail@noblepepper.com>
v3 includes changes suggested by L. D. Pinney & Karl Palsson-
Eliminate en25q64 (4MB) flash chip
Alphabetization
Remove hyphen in model
Rename profile from miwifinano.mk to xiaomi.mk
Add gpios that are attached to leds
SVN-Revision: 49024
OpenWrt configuration part of support for the PowerCloud Systems
CR5000. The CR5000 is a dual-band 802.11n wireless router with
8MB flash, 64MB RAM, (unused on stock firmware) USB 2.0 port and
five port gigabit ethernet switch. The CR5000 was sold as
hardware for the Skydog cloud-managed router service.
Signed-off-by: Daniel Dickinson <openwrt@daniel.thecshore.com>
SVN-Revision: 47946
OpenWRt configuration part of support for the PowerCloud
Systems CR3000. The CR3000 is a 802.11n 2.4 GHz wireless router with
8MB flash, 64MB RAM, a four port gigabit ethernet switch, and a fast
ethernet wan port that was sold by PowerCloud Systems as
hardware for the Skydog cloud-managed router service.
Signed-off-by: Daniel Dickinson <openwrt@daniel.thecshore.com>
SVN-Revision: 47945
Openwrt configuration part of support for PowerCloud CAP324
Cloud AP. The CAP324 Cloud AP is a device sold by PowerCloud Systems
who's stock firmware (CloudCommand) provides 'cloud' based managment
of large numbers access points.
The CAP324 is a dual-band 802.11n wireless access point with 16MB flash
and 128MB RAM and single gigabit ethernet port. It can be powered via PoE
or a wall wart.
Signed-off-by: Daniel Dickinson <openwrt@daniel.thecshore.com>
SVN-Revision: 47944
- Use board engineering names rather than marketing names
- Linksys uses a dual firmware layout, where the bootloader
will switch to the other stored image when one fails to
boot three consecutive times.
In order to make this firmware compatible with the factory
images and the stock bootloader we must match this layout.
Signed-off-by: Claudio Leite <leitec@staticky.com>
SVN-Revision: 47429
Note, that licensing stuff is a nightmare: many packages does not clearly
state their licenses, and often multiple source files are simply copied
together - each with different licensing information in the file headers.
I tried hard to ensure, that the license information extracted into the OpenWRT's
makefiles fit the "spirit" of the packages, e.g. such small packages which
come without a dedicated source archive "inherites" the OpenWRT's own license
in my opinion.
However, I can not garantee that I always picked the correct information
and/or did not miss license information.
Signed-off-by: Michael Heimpold <mhei@heimpold.de>
SVN-Revision: 43155
Qihoo C301 has 2 flash chips of which one is used as primary and the
other is used as backup. OEM U-Boot will try to boot an activeregion N
with imageNstatus=0 and imageNtrynum <= imagemaxtry. If such a region
is found, bootloader will try to increment imageNtrynum and boot it.
This patch tries to reset imageNtrynum after each successful boot (if
the boot process reaches the execution of /etc/init.d/done).
root@OpenWrt:/# hexdump -C -n 128 /dev/mtdblock9
00000000 9e f3 63 91 61 63 74 69 76 65 72 65 67 69 6f 6e |..c.activeregion|
00000010 3d 31 00 69 6d 61 67 65 31 73 74 61 74 75 73 3d |=1.image1status=|
00000020 30 00 69 6d 61 67 65 32 73 74 61 74 75 73 3d 30 |0.image2status=0|
00000030 00 69 6d 61 67 65 32 74 72 79 6e 75 6d 3d 30 00 |.image2trynum=0.|
00000040 69 6d 61 67 65 6d 61 78 74 72 79 3d 33 00 69 6d |imagemaxtry=3.im|
00000050 61 67 65 31 74 72 79 6e 75 6d 3d 30 00 00 00 00 |age1trynum=0....|
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
SVN-Revision: 42914
Generate the configuration file for uboot-envtools
on BTHOMEHUBV2B. Adds the specific parameters for the
BTHOMEHUBV2B and also fixes an incorrect path which
would have affected other lantiq boards as well
(currently only the GIGASX76X).
Signed-off-by: Ben Mulvihill <ben.mulvihill@gmail.com>
SVN-Revision: 41597
Insert a missing #ifdef UBI around the use of libubi_close().
As the preceding if (libubi) will never be true on non-UBI builds,
compiling only failed when disabling optimization.
Also rebase patch to latest u-boot.git HEAD.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
SVN-Revision: 41313
On UBI enabled devices, U-Boot might store it's environment on
UBI volume(s). Support this in uboot-envtools, so fw_setenv and
fw_printenv can work on these platforms.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
SVN-Revision: 40929
The settings require that the OpenWrt provided u-boot is used as either
first or second stage bootloader as it modifies the partitioning scheme
to move the u-boot environment to a separate mtd partition.
Signed-off-by: Felix Kaechele <heffer@fedoraproject.org>
SVN-Revision: 40829
