This is an automatically generated commit which aids following Kernel patch
history, as git will see the move and copy as a rename thus defeating the
purpose.
For the original discussion see:
https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
Signed-off-by: Martin Schiller <ms@dev.tdt.de>
Make the OF-compatible zImage per-board selectable. This allows the
image to only be built with the wrapper if the target actually uses it.
This fixes build-failures for the mpc85xx-p2020 subtarget.
Fixes: 557c094f0579 ("mpc85xx: only build zImage on required targets")
Signed-off-by: David Bauer <mail@david-bauer.net>
Set the appropriate cpu_port value based on the use of realtek,extif0 to extif2
instead of the additional cpu_port parameter.
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Link: https://github.com/openwrt/openwrt/pull/15033
Signed-off-by: Robert Marko <robimarko@gmail.com>
Set the appropriate cpu_port value based on the use of realtek,extif0 or realtek,extif1 parameter.
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Link: https://github.com/openwrt/openwrt/pull/15033
Signed-off-by: Robert Marko <robimarko@gmail.com>
Update to the latest upstream release to include recent improvements and
bugfixes, and simplify use of PKG_SOURCE_VERSION.
Link: https://github.com/libbpf/libbpf/releases/tag/v1.4.3
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
Add two patches to fix compile errors being repeatedly seen on OpenWrt CI.
The first is an upstream backport to fix this i386-related error:
x86_64-openwrt-linux-musl-gcc -mcmodel=large -I./purgatory/include
-I./purgatory/arch/x86_64/include -I./util_lib/include -I./include -Iinclude
-I/builder/shared-workdir/build/sdk/staging_dir/toolchain-x86_64_gcc-13.3.0_musl/lib/gcc/x86_64-openwrt-linux-musl/13.3.0/include
-c -MD -o purgatory/arch/i386/entry32-16.o purgatory/arch/i386/entry32-16.S
purgatory/arch/i386/entry32-16.S: Assembler messages:
purgatory/arch/i386/entry32-16.S:23: Error: 64bit mode not supported on `i386'.
The second addresses an error using basename() on musl libc:
kexec/arch/i386/x86-linux-setup.c: In function 'add_edd_entry':
kexec/arch/i386/x86-linux-setup.c:332:20: warning: implicit declaration of function 'basename' [-Wimplicit-function-declaration]
332 | if (sscanf(basename(sysfs_name), "int13_dev%hhx", &devnum) != 1) {
| ^~~~~~~~
kexec/arch/i386/x86-linux-setup.c:332:20: warning: passing argument 1 of 'sscanf' makes pointer from integer without a cast [-Wint-conversion]
332 | if (sscanf(basename(sysfs_name), "int13_dev%hhx", &devnum) != 1) {
| ^~~~~~~~~~~~~~~~~~~~
| |
| int
...
Fixes: #14621
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
This reverts commit 17d8c5825e.
This commit is breaking init somehow, even the hostname is not set,
so until its fixed, revert it.
Signed-off-by: Robert Marko <robimarko@gmail.com>
All NETGEAR EX6150v2 validate the rootfs for which OpenWrt places a
fakeheader at the position, where the bootloader expects it.
Some EX6150v2 bootloaders do however make a broken assumption about
where the rootfs starts. This is due to them calculating the rootfs
start not based upon the kernel-length but the string-offset of the
FIT-image.
We have to be compatible with both this broken as well as the valid
calculation. So we do relocate the FDT string section to a
block-boundary and enlarge the FIT image to end at this boundary +
BLOCKSIZE / 2. This way, both the broken as well as correct calculations
do expect the rootfs-header at the same position.
It is worth noting, that this is a rare edge-case in which only happens
if the image-length as well as the start of the string-section are not
placed in the same erase-block. This is an edge-case which happens very
rarely (thus it was not spotted prior).
Affected:
- U-Boot 2012.07 (Jun 16 2016 - 11:59:37)
Signed-off-by: David Bauer <mail@david-bauer.net>
(cherry picked from commit 8f9546f7b0a14f3afa813e39ed45c968ece24464)
When running unit tests this causes trouble since `/lib/config/uci.sh`
isn't available in those cases. Instead exit with a clean status fo the
unit test framework don't wrongly interpret things as an error.
Signed-off-by: Paul Spooren <mail@aparcar.org>
The recently added D-Link DNS-320L and the Zyxel NSA310S
is missing an RTC module so let's give them the default
Marvell RTC at least.
Reviewed-by: Robert Marko <robimarko@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The gpio is actually low active, fix it.
Fixes: 40e7fab9e4 ("mediatek: add Nokia EA0326GMP support")
Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
Link: https://github.com/openwrt/openwrt/pull/15651
Signed-off-by: Robert Marko <robimarko@gmail.com>
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.
Per the CycloneDX 1.4 spec, the `metadata.timestamp` field contains
the date/time when the BOM was created [1].
Before the change, the value generated by the package-metadata.pl
script would look like this:
2024-06-03T15:51:10
CycloneDX 1.4 relies on the JSON Schema specification version draft-07,
which defines the `date-time` format [2] as derived from RFC 3339,
section 5.6 [3]. In this format, the `time-offset` component is required,
however in the original version of package-metadata.pl it is omitted.
This is causing problems with OWASP Dependency-Track version 4.11.0 or
newer, where it now validates submitted SBOMs against the JSON schema
by default [4]. SBOMs with incorrect timestamp values are rejected with
the following error:
{
"detail": "Schema validation failed",
"errors": [
"$.metadata.timestamp: 2024-06-03T15:51:10 is an invalid date-time"
],
"status": 400,
"title": "The uploaded BOM is invalid"
}
Add explicit `Z` (UTC) timezone offset in the `timestamp` field
to satisfy the CycloneDX schema.
[1]: https://github.com/CycloneDX/specification/blob/1.4/schema/bom-1.4.schema.json#L116-L121
[2]: https://json-schema.org/draft-07/draft-handrews-json-schema-validation-01#rfc.section.7.3.1
[3]: https://datatracker.ietf.org/doc/html/rfc3339#section-5.6
[4]: https://github.com/DependencyTrack/dependency-track/pull/3522
Signed-off-by: Roman Azarenko <roman.azarenko@iopsys.eu>
containing fixes around tar and internal checksums.
Signed-off-by: Paul Spooren <mail@aparcar.org>
Link: https://github.com/openwrt/openwrt/pull/15646
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
The IMX device-tree's for arm moved from arch/arm/boot/dts to
arch/arm/boot/dts/nxp/imx. Use that if using the 6.6 kernel.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
copy 6.1 patches to 6.6 and fixup:
- removed patches already upstream
- adapted pathnames of dts patches for new kernel
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Commit ae8bf1a26e ("imx: add imx8m support") configured the
drm-imx-ldb kmod for imx_cortexa9 and imx_cortexa7 however it is only
applicable to imx_cortexa9 (imx6).
Fix this so that we can avoid a missing module config for cortexa7 when
moving to the 6.6 kernel.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Patch 733-01-net-ethernet-mtk_eth_soc-use-napi_build_skb.patch needs
a refresh as line numbers no longer match.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
For the first-time installation (mostly migrates from vendor firmware)
the ubiblock is not ready, but bootdev detection relies on it. This
means users must create ubiblock manually otherwise the sysupgrade
will not work.
Now a unique case is added for nand devices which use new fit format,
let's move to it.
Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
Hardware specification:
SoC: MediaTek MT7981B 2x A53
Flash: 128 MB SPI-NAND
RAM: 256MB
Ethernet: 4x 10/100/1000 Mbps
Switch: MediaTek MT7531AE
WiFi: MediaTek MT7976C
Button: Reset, WPS/Mesh
Power: DC 12V 1A
Gain SSH access:
1. Login into web interface, and download the configuration.
2. Download the configration utilities:
https://firmware.download.immortalwrt.eu.org/cnsztl/mediatek/filogic/openwrt-mediatek-mt7981-nokia-ea0326gmp-config-utils.tar.gz
These binaries are extraced from the factory firmware, which are
dynamically linked with aarch64 musl 1.1.24. To use them, you
must run them under the same runtime environment, otherwise the
binaries will not work properly!
3. Upload the configuration and utilities to a suitable environment.
4. Uncompress the utilities, move them to '/bin' and give them executable permisison:
tar -zxf openwrt-mediatek-mt7981-nokia-ea0326gmp-config-utils.tar.gz
mv mkconfig seama /bin
chmod +x /bin/mkconfig
chmod +x /bin/seama
5. Decrypt and uncompress the configuration:
Enter fakeroot if you are not login as root.
mkconfig -a de-enca -m EA0326GMP_3FE79221BAAA -i EA0326GMP_3FE79221BAAA-xxxxxxxx-backup.tar.gz -o backup.tar.gz
tar -zxf backup.tar.gz
6. Edit 'etc/config/dropbear', set 'enable' to '1'.
7. Edit 'etc/passwd', remove root password: 'root::1:0:99999:7:::'.
8. Repack the configuration:
tar -zcf backup.tar.gz etc/
mkconfig -a enca -m EA0326GMP_3FE79221BAAA -i backup.tar.gz -o EA0326GMP_3FE79221BAAA-xxxxxxxx-backup.tar.gz
9. Upload new configuration via web interface, now you can SSH to EA0326GMP.
A minimum configuration which enabled SSH access is also provided
to simplify the process:
https://firmware.download.immortalwrt.eu.org/cnsztl/mediatek/filogic/openwrt-mediatek-mt7981-nokia-ea0326gmp-enable-ssh.tar.gz
Flash instructions:
1. SSH to EA0326GMP, backup everything, especially 'Factory' part.
2. Write new BL2:
mtd write openwrt-mediatek-filogic-nokia_ea0326gmp-preloader.bin BL2
3. Write new FIP:
mtd write openwrt-mediatek-filogic-nokia_ea0326gmp-bl31-uboot.fip FIP
4. Set static IP on your PC:
IP 192.168.1.254/24, GW 192.168.1.1
5. Serve OpenWrt initramfs image using TFTP server.
6. Cut off the power and re-engage, wait for TFTP recovery to complete.
7. After OpenWrt has booted, perform sysupgrade.
Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
Prior to performing a PROGRAM LOAD RANDOM DATA operation, a WRITE
ENABLE (06h) command must be issued to change the contents of the
memory array. Following a WRITE ENABLE (06) command, **first a PROGRAM
LOAD (02h or 32h) command must be issued to reset the cache**, then
issue a PROGRAM LOAD RANDOM DATA (84h or 34h) command
This is dirty fix provided to use by MediaTek engineer Sky Huang which
may resolve the "OpenWrt Kiss of Death" issue we've been seeing on the
Linksys E8450 aka. Belkin RT3200. However, it means that everything has
to be re-written with that patch already applied, ie. we need to rebuild
the installer once it is part of snapshot builds to have any effect.
Users already on FIP-in-UBI layout are advised to re-write 'fip' UBI
volume and 'bl2' MTD partition manually once from within Linux after
this fix has been applied.
A similar fix will also be required for U-Boot.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Dont allow x2 read and cache read operations on FM35Q1GA as they seem
to be unstable. Also the Linux drivers does not allow x2 ops.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Import pending patches to set pinconf settings for SPI-NAND pins on
MT7622 identical to what the old proprietary preloader did.
Should further increase the reliability of some SNFI-attached SPI-NAND
flash chips.
Link: https://github.com/mtk-openwrt/arm-trusted-firmware/pull/7
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Update ARM TrustedFirmware-A to the most recent release of
MediaTek downstream patched version released 2024-01-17.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Buffalo WSR-2533DHPL2 is a 2.4/5 GHz band 11ac (Wi-Fi 5) router, based
on MediaTek MT7621A.
Specification:
- SoC : MediaTek MT7621AT
- RAM : DDR3 128 MiB (Winbond W631GG6MB12J)
- Flash : RAW-NAND 128 MiB (Winbond W29N01HVSINF)
- WLAN : 2.4/5 GHz (2x MediaTek MT7615N)
- Ethernet : 10/100/1000 Mbps x4
- Switch : MediaTek MT7530 (SoC)
- LED/keys : 8x/6x (2x buttons, 1x slide-switch)
- UART : through-hole on PCB (J4)
- arrangement : 3.3V, GND, TX, RX from triangle-mark
- settings : 57600n8
- Power : 12VDC 1.5A
Flash instruction using factory.bin image:
1. boot WSR-2533DHPL2 normally with "Router" mode
2. access to the WebI ("http://192.168.11.1/") on the device and open
firmware update page
("管理" -> "ファームウェア更新")
3. select the OpenWrt factory.bin image and click update ("更新実行")
button
Attention: do not use "factory-uboot.bin" image
4. Wait ~120 seconds to complete flashing
Flash instruction using initramfs image:
1. prepare the TFTP server with the initramfs image renamed to
"linux.trx-recovery" and IP address "192.168.11.2"
2. press the "AOSS" button while powering on the WSR-2533DHPL2
3. after 10 seconds, release the "AOSS" button, WSR-2533DHPL2 downloads
the initramfs image and boot with it automatically
4. on the initramfs image, download the factory-uboot.bin image to the
device and perform sysupgrade with it and "-F" option
5. wait ~120 seconds to complete flashing
Notes:
- There are 2x factory*.bin images for different purposes.
- factory.bin : for flashing on OEM WebUI
- factory-uboot.bin: for flashing on OEM bootloader or initramfs image
factory-uboot.bin is useful for recoverying the device, or refreshing
when the kernel partition is expanded in the future. sysupgrade on
this device accepts factory-uboot.bin with option "-F", but on that
situation, user configurations won't be kept, so it's not for normal
use.
MAC addresses:
LAN : 18:EC:E7:xx:xx:E0 (board_data, "mac" (text))
WAN : 18:EC:E7:xx:xx:E0 (board_data, "mac" (text))
2.4 GHz: 18:EC:E7:xx:xx:E1 (Factory, 0x4 (hex))
5 GHz : 18:EC:E7:xx:xx:E4 (Factory, 0x8004 (hex))
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
Buffalo WSR-2533DHPLS is a 2.4/5 GHz band 11ac router, based on MediaTek
MT7621A.
Very similar to Buffalo WSR-2533DHPL, but with NAND, different GPIO
and TRX partitions.
Specification:
- SoC : MediaTek MT7621AT
- RAM : DDR3 256 MiB (Samsung K4B2G1646F-BYMA)
- Flash : RAW-NAND 128 MiB
(Winbond W29N01HV or KIOXIA TC58BVG0S3HTAI0)
- WLAN : 2.4/5 GHz (2x MediaTek MT7615N)
- Ethernet : 10/100/1000 Mbps
- Switch : MediaTek MT7530 (SoC) 4 ports
- LED/keys : 8x/6x (2x buttons, 1x slide-switch)
- UART : through-hole on PCB (J4)
- arrangement : 3.3V, GND, TX, RX from triangle-mark
- settings : 115200n8
- Power : 12VDC 1.5A
Flash instruction using factory.bin image:
1. boot WSR-2533DHPLS normally with "Router" mode
2. access to the WebI ("http://192.168.11.1/") on the device and open
firmware update page
("管理" -> "ファームウェア更新")
3. select the OpenWrt factory.bin image and click update ("更新実行")
button
Attention: do not use "factory-uboot.bin" image
4. Wait ~120 seconds to complete flashing
Flash instruction using initramfs image:
1. prepare the TFTP server with the initramfs image renamed to
"linux.trx-recovery" and IP address "192.168.11.2"
2. press the "AOSS" button while powering on the WSR-2533DHPLS
3. after 10 seconds, release the "AOSS" button, WSR-2533DHPLS downloads
the initramfs image and boot with it automatically
4. on the initramfs image, download the factory-uboot.bin image to the
device and perform sysupgrade with it and "-F" option
5. wait ~120 seconds to complete flashing
Notes:
- The embedded addresses in eeprom data in Factory partition have
Buffalo's OUI, but they don't match with the actual addresses
assigned to wlan devices. So fixup addresses by the user-space
script.
root@localhost:/# hexdump -C /dev/mtdblock3 | grep "^0000[08]000\s"
00000000 15 76 a0 00 88 57 ee bc 01 a8 15 76 c3 14 00 80 |.v...W.....v....|
00008000 15 76 a0 00 88 57 ee bc 01 f8 15 76 c3 14 00 80 |.v...W.....v....|
See "MAC addresses" below for actual addresses.
- There are 2x factory*.bin images for different purposes.
- factory.bin : for flashing on OEM WebUI
- factory-uboot.bin: for flashing on OEM bootloader or initramfs image
factory-uboot.bin is useful for recoverying the device, or refreshing
when the kernel partition is expanded in the future. sysupgrade on
this device accepts factory-uboot.bin with option "-F", but on that
situation, user configurations won't be kept, so it's not for normal
use.
MAC addresses:
LAN : 90:96:F3:xx:xx:30 (board_data, "mac" (text))
WAN : 90:96:F3:xx:xx:30 (board_data, "mac" (text))
2.4 GHz: 90:96:F3:xx:xx:31
5 GHz : 90:96:F3:xx:xx:38
[original work]
Signed-off-by: Audun-Marius Gangstø <audun@gangsto.org>
[convert to ubi, fix/improve DT, add sysupgrade support]
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
Switch trx parser to parser_trx of Linux Kernel from mtdsplit_trx to
split firmware partition using model-specific trx magic number on
some Buffalo devices.
This change is tested on Buffalo WSR-2533DHPL.
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
Move Build/buffalo-trx to image-commands.mk from image/mt7622.mk to use
that definition from ramips as well.
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
Enable trx feature of mtd command to fixup trx length and crc32 while
booting for some Buffalo devices.
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
This pull request ports Ruijie RG-X60 Pro router support to the main branch.
Parameters:
- SoC : MediaTek MT7986A Quad-core ARM Cortex-A53 2.0GHz
- RAM : DDR3 512MiB (W634GU6QB)
- Flash : SPI-NAND 128 MiB (W25N01GVZEIG)
- WLAN : MediaTek MT7986A integration dual-band WiFi 6
- 2.4 GHz : b/g/n/ax, MIMO 4x4
- 5 GHz : a/n/ac/ax, MIMO 4x4
- Ethernet : 10/100/1000 Mbps x4 (MediaTek MT7531AE)
2500Mbps x 1 (Realtek RTL8221B-VB-CG)
- UART : through-hole on PCB
- [J500] GND, TX, RX, 3.3V (115200n1)
- Buttons : Mesh, Reset
- LEDs : 1x Power (Blue)
1x Turbo (Purple)
- Power : 12 VDC, 3 A
How to Installation:
1. Remove the case and connect the TTL cable to the corresponding position.
2. Power on the device and quickly press "down" on the keyboard, then
U-Boot will stay in the menu.
3. Select "1. Upgrade Firmware", select "0. TFTP Client(Default)".
4. Input the IP address, input the Openwrt image file name to be
flashed, start the TFTP server, and press "Enter".
5. Wait for the flashing to complete.
How return to stock:
1. Remove the case and connect the TTL cable to the corresponding
position.
2. Power on the device and quickly press "down" on the keyboard, then
U-Boot will stay in the menu.
3. Select "1. Upgrade Firmware", select "0. TFTP Client(Default)".
4. Input the IP address, input the Stock “E-WEBOS” image file name to
be flashed, start the TFTP server, and press "Enter".
5. Wait for the flashing to complete.
About recovery:
Connect uart, use u-boot menu to flash stock firmware image or boot
OpenWrt initramfs image.
About MAC Address:
+---------+-------------------+-----------+
| | MAC | Algorithm |
+---------+-------------------+-----------+
| WAN | 10:82:3D:XX:XX:9E | label |
| LAN | 10:82:3D:XX:XX:9F | label+1 |
| WLAN 2g | 10:82:3D:XX:XX:A0 | label+2 |
| WLAN 5g | 10:82:3D:XX:XX:A1 | label+3 |
+---------+-------------------+-----------+
Signed-off-by: Ashley Lee <code@emtips.net>
Use the same Yafut code revision for both updating devices with NAND
flash and preparing firmware images for devices with NOR flash.
Signed-off-by: Michał Kępień <openwrt@kempniu.pl>
Link: https://github.com/openwrt/openwrt/pull/13453
Signed-off-by: Robert Marko <robimarko@gmail.com>
Since the Yafut tool is now used for both updating the kernel on
MikroTik devices with NAND flash and preparing firmware images for
MikroTik devices with NOR flash, remove the kernel2minor utility from
the tree as it is no longer used for anything.
Signed-off-by: Michał Kępień <openwrt@kempniu.pl>
Link: https://github.com/openwrt/openwrt/pull/13453
Signed-off-by: Robert Marko <robimarko@gmail.com>
The Yafut tool now has limited capabilities for working on filesystem
images stored in regular files. This enables preparing Yaffs2 images
for devices with NOR flash using upstream Yaffs2 filesystem code instead
of the custom kernel2minor tool.
Since minimizing the size of the resulting filesystem image size is
important and upstream Yaffs2 code requires two allocator reserve blocks
to be available when writing a file to the filesystem, a trick is
employed while preparing an OpenWRT image: the blank filesystem image
that Yafut operates on initially contains two extra erase blocks that
are chopped off after the kernel file is written. This is safe to do
because Yaffs2 has a true log structure and therefore only ever writes
sequentially (and the size of the kernel file is known beforehand).
While the two extra erase blocks are necessary for writes, Yaffs2 code
seems to be perfectly capable of reading back files from a "truncated"
filesystem that does not contain these extra erase blocks.
In terms of image size, this new approach is only marginally worse than
the current kernel2minor-based one: specifically, upstream Yaffs2 code
needs to write three object headers (each of which takes up an entire
data chunk) when the kernel file is written to the filesystem:
- an object header for the kernel file when it is created,
- an object header for the root directory when the kernel file is
created,
- an updated object header for the kernel file when the latter is
fully written (so that its new size can be recorded).
kernel2minor only writes two of these headers, which is the absolute
minimum required for reading the file back. This means that the
Yafut-based approach causes firmware images to be at most one erase
block (64 kB) larger than those created using kernel2minor, but only in
the very unfortunate scenario where the size of the kernel file is
really close to a multiple of the erase block size.
The rest of the calculations performed when the empty filesystem image
is first prepared stems from the Yaffs2 layout used by MikroTik NOR
devices: each 65,536-byte erase block contains 63 chunks, each of which
consists of 1024 bytes of data followed by 16-byte Yaffs tags without
ECC data; each such group of 63 chunks is then followed by 16 bytes of
padding, which translates to "-C 1040 -B 64k -E" in the Yafut
invocation. Yaffs2 checkpoints and summaries are disabled (using
Yafut's -P and -S switches, respectively) as they are merely performance
optimizations that require extra storage space. The -L and -M switches
are used to force little-endian or big-endian byte order (respectively)
in the resulting filesystem image, no matter what byte order the build
host uses. The tr invocation is used to ensure that the filesystem
image is initialized with 0xFF bytes (which are an indicator of unused
space for Yaffs2 code).
Signed-off-by: Michał Kępień <openwrt@kempniu.pl>
Link: https://github.com/openwrt/openwrt/pull/13453
Signed-off-by: Robert Marko <robimarko@gmail.com>
The Yafut tool has so far been used to update the kernel on devices with
NAND flash via MTD character devices. Recent upstream updates extended
the tool with limited support for working with filesystem images stored
in regular files. This enables Yafut to be used for preparing a Yaffs
filesystem image for a device with NOR flash on a build host and
subsequently flashing it to the target device without using Yafut
itself.
Add Yafut to tools/ so that it can be compiled and run on the host
building OpenWRT.
Signed-off-by: Michał Kępień <openwrt@kempniu.pl>
Link: https://github.com/openwrt/openwrt/pull/13453
Signed-off-by: Robert Marko <robimarko@gmail.com>
Instead of extracting WiFi precal as well as MAC addresses in userspace
use recently introduced NVMEM-on-UBI instead.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Tested-by: Christian Lamparter <chunkeey@gmail.com>
