Birger Koblitz [Thu, 21 Jan 2021 13:11:35 +0000 (14:11 +0100)]
realtek: add support for the RTL8390 and RTL9300 SoC IRQs
This adds support for the RTL8390 and RTL9300 SoCs
it also cleans up unnecessary definitions in mach-rtl83xx.h
and moves definitions relevant for irq routing to irq.h
Append a device specific version trailer used by the stock
firmware upgrade application to validate firmwares.
The trailer contains a list of ZyXEL firmware version
numbers, which includes a four letter hardware identifier.
The stock web UI requires that the current hardware matches
one of the listed versions, and that the version number is
larger than a model specific minimum value. The minimum
version varies between V1.00 and V2.60 for the currently
known GS1900 models. The number is not used anywhere else
to our knowlege, and has no direct relation to the version
info in the u-image header. We can therefore use an
arbitrary value larger than V2.60.
The stock firmware upgrade application will only load and
flash the part of the file specified in the u-image header,
regardless of file size. It can therefore not be used to
flash images with an appended rootfs. There is therefore no
need to include the trailer in other images than the
initramfs. This prevents accidentally bricking by attempts
to flash other images from the stock web UI.
Stock images support all models in the series, listing
all of them in the version trailer. OpenWrt provide model
specific images. We therefore only list the single supported
hardware identifier for each image. This eliminates the risk
of flashing the wrong OpenWrt image from stock web UI.
OpenWrt can be installed from stock firmware in two steps:
1) flash OpenWrt initramfs image from stock web gui
2) boot OpenWrt and sysupgrade to a squasfs image
The OpenWrt squashfs image depends on a static partition
map in the DTS. It can only be installed to the "firmware"
partition. This partition is labeled "RUNTIME1" in u-boot
and in stock firmware, and is referred to as "image 0" in
the stock flash management tool. The OpenWrt initramfs
can be installed and run from either partitions. But if
you want to keep stock irmware in the spare system partition,
then you must make sure stock firmware is installed to the
"RUNTIME2" partition referred to as "image 1" in the stock
web UI. And the initial OpenWrt initramfs must be flashed
to "RUNTIME1"/"image 0".
The stock flash management application supports direct
selection of both which partition to flash and which
partition to boot next. This allows software controlled
"dual-boot" between OpenWrt and stock firmware, without
using console access to u-boot. u-boot use the "bootpartition"
variable stored in the second u-boot environment to select
which of the two system partitions to boot. This variable
is set by the stock flash management application, by direct
user input. It can also be set in OpenWrt using e.g
fw_setsys bootpartition 1
to select "RUNTIME2"/"image 1" as default, assuming a
stock firmware version is installed in that partition.
Bjørn Mork [Sat, 23 Jan 2021 10:08:11 +0000 (11:08 +0100)]
realtek: use vendor-specific magic for ZyXEL
The stock firmware of the ZyXEL GS1900 series use a non-standard
u-image magic. This is not enforced by the stock u-boot, which is
why we could boot images with the default magic. The flash
management application of the stock firmware will however verify
the magic, and refuse any image with another value.
Convert to vendor-specific value to get flash management support
in stock firmware, including the ability to upgrade to OpenWrt
directly from stock web UI.
dnsmasq v2.83 has a bug in handling duplicate queries which means it may
try to reply using the incorrect network socket. This is especially
noticeable in dual stack environments where replies may be mis-directed to
IPv4 addresses on an IPv6 socket or IPv6 addresses on an IPv4 socket.
This results in system log spam such as:
dnsmasq[16020]: failed to send packet: Network unreachable
dnsmasq[16020]: failed to send packet: Address family not supported by protocol
dnsmasq v2.84test3 resolves these issues.
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
x86 uses append-metadata, but only for signing and not for the
metadata itself.
Since recently SUPPORTED_DEVICES was assigned with a global value
and is not empty anymore, append-metadata will now actually put
metadata into x86 images. This breaks sysupgrade on x86.
To fix it for the moment, let's just empty SUPPORTED_DEVICES for
this target again.
In the long term, one should either not add metadata to the images
if it is not desired, and/or remove the unintended fwtool check.
Fixes: f52081bcf938 ("treewide: provide global default for SUPPORTED_DEVICES") Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
MAC addresses are labeled as ETH, 2.4G, and 5GHz
Only one Vendor MAC address in flash
eth0 ETH *:a2 art 0x0
phy1 2.4G *:a3 ---
phy0 5GHz *:a4 ---
**Serial Access:**
the RX line on the board for UART is shorted to ground by resistor R176
therefore it must be removed to use the console
but it is not necessary to remove to view boot log
optionally, R175 can be replaced with a solder bridge short
the resistors R175 and R176 are next to the UART RX pin at J10
**Installation:**
2 ways to flash factory.bin from OEM:
Method 1: Firmware upgrade page:
OEM webpage at 192.168.1.1
username and password "admin"
Navigate to "Firmware Upgrade" page from left pane
Click Browse and select the factory.bin image
Upload and verify checksum
Click Continue to confirm and wait 3 minutes
Method 2: Serial to load Failsafe webpage:
After connecting to serial console and rebooting...
Interrupt uboot with any key pressed rapidly
execute `run failsafe_boot` OR `bootm 0x9fd70000`
wait a minute
connect to ethernet and navigate to
"192.168.1.1/index.htm"
Select the factory.bin image and upload
wait about 3 minutes
**Return to OEM:**
If you have a serial cable, see Serial Failsafe instructions
otherwise, uboot-env can be used to make uboot load the failsafe image
*DISCLAIMER*
The Failsafe image is unique to Engenius boards.
If the failsafe image is missing or damaged this will brick the device
DO NOT downgrade to ar71xx this way, it can cause kernel loop or halt
ssh into openwrt and run
`fw_setenv rootfs_checksum 0`
reboot, wait 3 minutes
connect to ethernet and navigate to 192.168.1.1/index.htm
select OEM firmware image from Engenius and click upgrade
**TFTP recovery:**
Requires serial console, reset button does nothing
rename initramfs to 'vmlinux-art-ramdisk'
make available on TFTP server at 192.168.1.101
power board, interrupt boot
execute tftpboot and bootm 0x81000000
NOTE: TFTP is not reliable due to bugged bootloader
set MTU to 600 and try many times
**Format of OEM firmware image:**
The OEM software of EAP1200H is a heavily modified version
of Openwrt Kamikaze. One of the many modifications
is to the sysupgrade program. Image verification is performed
simply by the successful ungzip and untar of the supplied file
and name check and header verification of the resulting contents.
To form a factory.bin that is accepted by OEM Openwrt build,
the kernel and rootfs must have specific names...
and begin with the respective headers (uImage, squashfs).
Then the files must be tarballed and gzipped.
The resulting binary is actually a tar.gz file in disguise.
This can be verified by using binwalk on the OEM firmware images,
ungzipping then untaring.
Newer EnGenius software requires more checks but their script
includes a way to skip them, otherwise the tar must include
a text file with the version and md5sums in a deprecated format.
The OEM upgrade script is at /etc/fwupgrade.sh.
OKLI kernel loader is required because the OEM software
expects the kernel to be no greater than 1536k
and the factory.bin upgrade procedure would otherwise
overwrite part of the kernel when writing rootfs.
Note on PLL-data cells:
The default PLL register values will not work
because of the external AR8035 switch between
the SOC and the ethernet port.
For QCA955x series, the PLL registers for eth0 and eth1
can be see in the DTSI as 0x28 and 0x48 respectively.
Therefore the PLL registers can be read from uboot
for each link speed after attempting tftpboot
or another network action using that link speed
with `md 0x18050028 1` and `md 0x18050048 1`.
The clock delay required for RGMII can be applied
at the PHY side, using the at803x driver `phy-mode`.
Therefore the PLL registers for GMAC0
do not need the bits for delay on the MAC side.
This is possible due to fixes in at803x driver
since Linux 5.1 and 5.3
treewide: provide global default for SUPPORTED_DEVICES
The majority of our targets provide a default value for the variable
SUPPORTED_DEVICES, which is used in images to check against the
compatible on a running device:
SUPPORTED_DEVICES := $(subst _,$(comma),$(1))
At the moment, this is implemented in the Device/Default block of
the individual targets or even subtargets. However, since we
standardized device names and compatible in the recent past, almost
all targets are following the same scheme now:
The equal redundant definitions are a symptom of this process.
Consequently, this patch moves the definition to image.mk making it
a global default. For the few targets not using the scheme above,
SUPPORTED_DEVICES will be defined to a different value in
Device/Default anyway, overwriting the default. In other words:
This change is supposed to be cosmetic.
This can be used as a global measure to get the current compatible
with: $(firstword $(SUPPORTED_DEVICES))
(Though this is not precisely an achievement of this commit.)
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Paul Spooren [Sat, 2 Jan 2021 00:18:32 +0000 (14:18 -1000)]
base-files: use $(COMMITCOUNT) in PKG_RELEASE
The newly added `$(COMMITCOUNT)` varialbe allows automatic versioning
based on the number of Git commits of a package. Replace *tedious to
bump* and *merge conflict causing* `PKG_RELEASE` and replace it with
`$(COMMITCOUNT)`.
Paul Spooren [Sat, 2 Jan 2021 00:02:12 +0000 (14:02 -1000)]
rules: add AUTORELEASE and COMMITCOUNT variables
The lack of bumped PKG_RELEASE variables is a recurring theme on the
mailing list and in GitHub comments. This costs precious review time,
a rare good within the OpenWrt project.
Instead of relying on a manually set PKG_RELEASE this commit adds a
`commitcount` function that uses the number of Git commits to determine
the release. The function is called via the variables `$(AUTORELEASE)`
or `$(COMMITCOUNT)`. The `PKG_RELEASE` variable can be set to either of
the two.
- $(AUTORELEASE):
Release is automagically set to the number of commits since the last
commit containing either ": update to " or ": bump to ".
Bjørn Mork [Wed, 20 Jan 2021 17:36:52 +0000 (18:36 +0100)]
kernel: mtdsplit_uimage: add "openwrt, offset" and "openwrt, partition-magic"
Some devices prepend a standard U-Boot Image with a vendor specific
header, having its own magic. Adding two new properties will support
validation of such images, including the additional magic.
The only difference between the "openwrt,okli" and the generic
parser is the magic. Set this in device tree for all affected
devices and remove the "openwrt,okli" parser.
Tested-by: Michael Pratt <mcpratt@protonmail.com> # EAP300 v2, ENS202EXT and ENH202 Signed-off-by: Bjørn Mork <bjorn@mork.no>
Rafał Miłecki [Wed, 20 Jan 2021 15:49:26 +0000 (16:49 +0100)]
kernel: add parser finding rootfs after CFE bootfs
It's required for BCM4908. It cannot use "bcm-wfi-fw" parser because
that one requires *two* JFFS2 partitions which is untested / unsupported
on the BCM4908 architecture. With a single JFFS2 partition "bcm-wfi-fw"
parser will:
1. Fail to find "vmlinux.lz" as it doesn't follow "1-openwrt" file
2. Create partitions that don't precisely match bootfs layout
The new parser is described in details in the MTD_SPLIT_CFE_BOOTFS
symbol help message.
Rafał Miłecki [Thu, 21 Jan 2021 12:04:45 +0000 (13:04 +0100)]
firmware-utils: bcm4908asus: tool inserting Asus tail into BCM4908 image
Asus looks for an extra data at the end of BCM4908 image, right before
the BCM4908 tail. It needs to be properly filled to make Asus accept
firmware image.
This tool constructs such a tail, writes it and updates CRC32 in BCM4908
tail accordingly.
Sync ethernet driver code with upstream Linux kernel:
-Reduce xmit_more code changes.
-Combine rx cleanup code into a function.
-Convert to build_skb.
-Improve rx loop by optimizing loop tracking.
https://lore.kernel.org/netdev/20210106144208.1935-1-liew.s.piaw@gmail.com/ Signed-off-by: Sieng Piaw Liew <liew.s.piaw@gmail.com>
[Amend commit description, move patches to the top since they are going to be
upstreamed] Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Hamming ECC devices do not cover OOB data, as opposed to BCH ECC devices.
Therefore, disabling ECC for all devices is preventing BCH devices from
correctly reading and writing the OOB data.
UART Serial
[o] TX
[o] GND
[o] RX
[ ] VCC - Do not connect it
MAC addresses as verified by OEM firmware:
use address source
LAN *:c2 factory 0xe000 (label)
WAN *:c3 factory 0xe006
2g *:c4 factory 0x0000
5g *:c5 factory 0x8000
Flashing instructions:
1.Create a simple http server (nginx etc)
2.set uart enable
To enable writing to the console, you must reset to factory settings
Then you see uboot boot, press the keyboard 4 button (enter uboot command line)
If it is not successful, repeat the above operation of restoring the factory settings.
After entering the uboot command line, type:
setenv uart_en 1
saveenv
boot
3.use shell in uart
cd /tmp
wget http://"your_computer_ip:80"/openwrt-ramips-mt7621-xiaomi_mir4-squashfs-kernel1.bin
wget http://"your_computer_ip:80"/openwrt-ramips-mt7621-xiaomi_mir4-squashfs-rootfs0.bin
mtd write openwrt-ramips-mt7621-xiaomi_mir4-squashfs-kernel1.bin kernel1
mtd write openwrt-ramips-mt7621-xiaomi_mir4-squashfs-rootfs0.bin rootfs0
nvram set flag_try_sys1_failed=1
nvram commit
reboot
4.login to the router http://192.168.1.1/
Installation via Software exploit
Find the instructions in the https://github.com/acecilia/OpenWRTInvasion
Signed-off-by: Dmytro Oz <sequentiality@gmail.com>
[commit message facelift, rebase onto shared DTSI/common device
definition, bump uboot-envtools] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Robert Marko [Thu, 21 Jan 2021 12:08:57 +0000 (13:08 +0100)]
ipq40xx: fix boards being shown twice
Since generic images have been split to their own
Makefile boards are showing up twice in menuconfig
as $(eval $(call BuildImage)) was not dropped from
the new generic.mk.
Hence $(eval $(call BuildImage)) was being called
twice.
So, lets simply drop it from generic.mk.
Fixes: 378c7ff28210 ("ipq40xx: split generic images into own file") Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Rafał Miłecki [Thu, 21 Jan 2021 08:14:20 +0000 (09:14 +0100)]
bcm4908: set console in the CONFIG_CMDLINE
procd doesn't work with just serial specified in the DT (using chosen &
stdout-path). It requires tty device to be explicitly specified in the
cmdline.
Sven Eckelmann [Mon, 23 Nov 2020 12:41:34 +0000 (13:41 +0100)]
ath79: Add support for OpenMesh MR1750 v2
Device specifications:
======================
* Qualcomm/Atheros QCA9558 ver 1 rev 0
* 720/600/240 MHz (CPU/DDR/AHB)
* 128 MB of RAM
* 16 MB of SPI NOR flash
- 2x 7 MB available; but one of the 7 MB regions is the recovery image
* 3T3R 2.4 GHz Wi-Fi (11n)
* 3T3R 5 GHz Wi-Fi (11ac)
* 6x GPIO-LEDs (2x wifi, 2x status, 1x lan, 1x power)
* 1x GPIO-button (reset)
* external h/w watchdog (enabled by default))
* TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX)
* 1x ethernet
- AR8035 ethernet PHY (RGMII)
- 10/100/1000 Mbps Ethernet
- 802.3af POE
- used as LAN interface
* 12-24V 1A DC
* internal antennas
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
Sven Eckelmann [Mon, 23 Nov 2020 12:41:34 +0000 (13:41 +0100)]
ath79: Add support for OpenMesh MR1750 v1
Device specifications:
======================
* Qualcomm/Atheros QCA9558 ver 1 rev 0
* 720/600/240 MHz (CPU/DDR/AHB)
* 128 MB of RAM
* 16 MB of SPI NOR flash
- 2x 7 MB available; but one of the 7 MB regions is the recovery image
* 3T3R 2.4 GHz Wi-Fi (11n)
* 3T3R 5 GHz Wi-Fi (11ac)
* 6x GPIO-LEDs (2x wifi, 2x status, 1x lan, 1x power)
* 1x GPIO-button (reset)
* external h/w watchdog (enabled by default))
* TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX)
* 1x ethernet
- AR8035 ethernet PHY (RGMII)
- 10/100/1000 Mbps Ethernet
- 802.3af POE
- used as LAN interface
* 12-24V 1A DC
* internal antennas
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
The OpenMesh MR900 and to-be-added MR1750 family are very similar.
Make the existing MR900 DTSI more general so it can be used for
the MR1750 devices as well.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
ath79: consolidate common definitions for OpenMesh devices
The shared image definitions for OpenMesh devices are currently
organized based on device families. This introduces some duplicate
code, as the image creation code is mostly the same for those.
This patch thus derives two basic shared definitions that work for
all devices and only requires a few variables to be moved back to
the device definitions.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Sven Eckelmann [Wed, 30 Dec 2020 20:56:55 +0000 (21:56 +0100)]
ath79: apply Engenius ECB1750 style to OpenMesh MR900 RGMII cfg
The OpenMesh MR900 is a modified version of the Exx900/Exx1750 family.
These devices are shipped with an AR803x PHY and had various problems with
the delay configuration in ar71xx. These problems are now in the past [1]
and parts of the delay configuration should now be done in the PHY only.
Just switch to the configuration of the ECB1750 to have an already well
tested configuration for ath79 with the newer kernel versions.
Sven Eckelmann [Mon, 23 Nov 2020 12:41:34 +0000 (13:41 +0100)]
ath79: Add support for OpenMesh MR900 v2
Device specifications:
======================
* Qualcomm/Atheros QCA9558 ver 1 rev 0
* 720/600/240 MHz (CPU/DDR/AHB)
* 128 MB of RAM
* 16 MB of SPI NOR flash
- 2x 7 MB available; but one of the 7 MB regions is the recovery image
* 3T3R 2.4 GHz Wi-Fi
* 3T3R 5 GHz Wi-Fi
* 6x GPIO-LEDs (2x wifi, 2x status, 1x lan, 1x power)
* 1x GPIO-button (reset)
* external h/w watchdog (enabled by default))
* TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX)
* 1x ethernet
- AR8035 ethernet PHY (RGMII)
- 10/100/1000 Mbps Ethernet
- 802.3af POE
- used as LAN interface
* 12-24V 1A DC
* internal antennas
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
Sven Eckelmann [Mon, 23 Nov 2020 12:41:34 +0000 (13:41 +0100)]
ath79: Add support for OpenMesh MR900 v1
Device specifications:
======================
* Qualcomm/Atheros QCA9558 ver 1 rev 0
* 720/600/240 MHz (CPU/DDR/AHB)
* 128 MB of RAM
* 16 MB of SPI NOR flash
- 2x 7 MB available; but one of the 7 MB regions is the recovery image
* 3T3R 2.4 GHz Wi-Fi
* 3T3R 5 GHz Wi-Fi
* 6x GPIO-LEDs (2x wifi, 2x status, 1x lan, 1x power)
* 1x GPIO-button (reset)
* external h/w watchdog (enabled by default))
* TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX)
* 1x ethernet
- AR8035 ethernet PHY (RGMII)
- 10/100/1000 Mbps Ethernet
- 802.3af POE
- used as LAN interface
* 12-24V 1A DC
* internal antennas
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
Sven Eckelmann [Wed, 30 Dec 2020 20:56:55 +0000 (21:56 +0100)]
ath79: apply Engenius EAP600 style to OpenMesh MR600 RGMII cfg
The OpenMesh MR600 is a modified version of the EAP600 family. These
devices are shipped with an AR803x PHY and had various problems with the
delay configuration in ar71xx. These problems are now in the past [1] and
parts of the delay configuration should now be done in the PHY only.
Just switch to the configuration of the EAP600 to have an already well
tested configuration for ath79 with the newer kernel versions.
Sven Eckelmann [Mon, 23 Nov 2020 12:41:34 +0000 (13:41 +0100)]
ath79: Add support for OpenMesh MR600 v2
Device specifications:
======================
* Qualcomm/Atheros AR9344 rev 2
* 560/450/225 MHz (CPU/DDR/AHB)
* 128 MB of RAM
* 16 MB of SPI NOR flash
- 2x 7 MB available; but one of the 7 MB regions is the recovery image
* 2T2R 2.4 GHz Wi-Fi
* 2T2R 5 GHz Wi-Fi
* 8x GPIO-LEDs (6x wifi, 1x wps, 1x power)
* 1x GPIO-button (reset)
* external h/w watchdog (enabled by default))
* TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX)
* 1x ethernet
- AR8035 ethernet PHY (RGMII)
- 10/100/1000 Mbps Ethernet
- 802.3af POE
- used as LAN interface
* 12-24V 1A DC
* internal antennas
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
Sven Eckelmann [Mon, 23 Nov 2020 12:41:34 +0000 (13:41 +0100)]
ath79: Add support for OpenMesh MR600 v1
Device specifications:
======================
* Qualcomm/Atheros AR9344 rev 2
* 560/450/225 MHz (CPU/DDR/AHB)
* 128 MB of RAM
* 16 MB of SPI NOR flash
- 2x 7 MB available; but one of the 7 MB regions is the recovery image
* 2T2R 2.4 GHz Wi-Fi
* 2T2R 5 GHz Wi-Fi
* 4x GPIO-LEDs (2x wifi, 1x wps, 1x power)
* 1x GPIO-button (reset)
* TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX)
* 1x ethernet
- AR8035 ethernet PHY (RGMII)
- 10/100/1000 Mbps Ethernet
- 802.3af POE
- used as LAN interface
* 12-24V 1A DC
* internal antennas
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
Signed-off-by: Sven Eckelmann <sven@narfation.org>
[rebase, make WLAN LEDs consistent, add LED migration] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Hauke Mehrtens [Sun, 10 Jan 2021 23:33:07 +0000 (00:33 +0100)]
dnsmasq: Update to version 2.83
This fixes the following security problems in dnsmasq:
* CVE-2020-25681:
Dnsmasq versions before 2.83 is susceptible to a heap-based buffer
overflow in sort_rrset() when DNSSEC is used. This can allow a remote
attacker to write arbitrary data into target device's memory that can
lead to memory corruption and other unexpected behaviors on the target
device.
* CVE-2020-25682:
Dnsmasq versions before 2.83 is susceptible to buffer overflow in
extract_name() function due to missing length check, when DNSSEC is
enabled. This can allow a remote attacker to cause memory corruption
on the target device.
* CVE-2020-25683:
Dnsmasq version before 2.83 is susceptible to a heap-based buffer
overflow when DNSSEC is enabled. A remote attacker, who can create
valid DNS replies, could use this flaw to cause an overflow in a heap-
allocated memory. This flaw is caused by the lack of length checks in
rtc1035.c:extract_name(), which could be abused to make the code
execute memcpy() with a negative size in get_rdata() and cause a crash
in Dnsmasq, resulting in a Denial of Service.
* CVE-2020-25684:
A lack of proper address/port check implemented in Dnsmasq version <
2.83 reply_query function makes forging replies easier to an off-path
attacker.
* CVE-2020-25685:
A lack of query resource name (RRNAME) checks implemented in Dnsmasq's
versions before 2.83 reply_query function allows remote attackers to
spoof DNS traffic that can lead to DNS cache poisoning.
* CVE-2020-25686:
Multiple DNS query requests for the same resource name (RRNAME) by
Dnsmasq versions before 2.83 allows for remote attackers to spoof DNS
traffic, using a birthday attack (RFC 5452), that can lead to DNS
cache poisoning.
* CVE-2020-25687:
Dnsmasq versions before 2.83 is vulnerable to a heap-based buffer
overflow with large memcpy in sort_rrset() when DNSSEC is enabled. A
remote attacker, who can create valid DNS replies, could use this flaw
to cause an overflow in a heap-allocated memory. This flaw is caused
by the lack of length checks in rtc1035.c:extract_name(), which could
be abused to make the code execute memcpy() with a negative size in
sort_rrset() and cause a crash in dnsmasq, resulting in a Denial of
Service.
Hauke Mehrtens [Mon, 18 Jan 2021 20:57:10 +0000 (21:57 +0100)]
uboot-at91: Add PKG_MIRROR_HASH to fix download
The referenced commit is gone, but we already have this file on our
mirror, use that one by providing the correct mirror hash.
I generated a tar.xz file with the given git commit hash using a random
fork on github and it generated the same tar.xz file as found on our
mirror so this looks correct.
Hauke Mehrtens [Mon, 18 Jan 2021 20:57:05 +0000 (21:57 +0100)]
at91bootstrap: Add PKG_MIRROR_HASH to fix download
The referenced commit is gone, but we already have this file on our
mirror, use that one by providing the correct mirror hash.
I generated a tar.xz file with the given git commit hash using a random
fork on github and it generated the same tar.xz file as found on our
mirror so this looks correct.
David Bauer [Fri, 15 Jan 2021 01:15:12 +0000 (02:15 +0100)]
rockchip: use stable MAC-address for NanoPi R2S
The NanoPi R2S does not have a board specific MAC address written inside
e.g. an EEPROM, hence why it is randomly generated on first boot.
The issue with that however is the lack of a driver for the PRNG.
It often results to the same MAC address used on multiple boards by
default, as urngd is not active at this early stage resulting in low
available entropy.
There is however a semi-unique identifier available to us, which is the
CID of the used SD card. It is unique to each SD card, hence we can use
it to generate the MAC address used for LAN and WAN.
This enables the MikroTik platform driver, it enables us to parse
valuable info from hard_config including WLAN calibration data
extraction from sysfs.
If the watchdog is enabled, set the timeout to 30 seconds before
decompress is started.
Mikrotik ipq40xx devices running with RouterBoot have the SoC watchdog
enabled and running with a timeout that does not allow time for the
kernel to decompress and manage the watchdog.
On ipq40xx RouterBoot TFTP boot the watchdog countdown is reset before:
Jumping to kernel
Signed-off-by: John Thomson <git@johnthomson.fastmail.com.au>
4c619b3eed x86: Check IFUNC definition in unrelocated executable [BZ #20019] 87450ecf8a x86: Set header.feature_1 in TCB for always-on CET [BZ #27177] 2b4f67c2b3 Update for [BZ #27130] fix 1a24bbd43e x86-64: Avoid rep movsb with short distance [BZ #27130]
Rui Salvaterra [Wed, 2 Dec 2020 15:42:07 +0000 (15:42 +0000)]
ramips: mt7621: refresh the kernel config
The removed config symbols are already enabled by the generic kernel
configuration (or by default), while the added ones are forcefully
enabled by the specific architecture.
ath79: remove USB port definition for TP-Link TL-WR810N v1
The USB port definition is only needed when it is linked to a USB
LED. Since there is none for this device, we might as well remove
the port definition.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Flashing procedure is identical to other ubnt devices.
https://openwrt.org/toh/ubiquiti/common
Flashing through factory firmware
1. Ensure firmware version v8.7.0 is installed.
Up/downgrade to this exact version.
2. Patch fwupdate.real binary using
`hexdump -Cv /bin/ubntbox | sed 's/14 40 fe 27/00 00 00 00/g' | \
hexdump -R > /tmp/fwupdate.real`
3. Make the patched fwupdate.real binary executable using
`chmod +x /tmp/fwupdate.real`
4. Copy the squashfs factory image to /tmp on the device
5. Flash OpenWrt using `/tmp/fwupdate.real -m <squashfs-factory image>`
6. Wait for the device to reboot
(copied from Ubiquiti NanoBeam AC and modified)
Flashing from serial console
1. Connect serial console (115200 baud)
2. Connect ethernet to a network with a TFTP server, through a
passive PoE injector.
3. Press a key to obtain a u-boot prompt
4. Set your TFTP server's ip address, with:
setenv serverip <tftp-server-address>
5. Set the Bullet AC's ip address, with:
setenv ipaddr <bullet-ac-address>
6. Set the boot file, with:
setenv bootfile <name-of-initramfs-binary-on-tftp-server>
7. Fetch the binary with tftp:
tftpboot
8. Boot the initramfs binary:
bootm
9. From the initramfs, fetch the sysupgrade binary, and flash it with
sysupgrade.
The Bullet AC is identified as a 2WA board by Ubiquiti. As such, the UBNT_TYPE
must match from the "Flashing through factory firmware" install instructions
to work.
Phy0 is QCA988X which can tune either band (2.4 or 5GHz). Phy1 is AR9342,
on which 5GHz is disabled. It isn't currently known whether phy1 is
routed to the N connector at all.
Signed-off-by: Russell Senior <russell@personaltelco.net>
Sungbo Eo [Mon, 4 Jan 2021 13:27:28 +0000 (22:27 +0900)]
kernel: enable CONFIG_LEDS_TRIGGER_HEARTBEAT
The heartbeat trigger is used by luci-mod-system, which is installed
as a part of the standard luci package set. It seems the LED trigger
will be required quite often, so let's enable it by default.
This increases uncompressed kernel size by about 100 bytes on ath79/generic.
Leon M. George [Tue, 12 Jan 2021 09:30:08 +0000 (10:30 +0100)]
hostapd: fix setting wps_state to "not configured"
With encryption disabled, it was intended to set wpa_state=1 (enabled,
not configured) through the 'wps_not_configured' flag.
The flag is set appropriately but the condition using it is broken.
Instead, 'wps_configured' is checked and wpa_state is always 2 (enabled,
configured). Fix it by using the correct variable name.
Fixes: 498d84fc4e00 ("netifd: add wireless configuration support
and port mac80211 to the new framework")
Signed-off-by: Leon M. George <leon@georgemail.eu>
[commit title/message improvements] Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Sungbo Eo [Sun, 3 Jan 2021 13:40:01 +0000 (22:40 +0900)]
kernel: update kmod-thermal package
CONFIG_THERMAL option was changed to boolean in upstream linux commit 554b3529fe01 ("thermal/drivers/core: Remove the module Kconfig's option").
Switch it to 'y' and remove FILES and AUTOLOAD for non-existant module file.
And update the descripton text for the package as in upstream linux commit eb8504620381 ("thermal: Rephrase the Kconfig text for thermal").
Nick Hainke [Wed, 13 Jan 2021 15:06:03 +0000 (16:06 +0100)]
owipcalc: use v6 in cidr_parse6 function
The cidr_parse6 function parses a string to an ipv6-address.
The cidr struct contains a union called buf for the ipv4 and ipv6
address. Since it is a char pointer and the struct is initialized with
the maximum size (so ipv6 string) it does not make any difference.
However, we should access the buffer using the v6 name, since it could
be confusing otherwise.
Jan Alexander [Thu, 14 Jan 2021 13:55:22 +0000 (14:55 +0100)]
ipq806x: fix Ubiquiti UniFi AC HD partition map
This fixes a typo in the previously committed partition map that led to
the extension of the read-only mtd partition "SSD" into the following
partitions.
Fixes: 4e46beb31342 ("ipq806x: add support for Ubiquiti UniFi AC HD") Signed-off-by: Jan Alexander <jan@nalx.net>
Paul Spooren [Wed, 15 Apr 2020 00:49:54 +0000 (14:49 -1000)]
scripts: target-metadata don't add PROFILES twice
Since 4ee3cf2b5a profiles with alternative vendor names may appear
multiple times in `tmp/.targetinfo` or `.targetinfo` (for
ImageBuilders).
The `target-metadata.pl` script adds these profiles then twice to
`PROFILE_NAMES` and the ImageBuilder show the profile twice when running
`make info`.
This patch removes duplicate profile IDs and only adds them once to
`.profiles.mk`.
projects / thirdparty / openwrt.git / log
