This project is mirrored from https://github.com/luizluca/openwrt.git.
Pull mirroring failed .
Last successful update .
Last successful update .
- 21 Jan, 2021 2 commits
-
-
Rafał Miłecki authored
Final version differs slightly - uses IS_ENABLED() Signed-off-by:Rafał Miłecki <rafal@milecki.pl>
-
Rafał Miłecki authored
Final versions differ slightly from what was used initially. Signed-off-by:
-
- 20 Jan, 2021 7 commits
-
-
Rafał Miłecki authored
BCM4908 can have multiple firmware partitions. MTD needs to detect which one is currently used. Signed-off-by: -
Rafał Miłecki authored
1. It's useful for developing & validating DTS files inside OpenWrt 2. This will allow backporting later changes that depend on it Signed-off-by: -
John Audia authored
All modification made by update_kernel.sh in a fresh clone without existing toolchains. Build system: x86_64 Build-tested: ipq806x/R7800, bcm27xx/bcm2711 Run-tested: ipq806x/R7800 No dmesg regressions, everything functional Signed-off-by:John Audia <graysky@archlinux.us> Tested-by: Curtis Deptuck <curtdept@me.com> [x86/64]
-
Sven Eckelmann authored
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): setenv serverip 192.168.1.21 setenv ipaddr 192.168.1.1 tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr The actual sysupgrade image can then be transferred (on the LAN port) to the device via scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/ On the device, the sysupgrade must then be started using sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin Signed-off-by:
Sven Eckelmann <sven@narfation.org> [rebase, add LED migration] Signed-off-by:
Adrian Schmutzler <freifunk@adrianschmutzler.de>
-
Sven Eckelmann authored
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): setenv serverip 192.168.1.21 setenv ipaddr 192.168.1.1 tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr The actual sysupgrade image can then be transferred (on the LAN port) to the device via scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/ On the device, the sysupgrade must then be started using sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin Signed-off-by:
-
Adrian Schmutzler authored
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 authored
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:
-
- 19 Jan, 2021 14 commits
-
-
Sven Eckelmann authored
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. [1] https://github.com/openwrt/openwrt/pull/3505#issuecomment-716050292 Reported-by:
Michael Pratt <mcpratt@pm.me> Signed-off-by:
-
Sven Eckelmann authored
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): setenv serverip 192.168.1.21 setenv ipaddr 192.168.1.1 tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr The actual sysupgrade image can then be transferred (on the LAN port) to the device via scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/ On the device, the sysupgrade must then be started using sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin Signed-off-by:
-
Sven Eckelmann authored
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): setenv serverip 192.168.1.21 setenv ipaddr 192.168.1.1 tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr The actual sysupgrade image can then be transferred (on the LAN port) to the device via scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/ On the device, the sysupgrade must then be started using sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin Signed-off-by:
-
Sven Eckelmann authored
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. [1] https://github.com/openwrt/openwrt/pull/3505#issuecomment-716050292 Reported-by:
-
Sven Eckelmann authored
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): setenv serverip 192.168.1.21 setenv ipaddr 192.168.1.1 tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr The actual sysupgrade image can then be transferred (on the LAN port) to the device via scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/ On the device, the sysupgrade must then be started using sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin Signed-off-by:
-
Sven Eckelmann authored
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): setenv serverip 192.168.1.21 setenv ipaddr 192.168.1.1 tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr The actual sysupgrade image can then be transferred (on the LAN port) to the device via scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/ On the device, the sysupgrade must then be started using sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin Signed-off-by:
-
Nick Hainke authored
The "cidr_contains6" functions clones the given cidr. The contains4 does not clone the cidr. Both functions do not behave the same. I see no reason to push the cidr. I think that we get only a negligible performance gain, but it makes ipv4 and ipv6 equal again. Signed-off-by:Nick Hainke <vincent@systemli.org>
-
John Audia authored
All modification made by update_kernel.sh in a fresh clone without existing toolchains. Build system: x86_64 Build-tested: ipq806x/R7800, bcm27xx/bcm2711 Run-tested: ipq806x/R7800 No dmesg regressions, everything functional Signed-off-by: -
Hauke Mehrtens authored
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. Signed-off-by:Hauke Mehrtens <hauke@hauke-m.de>
-
Hauke Mehrtens authored
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. Signed-off-by: -
Hauke Mehrtens authored
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. Signed-off-by: -
Paul Spooren authored
Kerning seems to be very off-putting for some people so the logo designer thankfully updated guidelines to something which is now considered final. Signed-off-by:Paul Spooren <mail@aparcar.org>
-
David Bauer authored
These devices do not run Ubiquiti AirOS. Rename the partition to the name used by other UniFi devices with vendor dualboot support. Signed-off-by:David Bauer <mail@david-bauer.net>
-
David Bauer authored
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. Signed-off-by:
-
- 18 Jan, 2021 5 commits
-
-
Rafał Miłecki authored
bcm4908 target needs to include cferam images in firmware files too Signed-off-by: -
Rafał Miłecki authored
Flashing image with BCM4908 CFE bootloader requires specific firmware format. It needs 20 extra bytes with magic numbers and CRC32 appended. This tools allows appending such a tail to the specified image and also verifying CRC32 of existing BCM4908 image. Signed-off-by: -
Rosen Penev authored
Signed-off-by:Rosen Penev <rosenp@gmail.com>
-
Hans Dedecker authored
c00c833 interface-ip: add unreachable route if address is offlink e71909c interface-ip: coding style fixes Tested-by:
Karl Vogel <karl.vogel@gmail.com> Signed-off-by:
Hans Dedecker <dedeckeh@gmail.com>
-
Hans Dedecker authored
53f07e9 ra: fix routing loop on point to point links 2b6959d ra: align ifindex resolving Tested-by:
-
- 17 Jan, 2021 10 commits
-
-
Robert Marko authored
This enables the MikroTik platform driver, it enables us to parse valuable info from hard_config including WLAN calibration data extraction from sysfs. Signed-off-by:Robert Marko <robimarko@gmail.com>
-
Robert Marko authored
Needed for SPI-NOR based MikroTik IPQ40xx devices like hAP ac2. Signed-off-by: -
Robert Marko authored
This enables the new MikroTik specific partition parser. This avoids manually specifying the MikroTik specific partitions as they can be detected by their magic values. Signed-off-by: -
Robert Marko authored
MikroTik devices require the use of raw vmlinux out of the self extracting compressed kernels. They also require 4K sectors, kernel2minor, partition parser as well as RouterBoard platform drivers. So in order to not add unnecessary code to the generic sub target lets introduce a MikroTik sub target. Signed-off-by: -
John Thomson authored
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>
-
Robert Marko authored
This adds a appended_dtb section to the ARM decompressor linker script. This allows using the existing ARM zImage appended DTB support for appending a DTB to the raw ELF kernel. Its size is set to 1MB max to match the zImage appended DTB size limit. To use it to pass the DTB to the kernel, objcopy is used: objcopy --set-section-flags=.appended_dtb=alloc,contents \ --update-section=.appended_dtb=<target>.dtb vmlinux This is based off the following patch: https://github.com/openwrt/openwrt/commit/c063e27e02a9dcac0e7f5877fb154e58fa3e1a69 Signed-off-by:
-
Rosen Penev authored
Helps to see what actually gets installed. Signed-off-by: -
Rosen Penev authored
Reordered for consistency between packages. Fixed license information. Change PKG_BUILD_PARALLEL to 1. This is no longer a problem.1 Signed-off-by: -
Rosen Penev authored
Signed-off-by: -
Alexander Couzens authored
In preparation of the new mikrotik subtarget split the generic images into generic.mk Signed-off-by:Alexander Couzens <lynxis@fe80.eu>
-
- 16 Jan, 2021 2 commits
-
-
Hans Dedecker authored
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] Signed-off-by: -
Rui Salvaterra authored
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. Signed-off-by:Rui Salvaterra <rsalvaterra@gmail.com>
-
