Changes:
* Increase "oem" partition size from 0x10000 to 0x20000
* Correct partition lables, synchronize with official firmware
Evidence:
It should be the same as hiwifi hc5x61a and the fact indeed the
case. Here is part of dmesg boot log read from official firmware:
[ 1.470000] Creating 7 MTD partitions on "raspi":
[ 1.470000] 0x000000000000-0x000000030000 : "u-boot"
[ 1.480000] 0x000000030000-0x000000040000 : "hw_panic"
[ 1.490000] 0x000000040000-0x000000050000 : "Factory"
[ 1.490000] 0x000000fc0000-0x000000fe0000 : "oem"
[ 1.500000] 0x000000fe0000-0x000000ff0000 : "bdinfo"
[ 1.510000] 0x000000ff0000-0x000001000000 : "backup"
[ 1.510000] 0x000000050000-0x000000fc0000 : "firmware"
Signed-off-by: Shiji Yang <yangshiji66@qq.com>
with u-boot v2020.07 some variables have been renamed so this patch needs to be adjusted
otherwise at least with macOS as build system there are build errors
Signed-off-by: Ronny Kotzschmar <ro.ok@me.com>
Assign the usbdev trigger via devicetree and drop the userspace
handling of the usb leds.
Drop the now unused userspace helper code as well.
Signed-off-by: Mathias Kresin <dev@kresin.me>
Acked-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The QOS feature depends on KPI2UDP which was removed from the tree with
commit a95775e4b2 ("drop unmaintained packages") in 2012.
Since QOS was the last user of the KPI, the feature can be disabled by
default.
Signed-off-by: Mathias Kresin <dev@kresin.me>
The following warnings are shown during build:
/usr/include/vdsl/cmv_message_format.h:33:6: warning: "MEI_SUPPORT_DEBUG_STREAMS" is not defined, evaluates to 0 [-Wundef]
#if (MEI_SUPPORT_DEBUG_STREAMS == 1)
^~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/vdsl/drv_mei_cpe_interface.h:2256:6: warning: "MEI_SUPPORT_OPTIMIZED_FW_DL" is not defined, evaluates to 0 [-Wundef]
#if (MEI_SUPPORT_OPTIMIZED_FW_DL == 1)
^~~~~~~~~~~~~~~~~~~~~~~~~~~
The headers are provided by the MEI driver, but the defines are never
set by the vdsl app. While the struct with the
MEI_SUPPORT_OPTIMIZED_FW_DL conditional isn't used by the vdsl app,
however CMV_USED_PAYLOAD_8BIT_SIZE which value depends on
MEI_SUPPORT_DEBUG_STREAMS is.
Since the MEI driver doesn't provide an autogenerated header with
compile flags, the flags are hardcoded for the vdsl app.
Set them for the MEI driver as well, to indicate a relation to the
values used for the vdsl app and to be not surprised by a changed
default in case the MEI driver gets updated. Use the current default
values defined in the MEI driver.
Signed-off-by: Mathias Kresin <dev@kresin.me>
These boards have a fixed size kernel partition but do not limit the
kernel size during image building.
Disable image building for both boards as well, since the kernel of the
last release as well as master are to big to fit into the 2 MByte kernel
partition.
Signed-off-by: Mathias Kresin <dev@kresin.me>
Assign the usbdev trigger via devicetree and drop the userspace
handling of the usb leds
Add the PCI attached usb controller as trigger sources for the usb led
as well.
Signed-off-by: Mathias Kresin <dev@kresin.me>
The symbol CONFIG_CAVIUM_CN63XXP1 was disabled during the bump to
4.19 (see Fixes:) with the following reason:
No supported hardware uses CN63XXP1 and it causes "slight decrease
in performance"
However, it later turned out that the edgerouter image needed it,
which led to having the device disabled in [1].
Still, dropping support of a device seems a harsh action for just
removing a "slight" decrease in performance from the other devices.
Thus, this enables CONFIG_CAVIUM_CN63XXP1 again, and essentially
restores the situation present until (including) kernel 4.14 on
this target.
For OpenWrt as a platform, it seems more desirable to support all
devices (and have them tested regularly via the snapshots) in this
case.
Users interested in maximum performance might still just remove
the symbol again in their local build.
[1] 3824fa26d2 ("octeon: disable edgerouter image")
Fixes: 6c22545225 ("target/octeon: Add Linux 4.19 support")
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This is useful for dual-boot setups where the loader sets variables depending
on the flash boot partition.
For example the Linksys E8450 sets mtdparts=master for the first partition
and mtdparts=slave for the second one.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Ran update_kernel.sh in a fresh clone without any existing toolchains.
Build system: x86_64
Build-tested: ipq806x/R7800
Run-tested: ipq806x/R7800
No dmesg regressions, everything functional.
Signed-off-by: John Audia <graysky@archlinux.us>
The CPU_MIPS64 and CPU_MIPS32 variables are supposed to be able to
distinguish broadly between 64-bit and 32-bit MIPS CPUs. However, they
weren't selected by the specialty CPUs, Octeon and Loongson, which meant
it was possible to hit a weird state of:
MIPS=y, CONFIG_64BIT=y, CPU_MIPS64=n
This commit rectifies the issue by having CPU_MIPS64 be selected when
the missing Octeon or Loongson models are selected.
In particular, this affects our octeonplus target.
It has been posted to LKML here:
https://lore.kernel.org/linux-mips/20210227122605.2680138-1-Jason@zx2c4.com/
Cc: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
Cc: David Bauer <mail@david-bauer.net>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
CHACHA_MIPS depends on CPU_MIPS32_R2. Therefore,
kmod-crypto-lib-chacha20 should not contain chacha-mips.ko on MIPS32 R1
targets. Enforce that in the target-specific definition.
Fixes bcm47xx, bcm63xx, lantiq/ase, ath25 builds.
Fixes: 06351f1 ("kernel: migrate wireguard into the kernel tree")
Cc: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
BCM63XX internal PHYs and BCM5365 SoC internal switch are both using the
same phy_driver->phy_id, causing conflicts and unnecessary probes. E.g
the BCM63XX phy internal IRQ is lost on the first probe.
The full BCM5365 UID is 0x00406370.
Use an additional byte to mask the BCM5365 UID to avoid duplicate driver
phy_id's. This will fix the IRQ issue in internal BCM63XX PHYs and avoid
more conflicts in the future.
Signed-off-by: Daniel González Cabanelas <dgcbueu@gmail.com>
To the vast majority of the users, wireguard-tools are not useful
without the underlying kernel module. The cornercase of only generating
keys and not using the secure tunnel is something that won't be done on
an embedded OpenWrt system often. On the other hand, maintaining a
separate meta-package only for this use case introduces extra
complexity. WireGuard changes for Linux 5.10 remove the meta-package.
So let's make wireguard-tools depend on kmod-wireguard
to make WireGuard easier to use without having to install multiple
packages.
Fixes: ea980fb9 ("wireguard: bump to 20191226")
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
Use NETWORK_SUPPORT_MENU like all other modules in netsupport.mk. Drop
SECTION and CATEGORY fields as they are set by default and to match
other packages in netsupport.mk. Use better TITLE for kmod-wireguard
(taken from upstream drivers/net/Kconfig).
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
On Linux 5.4, build WireGuard from backports. Linux 5.10 contains
wireguard in-tree.
Add in-kernel crypto libraries required by WireGuard along with
arch-specific optimizations.
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
Rather than using the clunky, old, slower wireguard-linux-compat out of
tree module, this commit does a patch-by-patch backport of upstream's
wireguard to 5.4. This specific backport is in widespread use, being
part of SUSE's enterprise kernel, Oracle's enterprise kernel, Google's
Android kernel, Gentoo's distro kernel, and probably more I've forgotten
about. It's definately the "more proper" way of adding wireguard to a
kernel than the ugly compat.h hell of the wireguard-linux-compat repo.
And most importantly for OpenWRT, it allows using the same module
configuration code for 5.10 as for 5.4, with no need for bifurcation.
These patches are from the backport tree which is maintained in the
open here: https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.4.y
I'll be sending PRs to update this as needed.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
When converting the fdt binary to be created as an artifact, the image
receipt was dropped but the entry in the target images list was not.
Fixes commit 1e41de2f48 ("mpc85xx: convert TL-WDR4900 v1 to simpleImage")
Signed-off-by: David Bauer <mail@david-bauer.net>
ZTE MF283+ is a dual-antenna LTE category 4 router, based on Ralink
RT3352 SoC, and built-in ZTE P685M PCIe MiniCard LTE modem.
Hardware highlighs:
- CPU: MIPS24KEc at 400MHz,
- RAM: 64MB DDR2,
- Flash: 16MB SPI,
- Ethernet: 4 10/100M port switch with VLAN support,
- Wireless: Dual-stream 802.11n (RT2860), with two internal antennas,
- WWAN: Built-in ZTE P685M modem, with two internal antennas and two
switching SMA connectors for external antennas,
- FXS: Single ATA, with two connectors marked PHONE1 and PHONE2,
internally wired in parallel by 0-Ohm resistors, handled entirely by
internal WWAN modem.
- USB: internal miniPCIe slot for modem,
unpopulated USB A connector on PCB.
- SIM slot for the WWAN modem.
- UART connector for the console (unpopulated) at 3.3V,
pinout: 1: VCC, 2: TXD, 3: RXD, 4: GND,
settings: 57600-8-N-1.
- LEDs: Power (fixed), WLAN, WWAN (RGB),
phone (bicolor, controlled by modem), Signal,
4 link/act LEDs for LAN1-4.
- Buttons: WPS, reset.
Installation:
As the modem is, for most of the time, provided by carriers, there is no
possibility to flash through web interface, only built-in FOTA update
and TFTP recovery are supported.
There are two installation methods:
(1) Using serial console and initramfs-kernel - recommended, as it
allows you to back up original firmware, or
(2) Using TFTP recovery - does not require disassembly.
(1) Using serial console:
To install OpenWrt, one needs to disassemble the
router and flash it via TFTP by using serial console:
- Locate unpopulated 4-pin header on the top of the board, near buttons.
- Connect UART adapter to the connector. Use 3.3V voltage level only,
omit VCC connection. Pin 1 (VCC) is marked by square pad.
- Put your initramfs-kernel image in TFTP server directory.
- Power-up the device.
- Press "1" to load initramfs image to RAM.
- Enter IP address chosen for the device (defaults to 192.168.0.1).
- Enter TFTP server IP address (defaults to 192.168.0.22).
- Enter image filename as put inside TFTP server - something short,
like firmware.bin is recommended.
- Hit enter to load the image. U-boot will store above values in
persistent environment for next installation.
- If you ever might want to return to vendor firmware,
BACK UP CONTENTS OF YOUR FLASH NOW.
For this router, commonly used by mobile networks,
plain vendor images are not officially available.
To do so, copy contents of each /dev/mtd[0-3], "firmware" - mtd3 being the
most important, and copy them over network to your PC. But in case
anything goes wrong, PLEASE do back up ALL OF THEM.
- From under OpenWrt just booted, load the sysupgrade image to tmpfs,
and execute sysupgrade.
(2) Using TFTP recovery
- Set your host IP to 192.168.0.22 - for example using:
sudo ip addr add 192.168.0.22/24 dev <interface>
- Set up a TFTP server on your machine
- Put the sysupgrade image in TFTP server root named as 'root_uImage'
(no quotes), for example using tftpd:
cp openwrt-ramips-rt305x-zte_mf283plus-squashfs-sysupgrade.bin /srv/tftp/root_uImage
- Power on the router holding BOTH Reset and WPS buttons held for around
5 seconds, until after WWAN and Signal LEDs blink.
- Wait for OpenWrt to start booting up, this should take around a
minute.
Return to original firmware:
Here, again there are two possibilities are possible, just like for
installation:
(1) Using initramfs-kernel image and serial console
(2) Using TFTP recovery
(1) Using initramfs-kernel image and serial console
- Boot OpenWrt initramfs-kernel image via TFTP the same as for
installation.
- Copy over the backed up "firmware.bin" image of "mtd3" to /tmp/
- Use "mtd write /tmp/firmware.bin /dev/mtd3", where firmware.bin is
your backup taken before OpenWrt installation, and /dev/mtd3 is the
"firmware" partition.
(2) Using TFTP recovery
- Follow the same steps as for installation, but replacing 'root_uImage'
with firmware backup you took during installation, or by vendor
firmware obtained elsewhere.
A few quirks of the device, noted from my instance:
- Wired and wireless MAC addresses written in flash are the same,
despite being in separate locations.
- Power LED is hardwired to 3.3V, so there is no status LED per se, and
WLAN LED is controlled by WLAN driver, so I had to hijack 3G/4G LED
for status - original firmware also does this in bootup.
- FXS subsystem and its LED is controlled by the
modem, so it work independently of OpenWrt.
Tested to work even before OpenWrt booted.
I managed to open up modem's shell via ADB,
and found from its kernel logs, that FXS and its LED is indeed controlled
by modem.
- While finding LEDs, I had no GPL source drop from ZTE, so I had to probe for
each and every one of them manually, so this might not be complete -
it looks like bicolor LED is used for FXS, possibly to support
dual-ported variant in other device sharing the PCB.
- Flash performance is very low, despite enabling 50MHz clock and fast
read command, due to using 4k sectors throughout the target. I decided
to keep it at the moment, to avoid breaking existing devices - I
identified one potentially affected, should this be limited to under
4MB of Flash. The difference between sysupgrade durations is whopping
3min vs 8min, so this is worth pursuing.
In vendor firmware, WWAN LED behaviour is as follows, citing the manual:
- red - no registration,
- green - 3G,
- blue - 4G.
Blinking indicates activity, so netdev trigger mapped from wwan0 to blue:wwan
looks reasonable at the moment, for full replacement, a script similar to
"rssileds" would need to be developed.
Behaviour of "Signal LED" in vendor firmware is as follows:
- Off - no signal,
- Blinking - poor coverage
- Solid - good coverage.
A few more details on the built-in LTE modem:
Modem is not fully supported upstream in Linux - only two CDC ports
(DIAG and one for QMI) probe. I sent patches upstream to add required device
IDs for full support.
The mapping of USB functions is as follows:
- CDC (QCDM) - dedicated to comunicating with proprietary Qualcomm tools.
- CDC (PCUI) - not supported by upstream 'option' driver yet. Patch
submitted upstream.
- CDC (Modem) - Exactly the same as above
- QMI - A patch is sent upstream to add device ID, with that in place,
uqmi did connect successfully, once I selected correct PDP context
type for my SIM (IPv4-only, not default IPv4v6).
- ADB - self-explanatory, one can access the ADB shell with a device ID
added to 51-android.rules like so:
SUBSYSTEM!="usb", GOTO="android_usb_rules_end"
LABEL="android_usb_rules_begin"
SUBSYSTEM=="usb", ATTR{idVendor}=="19d2", ATTR{idProduct}=="1275", ENV{adb_user}="yes"
ENV{adb_user}=="yes", MODE="0660", GROUP="plugdev", TAG+="uaccess"
LABEL="android_usb_rules_end"
While not really needed in OpenWrt, it might come useful if one decides to
move the modem to their PC to hack it further, insides seem to be pretty
interesting. ADB also works well from within OpenWrt without that. O
course it isn't needed for normal operation, so I left it out of
DEVICE_PACKAGES.
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
[remove kmod-usb-ledtrig-usbport, take merged upstream patches]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This patch enables LED support for the GL.iNet GL-MV1000
Signed-off-by: Jeff Collins <jeffcollins9292@gmail.com>
[add SPDX identifier on new file, add aliases, minor cosmetic issues]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Before: Kernel reported "usb_vbus: disabling" and the USB was not
providing power
After: USB power is switched on, peripheral is powered from the
device
Signed-off-by: Tom Stöveken <tom@naaa.de>
[squash and tidy up]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
These patches have been already accepted.
302-ARM-dts-BCM5301X-Update-Northstar-pinctrl-binding.patch had to
be updated.
[rmilecki: use actual upstream accepted patches
replace v5.10 with v5.11 to match actual upstream kernel
recover dropped part of the pinctrl compatible patch
update filenames
refresh patches]
Signed-off-by: Vivek Unune <npcomplete13@gmail.com>
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
PCIe still reports link-down for some reason, RAID fails to assemble
despite SATA looking good (maybe a generic problem with RAID?)
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
This was overlooked when adding support for this device.
(It has recently been discovered that this was the only device in
ath79 having &uart disabled.)
Fixes: acc62630132c ("ath79: add support for GL.iNet GL-USB150")
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Ran update_kernel.sh in a fresh clone without any existing toolchains.
Build system: x86_64
Build-tested: ipq806x/R7800
Run-tested: ipq806x/R7800
No dmesg regressions, everything functional
Signed-off-by: John Audia <graysky@archlinux.us>
[refresh again]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Previously, build would fail for targets containing devices with not
initramfs image (such as mpc85xx-p1010). Only generate the JSON image
info for the initramfs image when we have one to avoid breaking the
builds.
Fixes commit d3140d0529 ("build/json: generate json file for initramfs")
Signed-off-by: David Bauer <mail@david-bauer.net>
simplify maintaining mt7622-bananapi-bpi-r64-rootdisk.dts by
storing only differences between upstream dts
Signed-off-by: Oskari Lemmela <oskari@lemmela.net>
As PKG_LICENSE is originally set by include/trusted-firmware-a.mk it
can only be appended after that. Hence move that line below the
include to actually make sense.
(cosmetical change, already slipped into openwrt-21.02 branch)
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
