This commit builds on previous efforts to add support
for Sophos devices.
* Add support for Sophos XG 85 with/without wireless
* Add support for Sophos XG 86 with/without wireless
Tested on Sophos XG 85w rev1 and XG 86 rev 1
Signed-off-by: Raylynn Knight <rayknight@me.com>
# CONFIG_PSTORE_COMPRESS_DEFAULT="deflate"
this can lead to confusion. Thankfully, in the KConfig
world this setting is still interpreted as disabled.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
For HiWiFi series devices, label_mac can be read from bdinfo partition,
and lan_mac, wlan2g_mac are same as the label_mac. Converting label_mac
to wlan5g_mac only needs to unset 6th bit. (It seems that all HiWiFi's
label_mac start with D4:EE)
For example:
label D4:EE:07:32:84:88
lan D4:EE:07:32:84:88
wan D4:EE:07:32:84:89
wlan2g D4:EE:07:32:84:88
wlan5g D0:EE:07:32:84:88
Tested on HiWiFi HC5661.
Signed-off-by: Shiji Yang <yangshiji66@qq.com>
at91/sama7 fails to build due to:
| Asymmetric (public-key cryptographic) key type (ASYMMETRIC_KEY_TYPE) [Y/?] y
| Asymmetric public-key crypto algorithm subtype (ASYMMETRIC_PUBLIC_KEY_SUBTYPE) [Y/?] y
| Asymmetric TPM backed private key subtype (ASYMMETRIC_TPM_KEY_SUBTYPE) [N/m/?] (NEW)
|Error in reading or end of file.
please note that asym_tpm (module) has been removed in 5.17:
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d3cff4a9>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
removes usb-port remains as neither the WAC510 nor the WAC505
come with a USB port. Update the LED properties to phase out
labels and introduce generic node-names as well as adding
the color, function and function-enumerator properties.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
ARM Builds like sunxi/cortexa53 or the rpi family failed
to build due to a new symbols showing up:
|Google Firmware Drivers (GOOGLE_FIRMWARE) [Y/n/?] y
| Coreboot Table Access (GOOGLE_COREBOOT_TABLE) [M/n/y/?] m
| Coreboot Framebuffer (GOOGLE_FRAMEBUFFER_COREBOOT) [N/m/?] (NEW)
|Error in reading or end of file.
Fixes: e5b009e53281 ("kernel: Package GOOGLE_FIRMWARE drivers")
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
The OCEDO Raccoon had significant packet-loss with cables longer than 50
meter. Disabling EEE restores normal operation.
Also change the ethernet config to reduce loss on sub-1G links.
Signed-off-by: David Bauer <mail@david-bauer.net>
Avoid flooding the log with the message below by increasing the log
level to debug:
mt7621-nand 1e003000.nand: Using programmed access timing: 31c07388
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
The patch was rejected by upstream. The mtk_nand driver should be
modified to support the mt7621 flash controller instead. As there is no
newer version to backport, or no upstream version to fix bugs, let's
move the driver to the files dir under the ramips target. This makes it
easier to make changes to the driver while waiting for mt7621 support to
land in mtk_nand.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Modified the radio frequency hardware part of e2600ac c1/c2,
need to cooperate with the modified board.bin file, the device
can work normally.
Signed-off-by: 张 鹏 <sd20@qxwlan.com>
This commit replaces patch number 0703 with the upstream accepted
version. This patch requires backporting an additional patch to
avoid conflicts.
The only significant change is the lower maximum MTU. Packets with
lengths over 2400 may be dropped.
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
This commit moves the patches for the r8152.c driver to the generic
directory. Previously they were only available on the bcm27xx target.
With these patches the Realtek RTL8153C, RTL8153D, RTL8156A and RTL8156B
chips are supported on all targets by the kmod-usb-net-rtl8152 module.
The RTL8156A and RTL8156B are the 2.5Gb/s Ethernet adapters.
The patches have been tested on TP-Link UE300 (RTL8153A) and UNITEK
1313B (RTL8156B).
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
This reverts commit 80b7a8a7f5a0a88fde6dd19f097df4d7cac9ff04.
Now that 5.10 is the default kernel for all platforms, we can
bring back the NU801 userspace driver for platforms that rely
on it. Currently it's used on the MX100 x86_64 target, but
other Meraki platforms use this controller.
Note that we also now change how we load nu801. The way we did
this previously with procd worked, but it meant it didn't load
until everything was up and working.
To fix this, let's call nu801 from boot and re-trigger the
preinit blink sequence. Since nu801 runs as a daemon this is
now something we can do.
Signed-off-by: Chris Blake <chrisrblake93@gmail.com>
(removed empty line, currently only MX100 uses it so: @TARGET_x86)
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
This model, also know as "1&1 HomeServer", shares the same features as 7530.
The vendor firmware has artificial software limitations: only 2 of the 4
LAN-Ports are GBit, and the USB-Host is only v2.0.
With OpenWrt, USB is already working at v3.0.
Signed-off-by: Andre Heider <a.heider@gmail.com>
(updated commit message to reflect current state)
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Google WiFi (codename: Gale) is an IPQ4019-based AP, with 2 Ethernet
ports, 2x2 2.4+5GHz WiFi, 512 MB RAM, 4 GB eMMC, and a USB type C port.
In its stock configuration, it runs a Chromium OS-based system, but you
wouldn't know it, since you can only manage it via a "cloud" +
mobile-app system.
The "v2" label is coded into the bootloader, which prefers the
"google,gale-v2" compatible string. I believe "v1" must have been
pre-release hardware.
Note: this is *not* the Google Nest WiFi, released in 2019.
I include "factory.bin" support, where we generate a GPT-based disk
image with 2 partitions -- a kernel partition (using the custom "Chrome
OS kernel" GUID type) and a root filesystem partition. See below for
flashing instructions.
Sysupgrade is supported via recent emmc_do_upgrade() helper.
This is a subtarget because it enables different features
(FEATURES=boot-part rootfs-part) whose configurations don't make sense
in the "generic" target, and because it builds in a few USB drivers,
which are necessary for installation (installation is performed by
booting from USB storage, and so these drivers cannot be built as
modules, since we need to load modules from USB storage).
Flashing instructions
=====================
Documented here:
https://openwrt.org/inbox/toh/google/google_wifi
Note this requires booting from USB storage.
Features
========
I've tested:
* Ethernet, both WAN and LAN ports
* eMMC
* USB-C (hub, power-delivery, peripherals)
* LED0 (R/G/B)
* WiFi (limited testing)
* SPI flash
* Serial console: once in developer mode, console can be accessed via
the USB-C port with SuzyQable, or other similar "Closed Case
Debugging" tools:
https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/master/docs/ccd.md#suzyq-suzyqable
* Sysupgrade
Not tested:
* TPM
Known not working:
* Reboot: this requires some additional TrustZone / SCM
configuration to disable Qualcomm's SDI. I have a proposal upstream,
and based on IRC chats, this might be acceptable with additional DT
logic:
[RFC PATCH] firmware: qcom_scm: disable SDI at boot
https://lore.kernel.org/linux-arm-msm/20200721080054.2803881-1-computersforpeace@gmail.com/
* SMP: enabling secondary CPUs doesn't currently work using the stock
bootloader, as the qcom_scm driver assumes newer features than this
TrustZone firmware has. I posted notes here:
[RFC] qcom_scm: IPQ4019 firmware does not support atomic API?
https://lore.kernel.org/linux-arm-msm/20200913201608.GA3162100@bDebian/
* There's a single external button, and a few useful internal GPIO
switches. I haven't hooked them up.
The first two are fixed with subsequent commits.
Additional notes
================
Much of the DTS is pulled from the Chrome OS kernel 3.18 branch, which
the manufacturer image uses.
Note: the manufacturer bootloader knows how to patch in calibration data
via the wifi{0,1} aliases in the DTB, so while these properties aren't
present in the DTS, they are available at runtime:
# ls -l
/sys/firmware/devicetree/base/soc/wifi@a*/qcom,ath10k-pre-calibration-data
-r--r--r-- 1 root root 12064 Jul 15 19:11 /sys/firmware/devicetree/base/soc/wifi@a000000/qcom,ath10k-pre-calibration-data
-r--r--r-- 1 root root 12064 Jul 15 19:11 /sys/firmware/devicetree/base/soc/wifi@a800000/qcom,ath10k-pre-calibration-data
Ethernet MAC addresses are similarly patched in via the ethernet{0,1} aliases.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
(updated 901 - x1pro moved in the process)
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
See my upstream questions:
https://lore.kernel.org/linux-arm-msm/20200913201608.GA3162100@bDebian/
This effectively reverts upstream Linux commit 13e77747800e ("firmware:
qcom: scm: Use atomic SCM for cold boot"), because Google WiFi boot
firmwares don't support the atomic variant.
This fixes SMP support for Google WiFi.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
See firmware-utils.git commits [1], which implemented the cros-vbutil
verified-boot payload-packing tool, and extended ptgen for the CrOS
kernel partition type. With these, it's now possible to package kernel +
rootfs to make disk images that can boot a Chrome OS-based system (e.g.,
Chromebooks, or even a few AP models).
Regarding PARTUUID= changes: Chromium bootloaders work well with a
partition number offset (i.e., relative to the kernel partition), so
we'll be using a slightly different root UUID line.
NB: I've made this support specific to ip40xx for now, because I only
plan to support an IPQ4019-based AP that uses a Chromium-based
bootloader, but this image format can be used for essentially any
Chromebook, as well as the Google OnHub, a prior Chromium-based AP using
an IPQ8064 chipset.
[1]
ptgen: add Chromium OS kernel partition support
https://git.openwrt.org/?p=project/firmware-utils.git;a=commit;h=6c95945b5de973026dc6f52eb088d0943efa96bb
cros-vbutil: add Chrome OS vboot kernel-signing utility
https://git.openwrt.org/?p=project/firmware-utils.git;a=commit;h=8e7274e02fdc6f2cb61b415d6e5b2e1c7e977aa1
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Tel(co Electronics) X1 Pro is preventing ipq40xx generic
from building due to the KERNEL_SIZE.
Whenever bigger kernels are possible, if lzma is supported
is unknown.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
When using external targets there is a symlink being created for the
target under target/linux which then becomes dangling under Image
Builder. Fix it by dereferencing the possible symlink.
Tested on IB with external target, ipq40xx and mvebu.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
It is disabled in the generic kernel config and not used in any of the
other targets. There was no specific reason for enabling it, so let's be
consistent and remove it from the qoriq kernel config.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
As the LED controller is working now, we can make good use of the LEDs
now.
- Drop the model-name prefix
- Rename eth0 / eth1 LEDs to LAN1 / LAN2, as they are labeled as such
on the casing
- Enable wired LEDs in userspace
Signed-off-by: David Bauer <mail@david-bauer.net>
Move the GPIO extender to the SoC node. Otherwise, the legacy PowerPC
init code will not populate the BUS and thus never probe spi-gpio.
Signed-off-by: David Bauer <mail@david-bauer.net>
While it hasn't always been clear whether the "AP" is part of the model
name on the Ubiquiti website, we include it for all other pre-AC
variants (AP Pro and the AP Outdoor+). Add it to the original UniFi AP
as well for consistency.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
* only map filesystems configured in 'loadables'
* allow mapping more than one filesystem (e.g. customization/branding
or localization in addition to rootfs)
* small cleaning here and there
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
If the selected boot configuration is stored by U-Boot in '/chosen'
node as 'bootconf' attribute, use that configuration to resolve the
block device used as rootfs. Fall back to use the default configuration
in case 'bootconf' is not present.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
a20-olinuxino-lime2 is currently having hard time with link detection of
certain 1000Mbit partners due to usage of generic PHY driver, probably
due to following missing workaround introduced in upstream in commit
3aed3e2a143c ("net: phy: micrel: add Asym Pause workaround"):
The Micrel KSZ9031 PHY may fail to establish a link when the Asymmetric
Pause capability is set. This issue is described in a Silicon Errata
(DS80000691D or DS80000692D), which advises to always disable the
capability. This patch implements the workaround by defining a KSZ9031
specific get_feature callback to force the Asymmetric Pause capability
bit to be cleared.
This fixes issues where the link would not come up at boot time, or when
the Asym Pause bit was set later on.
As a20-olinuxino-lime2 has Micrel KSZ9031RNXCC-TR Gigabit PHY since
revision H, so we need to use Micrel PHY driver on those devices.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Remove "a" character from the first line of patch
738-v5.14-01-net-dsa-qca8k-fix-an-endian-bug-in-qca8k-get-ethtool.patch
Otherwise `git am` fails to apply this patch which is annoying when
trying to do some development / rebasing.
Signed-off-by: Marek Behún <kabel@kernel.org>
uDPU has 2 LM75 compatible temperature sensors, so include the driver for
them by default in order to utilize them.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
uDPU provides a FIT based initramfs, but currently gets stuck after U-boot
starts the kernel at "Starting kernel..".
It is due to the load address being too low, so increase it in order to get
the initramfs booting again.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
As the upcoming release will be based on Linux 5.10 only, remove all
kernel configuration as well as patches for Linux 5.4.
There were no targets still actively using Linux 5.4.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Also known as the "Xiaomi Router AX3200" in western markets,
but only the AX6S is widely installation-capable at this time.
SoC: MediaTek MT7622B
RAM: DDR3 256 MiB (ESMT M15T2G16128A)
Flash: SPI-NAND 128 MiB (ESMT F50L1G41LB or Gigadevice GD5F1GQ5xExxG)
WLAN: 2.4/5 GHz 4T4R
2.4 GHz: MediaTek MT7622B
5 GHz: MediaTek MT7915E
Ethernet: 4x 10/100/1000 Mbps
Switch: MediaTek MT7531B
LEDs/Keys: 2/2 (Internet + System LED, Mesh button + Reset pin)
UART: Marked J1 on board VCC RX GND TX, beginning from "1". 3.3v, 115200n8
Power: 12 VDC, 1.5 A
Notes:
U-Boot passes through the ethaddr from uboot-env partition,
but also has been known to reset it to a generic mac address
hardcoded in the bootloader.
However, bdata is also populated with the ethernet mac addresses,
but is also typically never written to. Thus this is used instead.
Installation:
1. Flash stock Xiaomi "closed beta" image labelled
'miwifi_rb03_firmware_stable_1.2.7_closedbeta.bin'.
(MD5: 5eedf1632ac97bb5a6bb072c08603ed7)
2. Calculate telnet password from serial number and login
3. Execute commands to prepare device
nvram set ssh_en=1
nvram set uart_en=1
nvram set boot_wait=on
nvram set flag_boot_success=1
nvram set flag_try_sys1_failed=0
nvram set flag_try_sys2_failed=0
nvram commit
4. Download and flash image
On computer:
python -m http.server
On router:
cd /tmp
wget http://<IP>:8000/factory.bin
mtd -r write factory.bin firmware
Device should reboot at this point.
Reverting to stock:
Stock Xiaomi recovery tftp that accepts their signed images,
with default ips of 192.168.31.1 + 192.168.31.100.
Stock image should be renamed to tftp server ip in hex (Eg. C0A81F64.img)
Triggered by holding reset pin on powerup.
A simple implementation of this would be via dnsmasq's
dhcp-boot option or using the vendor's (Windows only)
recovery tool available on their website.
Signed-off-by: Richard Huynh <voxlympha@gmail.com>
