ChromiumOS's vboot_reference tooling [1] provides convenient access to
various firmware and hardware details via its `crossystem` tool.
crossystem currently:
(1) relies on the v1 GPIO cdev API to read GPIOs; and
(2) expects gpio-line-names properties.
Enable the kernel config, and document a few pins for OnHub devices.
I only go so far as to pull two relevant names out of the vendor device
tree. Others could perhaps be backfilled if the info is available and
useful.
[1] https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+/HEAD/README
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/16014
Signed-off-by: Robert Marko <robimarko@gmail.com>
ChromiumOS's vboot_reference tooling [1] provides convenient access to
various firmware and hardware details via its `crossystem` tool.
crossystem currently:
(1) relies on the v1 GPIO cdev API to read GPIOs; and
(2) expects gpio-line-names properties.
Enable the kernel config, and document a few pins for Google WiFi
devices.
I only go so far as to pull two relevant names out of the vendor device
tree. Others could perhaps be backfilled if the info is available and
useful.
[1] https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+/HEAD/README
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/16014
Signed-off-by: Robert Marko <robimarko@gmail.com>
These flash chips are used on Google / TP-Link / ASUS OnHub devices, and
OnHub devices are write-protected by default (same as any other
ChromeOS/Chromebook system).
This patch has been submitted upstream, per the notes in the patch file.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/16014
Signed-off-by: Robert Marko <robimarko@gmail.com>
Strip off initial leading blanks and tabs from scripts and script
fragments that are supplied by the package's Makefile. Specifically,
the script included in the postrm must be left justified so that
the shebang is in the first column.
Fixes: https://github.com/openwrt/openwrt/issues/17439
Signed-off-by: Eric Fahlgren <ericfahlgren@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/17440
Signed-off-by: Robert Marko <robimarko@gmail.com>
The label MAC address is written inside the case of the whw03 v2 at the bottom.
Similar fix as to the 4040 in b22d382ae4
Signed-off-by: Florian Maurer <f.maurer@outlook.de>
Link: https://github.com/openwrt/openwrt/pull/17535
Signed-off-by: Robert Marko <robimarko@gmail.com>
This patch is also needed on bmips since it fixes issues with GPIOs not being
properly configured due to gpio_request_enable not being called on bcm63xx
devices. Therefore we can now drop the bcm63268 gpio function patch.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
ath79 uses the generic-ehci driver, which does not support regulators
using vbus-supply.
dr_mode is also not useful as the driver does not support multiple
modes.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/17486
Signed-off-by: Robert Marko <robimarko@gmail.com>
Bringing up a mesh interface using wpa_supplicant already supports a
per-VIF basic rate selection. Add the same ability when creating a mesh
VIF without wpa_supplicant.
Signed-off-by: David Bauer <mail@david-bauer.net>
Update the devicetree files to switch the GS1900 devices over to the new
pinctrl and GPIO driver. Enable the drivers to ensure the nodes can be
used.
This may fix issues caused by bad RMW behaviour on the GPIO data lines,
or glitches due to setting the pin direction before the pin level.
Although the driver supports retaining GPIO state after a warm boot,
some bootloaders appear to apply a default configuration on boot, which
may cause an interrupt in PoE-PSE support.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Add pending patches to add RTL8231 support as a MDIO-bus attached
multi-functional device. This includes subdrivers for the pincontrol and
GPIO features, as well as the LED matrix support.
Leave the drivers disabled until required by a device.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Add a disabled node for the auxiliary MDIO bus, used to manage the
RTL8231 expanders. A simple-mfd parent node is added, at the same
(implied) address as the switch@1b000000 node, as the switch drivers
should anyway transistion to MFD subdivices at some point.
Additionally, two pinctrl-single node are added to allow the MDX pins to
be muxed correctly, in case the bootloader leaves these unconfigured.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Add a driver that exposes the auxiliary busses, used for the RTL8231
expanders, as a proper MDIO controller. The device must be instantiated
under an MFD device, so the driver should also be compatible with SoC
managed by an external CPU via SPI.
Leave the driver disabled in builds until required.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Run 'make kernel_oldconfig' to get an up-to-date config.
"# CONFIG_I2C_MUX_RTL9300 is not set" is retained, as the kernel module
build will selects CONFIG_I2C_MUX=m, on which this symbol depends.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
It is not required to specify the number of blocks as envtools are able
to autodetect it.
Link: https://github.com/openwrt/openwrt/pull/17504
Signed-off-by: Robert Marko <robimarko@gmail.com>
Updating the driver patches for ipq40xx (correctly) removed the
ethernet0 alias from qcom-ipq4019.dtsi; however, on some devices this
alias is needed for the bootloader to set MAC addresses in the FDT.
As it is unknown which devices actually need the alias, simply add it to
all devices trees for now that enable the &gmac now to avoid regressions
from previous OpenWrt releases. The additional alias should not cause any
issues even when it is not needed.
A TODO comment is added to the same Device Trees to document that the
alias may not be needed (hopefully preventing it from being copied
unnecessarily to newly added devices in the future). The following
devices are known to need the alias for correct MAC address assignment,
so no TODO comment is added:
- FRITZ!Box 4040
- FRITZ!Box 7530
Fixes: cd9c721124 ("ipq40xx: 6.1: use latest DSA and ethernet patches")
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Link: https://github.com/openwrt/openwrt/pull/17442
Signed-off-by: Robert Marko <robimarko@gmail.com>
Basic rates were not set for mesh-interfaces, resulting in the undesired
behavior where 11s frames might be sent with a rate which was not
configured.
Depending on the driver, the basic rate might also be used to determine
the beacon rate configured to the chip. One such example are MediaTek
MT7915 platforms.
Signed-off-by: David Bauer <mail@david-bauer.net>
This is a minor upgrade that mainly fixes some compilation errors
and remove old unused code.
The Makefile has been reorganized. Now all package make parameters
are passed as configure arguments instead of environment variables.
The compilation dependencies remain the same as ppp v2.5.1 and the
package size changes are negligible.
Change log:
https://github.com/ppp-project/ppp/blob/v2.5.2/README#L70
Upstreamed patches:
101-pppd-crypto-fix-build-without-openssl.patch [1]
102-pppd-make-pid-directory-before-create-the-pid-file.patch [2]
103-pppd-crypto-fix-gcc-14-build.patch [3]
[1] 5f6eabdb66
[2] 734bc0438e
[3] ac269dbf7c
Signed-off-by: Shiji Yang <yangshiji66@qq.com>
Link: https://github.com/openwrt/openwrt/pull/17477
Signed-off-by: Nick Hainke <vincent@systemli.org>
According to datasheet, on AR9344 the switch and switch analog need to
be reset first before initiating a full reset.
Resetting these systems fixes spurious reset hangs on Atheros AR9344
SoCs.
Link: https://github.com/freifunk-gluon/gluon/issues/2904
Signed-off-by: David Bauer <mail@david-bauer.net>
This reverts commit 7ce4ed4829.
Turns out that this requires more work, so revert to prevent making the
LED uncontrollable.
Signed-off-by: Robert Marko <robimarko@gmail.com>
The Linksys MX4200v2 doesn't have the same LED controller as the MX4200v1 or MX4300. It comes with the STMicroelectronics LED1202 while the others come with the NXP PCA9633.
This LED controller has a driver under development which is currently being reviewed by the respective kernel maintainers. They are currently on v11.
Apart from the changes needed on the MX4200v2, this commit also amends the configuration of other devices affected by this change as the LED controller is no common to all of them as it was originally thought.
Signed-off-by: Manuel Fombuena <fombuena@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/17451
Signed-off-by: Robert Marko <robimarko@gmail.com>
This LED controller has a driver under development which is currently being reviewed by the respective kernel maintainers. They are currently on v11 which is included here.
The LED1202 is a 12-channel low quiescent current LED driver with:
* Supply range from 2.6 V to 5 V
* 20 mA current capability per channel
* 1.8 V compatible I2C control interface
* 8-bit analog dimming individual control
* 12-bit local PWM resolution
* 8 programmable patterns
If the led node is present in the controller then the channel is
set to active.
The output current can be adjusted separately for each channel by 8-bit
analog (current sink input) and 12-bit digital (PWM) dimming control. The
LED1202 implements 12 low-side current generators with independent dimming
control.
Internal volatile memory allows the user to store up to 8 different patterns,
each pattern is a particular output configuration in terms of PWM
duty-cycle (on 4096 steps). Analog dimming (on 256 steps) is per channel but
common to all patterns. Each device tree LED node will have a corresponding
entry in /sys/class/leds with the label name. The brightness property
corresponds to the per channel analog dimming, while the patterns[1-8] to the
PWM dimming control.
Signed-off-by: Manuel Fombuena <fombuena@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/17451
Signed-off-by: Robert Marko <robimarko@gmail.com>
I think I implemented the U-Boot handling incorrectly on M30 (saw the issue while porting M60 to OpenWrt). Maybe someone with more U-Boot experience can have a look at it.
What I understood until now:
Before flashing, `sw_tryactive` must be set to 0 because OpenWrt runs on partition 0
During reset after flashing, U-Boot executes the following line:
`boot_rd_auto_sw_img=if itest.s ${sw_tryactive} == 2; then run boot_by_part; else run boot_by_tryactive; fi`
As `sw_tryactive` was set to 0 before flashing, `boot_by_tryactive` will be executed:
`boot_by_tryactive=if itest.s ${sw_tryactive} == 0; then setenv sw_tryactive 2; setenv sw_active 1; saveenv; run ub0; else setenv sw_tryactive 2; setenv sw_active 2; saveenv; run ub1; fi`
As `sw_tryactive` was set to 0 before flashing, `sw_active` will be set to 1 and `ub0` will be executed:
`ub0=setenv bootpart 0; mtkboardboot; run ub0to1; uip main; reset`
If the OpenWrt boot is successful, `ub0to1` and `uip` main will never be executed. Only in case OpenWrt cannot be loaded, `mtkboardboot` will return and the fallback `ub0to1` is executed.
Conclusion: It's sufficient to set `sw_tryacitve` to 0 before flashing, the added code in `target/linux/mediatek/filogic/base-files/etc/init.d/bootcount` is useless.
In the worst case (/proc/cmdline doesn't contain `bootpart=ubi0` as expected), the bootpart variable would be set to 1 and causes starting the firmware from the second partition instead of the one on the first partition.
Signed-off-by: Roland Reinl <reinlroland+github@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/17298
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Images for certain devices are staring to become too large, as some
device only have 6MB available in their vendor partition layout for the
initial install. This is especially pressing for bootloaders only
supporting gzip compression.
Drop some packages from DEFAULT_PACKAGES that aren't strictly required
for a factory install. The user can always install more packages later
using opkg/apk, or via a sysupgrade to a custom build.
firewall4 is kept to ensure the most recent firewall package is selected
in builds including LuCI.
ethtool is kept as a frequently used diagnostics tool.
Link: https://github.com/openwrt/openwrt/pull/17450
Signed-off-by: Sander Vanheule <sander@svanheule.net>
We can use a package for the MV88E6060 DSA switch on the single
ath79 device that uses it, saving around 600 KB of memory on
all other devices (for the DSA infrastructure, mainly).
As far as I can see the TP-Link TL WR941 v2 is the only device
using MV88E6060 and the only device with a DSA switch overall.
However the ath79 people should look at this so I'm not
mistaken.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.ozlabs.org/project/openwrt/patch/20250102-ath79-mv88e6060-module-v1-1-c2a8e31e72fc@linaro.org/
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Sync buffalo.sh with the one in ramips/mt7621 to improve handling of the
TRX magic numbers of Buffalo WSR devices and switching sysupgrade method
between buffalo_upgrade_ubinized() and nand_do_upgrade().
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/17408
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Unify the common part to the function and don't fixup trx when booting
with initramfs image.
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/17408
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Specification:
SoC: MediaTek MT7628AN
RAM: 128M DDR2, Etron Technology EM68C16CWQG-25H
Flash: 32M, cFeon EN25QH256A (Dual Boot, SPI)
Switch: MediaTek MT7628AN, 4 ports 100 Mbps
WiFi: MediaTek MT7628AN 2.4 GHz 802.11n and MediaTek MT7613BEN 5 GHz 802.11ac
USB: 1 port USB 2.0
GPIO: 3 buttons (Wi-Fi, Reset, FN), 4 LEDs (Power, Internet, FN, Wi-Fi), USB port power controls
Disassembly:
There are 2 screws at the bottom. After removing the screws, pry the gray plastic part around (it is secured with latches) and remove it.
UART Interface:
The UART interface can be connected to the 5 pin located between the WAN port and the RESET button.
Pins (from WAN port to Reset button): VCC, TX, RX, NC, GRD
Settings: 115200, 8N1
Flashing via OEM recovery software:
1. Download the OEM recovery software from the manufacturer's website
2. Download the firmware image (for OpenWRT it is *-squashfs-factory.bin), rename it to KN-1713_recovery.bin
3. Replace the file in the fw folder OEM recovery software with the file from step 2.
4. Run the OEM recovery software and follow the instructions.
Flashing via TFTP:
1. Connect your PC and router to port 1-3, configure PC interface using IP 192.168.1.2, mask 255.255.255.252
2. Serve the firmware image (for OpenWRT it is *-squashfs-factory.bin) renamed to KN-1713_recovery.bin via TFTP
3. Power up the router while pressing Reset button on the back
4. Release Restart button when Power LED starts blinking
To revert back to OEM firmware:
The return to the OEM firmware is carried out by using the methods described above with the help of the appropriate firmware image.
When using OEM bootloader, the firmware image size cannot exceed the size of one OEM «Firmware_x» partition or Kernel + rootFS size.
Signed-off-by: Anton Yu. Ivanusev <ivanusevanton@yandex.ru>
Link: https://github.com/openwrt/openwrt/pull/17382
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
If CC is explicitly set to a non default value, TF-A keeps this value.
Otherwise it assigns generic default value.
As the build bot set CC=/usr/bin/gcc-10, TF-A uses it which causes a
compile issue.
So unset CC before compiling.
It's a new behavior since v2.12. A part of the explanation is available in
this commit [1].
[1] e01c71266f
Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
Link: https://github.com/openwrt/openwrt/pull/17465
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Spaces and tabs are widely used in variable definitions. We have to
remove them to ensure that get_mac_ascii() works properly.
Signed-off-by: Shiji Yang <yangshiji66@qq.com>
Link: https://github.com/openwrt/openwrt/pull/17262
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The function get_mac_ascii() will fail when there are two or more
same MAC address variable names in the mtd partition. Only retain
the first variable to workaround this rare situation.
Fixes: https://github.com/openwrt/openwrt/issues/17236
Signed-off-by: Shiji Yang <yangshiji66@qq.com>
Link: https://github.com/openwrt/openwrt/pull/17262
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Avoids having to set the MAC in userspace.
Also added a mac-base change to set the wifi MACs. It's not clear if
upstream would want it once mac-base is upstreamed.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/17064
Signed-off-by: Robert Marko <robimarko@gmail.com>
On the AVM 5490/5491, lan1, lan2 and wan ports are connected directly
to the internal GSWIP switch. The lan3 and lan4 ports are connected via
an external QCA8334 switch. This commit adds the missing entries in dts
and adds the driver module.
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
Link: https://github.com/openwrt/openwrt/pull/17473
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Now we can set the mt76x8 SDXC pinmux in device tree.
Signed-off-by: Shiji Yang <yangshiji66@qq.com>
Link: https://github.com/openwrt/openwrt/pull/17446
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
These two packages are SDXC drivers for Mediatek mt762x series SoCs.
One is upstream implementation, and the other is downstream driver.
Installing them together will result in conflicts.
Signed-off-by: Shiji Yang <yangshiji66@qq.com>
Link: https://github.com/openwrt/openwrt/pull/17446
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
There are only 5 devices in mt76x8 sub-target selected the MTK SDXC
driver package. And they are all single ethernet port routers or dev
boards:
* LinkIt Smart 7688
* Onion Omega2+
* RAVPower RP-WD009
* VoCore VoCore2
* VoCore VoCore2-Lite
For these devices, they are using the ephy p1 - p4 as the SDXC IO
pins. Therefore, these GPIO pads must be configured in "digital"
IO mode.
Signed-off-by: Shiji Yang <yangshiji66@qq.com>
Link: https://github.com/openwrt/openwrt/pull/17446
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
After adding the correct package and pin group configurations,
the SDXC card slot can now function properly.
Signed-off-by: Shiji Yang <yangshiji66@qq.com>
Link: https://github.com/openwrt/openwrt/pull/17446
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The mt76x8 SDXC pin register definition is incompatible with the
mtmips generic pinctrl driver structure. This hack allows us to
mux the SDXC IO to different pin groups in device tree.
Signed-off-by: Shiji Yang <yangshiji66@qq.com>
Link: https://github.com/openwrt/openwrt/pull/17446
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
