No single target/arch uses it and most likely there is no need to make
such a potential code target/arch specific.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
If "compatible" is being used that should trigger a proper parser
directly. It's more reliable thanks to not trying parsers one by one. In
such case partition shouldn't be split automatically to avoid parsing it
twice.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Currently, the b53 MDIO switch driver registers the switch on
config-init and not on device probe. Because of this, the switch
gets added every time the associated interface comes up.
This commit fixes this behavior by registering the switch on device
probe.
Compile- and run-tested on OCEDO Koala.
Signed-off-by: David Bauer <mail@david-bauer.net>
It's more reliable as mtd subsystem doesn't have to blindly try that
parser. It allows disabling MTD_SPLIT_FIRMWARE completely (TRX is
handled in a similar way).
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
It makes more sense to add run_parsers_by_type() in a patch that
introduces parser types. That makes the other one just add a code using
it.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
There was a bug in ubifs related to the O_TMPFILE. When reapplying
changes after power cut data could be lost. This problem was exposed by
overlayfs and the upstream commit 3a1e819b4e80 ("ovl: store file handle
of lower inode on copy up").
This fixes a regression introduced when switching from 4.9 to 4.14.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
It has been rejected upstream and instead a nice/more generic solution
has been implemented. It's possible now to describe partitions format
using "compatible" DT string.
No OpenWrt target uses "linux,part-probe" anymore, leave it only in case
some forks need it. It will be dropped with support for new kernels.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
as indicated in commit c5bf408ed6 "(ramips: fix image generation for mt76x8")
more rework was needed to fix the other issues.
Building on another machine, but using the same arch, showed
the application failing again for different reasons.
Fix this by completely rewriting the application, fixing following found issues:
- buffer overflows, resulting in stack corruption
- flaws in memory requirement calculations (too small, too large)
- memory leaks
- missing bounds checking on string handling
- non-reproducable images, by using unitilized memory in checksum calculation
- missing error handling, resulting in succes on specific image errors
- endianness errors when building on BE machines
- various minor build warnings
- documentation did not match the code actions (header item locations)
- allowing input to be decimal, hex or octal now
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
Following errors were seen in the past on imx6 when using serial:
[ 22.617622] imx-uart 2020000.serial: DMA transaction error.
[ 22.623228] imx-uart 2020000.serial: DMA transaction error.
[ 22.628826] imx-uart 2020000.serial: DMA transaction error.
[ 22.648951] imx-uart 2020000.serial: DMA transaction error.
[ 22.654558] imx-uart 2020000.serial: DMA transaction error.
[ 22.660156] imx-uart 2020000.serial: DMA transaction error.
Which is the reason why DMA for the serial ports
got disabled in commits:
efb362cd93 ("imx6: disable dma on uart")
3b4241071d ("imx6: disable UART dma")
As indicated on mailinglist discussion, the cause seems to be
the usage of very old SDMA firmware which is present in the soc:
[ 0.624302] imx-sdma 20ec000.sdma: Direct firmware load for imx/sdma/sdma-imx6q.bin failed with error -2
[ 0.624318] imx-sdma 20ec000.sdma: Falling back to user helper
[ 64.531607] imx-sdma 20ec000.sdma: external firmware not found, using ROM firmware
This patch adds the new firmware binary. (2196 bytes)
It is required to embed the binary into the kernel image, as it
gets loaded very early in the boot process where the rootfs is not
available yet:
[ 0.622966] imx-sdma 20ec000.sdma: loaded firmware 3.3
Extended testing shows that the DMA errors are not seen anymore
when using this newer firmware version.
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
The bump to kernel 4.14 caused a massive increase in kernel size.
For most targets, switching them to dynamic partitioning allowed
to cope with this.
On some targets, the kernel partition is located behind the rootfs,
which disallows switching to dynamic partitioning as the boot location
would be altered, requiring a u-boot change.
Also within the tiny section, which disables kernel symbols etc
to decrease the image size, the partition size is still too small.
Disable these targets for now, fixing image generation:
- Buffalo BHR-4GRV2
- Zbtlink ZBT-WE1526
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
The NBG6617's LEDs are wrongly identified in the 01_leds boardinit
script (board instead of boardname), resulting in referencing
non-existent LEDs in UCI.
Signed-off-by: David Bauer <mail@david-bauer.net>
For each board, set the legacy name as well as the new based on the
compatible-string from devicetree.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
remove /lib/oxnas.sh platform-specific board-detection and use
generic which is based on device-tree compatible node instead.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The BDFs for all boards were upstreamed to the ath10k-firmware
repository and linux-firmware.git.
We switched to the upstream board-2.bin, hence the files can be removed
here.
Keep the ipq-wifi package in case new boards are added. It might take
some time till board-2.bins send upstream are merged.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
The NBG6617's boardfile was merged and this device can
now switch to the upstream ath10k board-2.bin.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
This patch replaces the custom autoload quirk of the
RT-AC58U with a bootargs-append overwrite.
The vendor's u-boot doesn't leave the bootargs / cmdline alone,
so the it can't be overwritten in any other way right now...
And of course, this will be a lot of fun to deal with once
the device switches to the new spi-nand subsystem.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Kernel 4.14 is pretty large causing a build error as the partition is too small.
Expand the kernel partition a bit to make it fit.
* ubnt-uap-pro
* ubnt-unifi-outdoor-plus
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
This target causes a build failure as the kernel image does not fit
into the kernel partition.
As the kernel is located behind the rootfs, it cannot be enlarged
as the boot entry location would get altered.
Disable this target for now.
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
Targets:
- TP-LINK ER355
- TP-LINK C25 V1
- TP-LINK C59 V1
- TP-LINK C7 V4
- TP-LINK C7 V5
Fixes build issues seen due to the kernel being too big
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
As mentioned in commit 5f24933 recent changes on ar71xx (switch to 4.14,
memory compaction, ...) cause an increase in kernel size, making it too
big for RE450.
RE450 images were not build due to the following error message:
os-image partition too big (more than 1572864 bytes): Success
Tested on RE450, device boots and was used to send this patch.
Reported-by: Enrico Mioso <mrkiko.rs@gmail.com>
Suggested-by: David Bauer <mail@david-bauer.net>
Signed-off-by: Radek Dostál <rd@radekdostal.com>
[rewrote commit msg keeping it tight + fixed SoB lines]
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
This changes the OCEDO Koala flash-layout to a unified firmware
partition, thus making the ar71xx-generic kernel fit in flash.
Compile and runtested on OCEDO Koala.
Signed-off-by: David Bauer <mail@david-bauer.net>
[small title reword]
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
This commit adds support for the Ubiquiti LiteAP ac (LAP-120), an outdoor
5 GHz AC access point with an integrated 120° 16 dBi antenna. The device
was previously known as LiteBeam AP ac but was later rebranded.
CPU: Atheros AR9342 SoC
RAM: 64 MB DDR2
Flash: 16 MB NOR SPI
Ports: 1 GbE port (PoE in)
WLAN: 5 GHz QCA899X (PCI)
The integrated QCA899X is a Ubiquiti branded part with modified vendor
and product id (0777:11ac9). It is very similar to the NanoStation loco
AC, except for the 2.4 GHz management radio (missing here).
Installation procedure is the same as the NanoStation [loco] AC:
1. Connect to serial header on device
2. Power on device and enter uboot console
3. Set up tftp server serving an openwrt initramfs build
4. Load initramfs build using the command tftpboot in the uboot cli
5. Boot the loaded image using the command bootm
6. Copy squashfs openwrt sysupgrade build to the booted device
7. Use mtd to write sysupgrade to partition "firmware"
8. Reboot and enjoy
Signed-off-by: Roger Pueyo Centelles <roger.pueyo@guifi.net>
Regression introduced with 4.10 by 43c9127d94d62a232ed33ed2eab8a08657ce5472
Build will fail if system 'ar' does not support deterministic builds.
e.g. macOS with Xcode toolchain
Appears to be fixed upstream in 4.18 by af3901cbbd3de182aafb8ee553c825c0074df6a2
Signed-off-by: Ryan Mounce <ryan@mounce.com.au>
The WNDR4700 and the MBL have a dedicated HDD activity LED.
This patch adds the default led triggers to the DTS and
removes the entries in 01_leds.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
- order entries by mmio address where possible
- switch to lower-case address values
- comment on BSP u-boot behaviour in regards to
what it edits and look for
- annotate irq lines with the help of interrupt-names
- remove deprecated "device_type" properties
The pci and network device_type had to stay since
they are required by the drivers and u-boot.
the cpu and memory device_types will remain as well
as they are still part of the DT Spec.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
With the upcoming 4.19 release, the serial console on the
Netgear WNDR4700 would no longer work as it is never really
set and always relied on the kernel's serial code not to
change the baud rate.
On the stock firmware, Netgear forced the console setting
through a custom CONFIG_CMDLINE in their kernel to 115200.
Normally, they should have done it in a different way and
just passed the baudrate through a "console=..." kernel
parameter via the bootargs in the "/chosen" dt node.
But in their default u-boot bootcmd setting, they somehow
forgot to add the "run addtty", so there's no easy way to
pass the baudrate from u-boot to the kernel. So it has
to be forced as otherwise it ends up as 9600 baud.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
I noticed that the image generator for the Gemini generates
some 10+ MB files for the second (application) partition.
This is just wrong. The first 6144K partition named initramfs
easily fits OpenWRTs squashfs,jffs2 overlayed partitions
with nice headroom for storing configuration files.
Generate a blank partition for the hddapp.tgz file and delete
it after generating the firmware image - when performing
updates manually you just want the "rd.z" file around
anyways.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This creates a new kernel package for the fotg210 host
controller and uses that with the gemini to shrink the
kernel. The SQ201 needs the USB2 PCI package as well.
The build system required me to make kernel_oldconfig
beofore it would build without errors so some minor
unrelated Kconfig entries are changed.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Newer batches of several Mikrotik boards contain this yet-unsupported
flash chip, for instance:
- rb941-2nd (hAP lite)
- rb952ui-5ac2nd (hAP ac lite)
- RBM33G
and probably other Mikrotik boards need this patch as well.
The patch was submitted upstream by Robert Marko: https://patchwork.ozlabs.org/patch/934181/
Closes: FS#1715
Signed-off-by: Baptiste Jonglez <git@bitsofnetworks.org>
Cc: Robert Marko <robimarko@gmail.com>
Refreshed all patches.
Altered patches:
- 666-Add-support-for-MAP-E-FMRs-mesh-mode.patch
New symbol for arm targets:
- HARDEN_BRANCH_PREDICTOR
Compile-tested on: ar71xx, cns3xxx, imx6
Runtime-tested on: ar71xx, cns3xxx, imx6
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
In commit fec8fe8069 ("kernel: bump 4.9 to 4.9.116") [1], the following patch for removed:
- 403-mtd_fix_cfi_cmdset_0002_status_check.patch
This patch contained fixes for both write and erase functions.
While the chip-detects for erase got fixed upstream [2],
some modifications are still required, even with the fixes applied.
While at it, also apply the same fix for target ath79,
which suffers the same issue.
Not doing so results in following errors seen:
Collected errors:
* pkg_write_filelist: Failed to open //usr/lib/opkg/info/luci-lib-ip.list: I/O error.
* opkg_install_pkg: Failed to extract data files for luci-lib-ip. Package debris may remain!
* opkg_install_cmd: Cannot install package luci-ssl.
* opkg_conf_write_status_files: Can't open status file //usr/lib/opkg/status: I/O error.
[ 0.780920] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc.
[ 8.406396] jffs2: notice: (415) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
[ 8.423476] mount_root: switching to jffs2 overlay
[ 270.902671] jffs2: Write of 1989 bytes at 0x005ce6f8 failed. returned -5, retlen 962
[ 270.931965] jffs2: Write of 1989 bytes at 0x005ceec0 failed. returned -5, retlen 0
[ 270.939631] jffs2: Not marking the space at 0x005ceec0 as dirty because the flash driver returned retlen zero
[ 270.950397] jffs2: Write of 68 bytes at 0x005ceec0 failed. returned -5, retlen 0
[ 270.957838] jffs2: Not marking the space at 0x005ceec0 as dirty because the flash driver returned retlen zero
[ 270.968584] jffs2: Write of 68 bytes at 0x005ceec0 failed. returned -5, retlen 0
[ 270.976027] jffs2: Not marking the space at 0x005ceec0 as dirty because the flash driver returned retlen zero
[ 270.986735] jffs2: Write of 68 bytes at 0x005ceec0 failed. returned -5, retlen 0
[ 270.994225] jffs2: Not marking the space at 0x005ceec0 as dirty because the flash driver returned retlen zero
[1] https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=fec8fe806963c96a6506c2aebc3572d3a11f285f
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v4.9.133&id=a0239d83e1cb60de5e78452d4708c083b9e3dcbe
Fixes: fec8fe8069 ("kernel: bump 4.9 to 4.9.116")
Signed-off-by: Fabio Bettoni <fbettoni@gmail.com>
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
Recent changes on ar71xx (switch to 4.14, memory compaction, ...) cause
an increase in kernel size, making it too big for some devices.
Move these devices to the tiny target, where kernel symbols and
optimization for speed are disabled, reducing the kernel size.
Devices:
- EnGenius ENS202EXT
- OCEDO Koala
Compile-tested targets:
- ar71xx->generic->default
- ar71xx->smallFlash->Default
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
Add out of the box support for 802.11r and 802.11w to all targets not
suffering from small flash.
Signed-off-by: Mathias Kresin <dev@kresin.me>
Mathias did all the heavy lifting on this, but I'm the one who should
get shouted at for committing.
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
It's required to support devices using adjustable SoC pins for some
specific purpose (e.g. I2C, PWM, UART1).
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Instead of reverting whole commit it's enough to just revert a single
line change. It seems the real problem with the regressing commit was a
bump of read chunk size. Switching back to 256 B chunks is enough to fix
the problem/regression.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Compaction is the only memory management component to form high order (larger
physically contiguous) memory blocks reliably. The page allocator relies on
compaction heavily and the lack of the feature can lead to unexpected OOM
killer invocations for high order memory requests. You shouldn't disable this
option unless there really is a strong reason for it.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Michal Hrusecky <michal.hrusecky@nic.cz>
Optimized inlining was disabled by default when gcc 4 was still
relatively new. By now, all gcc versions handle this well and there
seems to be no real reason to keep it x86-only.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
This commit adds support for the TP-Link TL-WR901ND v2 access point.
CPU: Atheros AR9132 400MHz
RAM: 32MB
FLASH: 4MiB
WiFi: Atheros AR9103 3x3:2 bgn
LED: Power (static on)
LAN (controlled by PHY)
SYS, WiFi, QSS toggleable
BTN: Reset, QSS
Installation:
Upload the factory image via the vendor-GUI.
Signed-off-by: David Bauer <mail@david-bauer.net>
Buffalo WZR-HP-G302H is a 2T2R 2.4 GHz 11n router, based on Atheros
AR7242.
It is Japanese market model of WZR-HP-G300NH2, but there are some
diffrences. This commit is based on WZR-HP-G300NH2 in ar71xx.
And, G302H has several hardware versions and hardware is different
dependent on the versions. This commit adds support for "A1A0"
version.
Specification:
- Atheros AR7242
- 64 MB of RAM (DDR2)
- 32 MB of Flash
- 2x 16 MB SPI-NOR flash
- 2.4 GHz 2T2R wifi
- Atheros AR9283
- 5x 10/100/1000 Mbps Ethernet
- Atheros AR8316
- 7x LEDs, 5x keys
- LED: 1x gpio-leds, 6x ath9k-leds
- key: 3x buttons, 2x slide switches
- UART header on PCB
- Vcc, GND, TX, RX from ethernet port side
- 115200n8
Flash instruction using factory image:
1. Boot WZR-HP-G302H normaly and connect the computer to its LAN port
2. Access to "http://192.168.11.1/" and move to firmware update page
("ファーム更新")
3. Select the OpenWrt factory image and click update ("更新実行")
button to perform firmware update
4. Wait ~200 seconds to complete flashing
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
In order to be able to set the value of "hardware version" other than
"3", I added the "hwver" parameter.
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
This PR adds support for TP-Link TL-WR842N-v2 router which is supported by ar71xx to ath79.
This is a low cost model with following specs:
CPU: Atheros AR9341 SoC
RAM: 32 MB DDR1
Flash: 8 MB NOR SPI
Switch: Internal AR9341 5 port 10/100 Mbit
Ports: 5x 10/100 Mbit(1x WAN, 4x LAN)
USB: 1x USB2.0
WLAN: 2.4 GHZ AR9341
Installation:
Simply flash the factory image through stock firmware WEB UI.
Signed-off-by: Robert Marko <robimarko@gmail.com>
The sysupgrade_pre_upgrade hook was removed with 5e1b4c57de ("base-files:
drop fwtool_pre_upgrade") while there were still scripts using it:
* target/linux/ar71xx/base-files/lib/upgrade/allnet.sh
* target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh
* target/linux/ipq40xx/base-files/lib/upgrade/openmesh.sh
Not running the hooks can either prevent a successful upgrade or brick the
device because the fw_setenv program cannot be started correctly.
Instead of adding this hook again, the directory /var/lock for fw_setenv
can also just be created directly before fw_setenv is called.
Fixes: 5e1b4c57de ("base-files: drop fwtool_pre_upgrade")
Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com>
The sysupgrade_pre_upgrade hook was removed with 5e1b4c57de ("base-files:
drop fwtool_pre_upgrade") while there were still scripts using it:
* target/linux/ar71xx/base-files/lib/upgrade/allnet.sh
* target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh
* target/linux/ipq40xx/base-files/lib/upgrade/openmesh.sh
Not running the hooks can either prevent a successful upgrade or brick the
device because the fw_setenv program cannot be started correctly.
Instead of adding this hook again, the directory /var/lock for fw_setenv
can also just be created directly before fw_setenv is called.
Fixes: 5e1b4c57de ("base-files: drop fwtool_pre_upgrade")
Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com>
The install_bin from /lib/upgrade/common.sh is no longer creating the
symlinks when a secondary parameter is added. But the fw_setenv program was
always copied this way to the ramdisk for the upgrade.
Instead, this should be done using RAMFS_COPY_* like on all other
platforms.
Fixes: 438dcbfe74 ("base-files: automatically handle paths and symlinks for RAMFS_COPY_BIN")
Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com>
The image build code for the Ubiquiti Nanostation AC series adds the
factory image as to be build image. The same is already done by an
included recipe which results into an expanded IMAGE variable of:
IMAGES = sysupgrade.bin factory.bin factory.bin
The build system doesn't like these duplicates and issues the following
warning:
Makefile:82: warning: overriding recipe for target...
Get remove the duplicate factory image to get rid of the warning.
Fixes: 5736af8024 ("ath79: Add support for Ubiquiti NanoStation AC loco")
fa3c2676ab ("ath79: Add support for Ubiquiti Nanostation AC")
Signed-off-by: Mathias Kresin <dev@kresin.me>
Don't hijack the status led to indicate the wireless state. If we don't
have a dedicated wireless led, it's as simply as the wireless status
can't be indicated.
Such a led misuse should be set by the user and not shipped by default.
Signed-off-by: Mathias Kresin <dev@kresin.me>
Release the led used for boot status indication via devicetree instead
of setting a default off trigger in userspace.
Signed-off-by: Mathias Kresin <dev@kresin.me>
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>
