The TP-LINK TL-ST1008F has active-high LEDs, so we need a device tree
property to express this.
Signed-off-by: Lorenz Brun <lorenz@brun.one>
[Tidy up code, restrict changes to 5.15]
Signed-off-by: Sander Vanheule <sander@svanheule.net>
On RTL931x builds, CONFIG_RTL931X was used as a stand-in for
CONFIG_NO_EXCEPT_FILL. Now that the latter is always selected for
devices in the realtek target, this hack can be removed. Resulting
device images are binary identical.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
It seems like we are offsetting the KERNEL_ENTRY to +0x400, which is
also accomplished by the NO_EXCEPT_FILL configuration option.
Since this is the default for MIPS_GENERIC_KERNEL, lets push a little
bit closer to that one by doing the same thing.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
It appears that only a few users are using the pistachio SoC. The most
active user of the target has already approved the testing kernel and
so it is very unlikely bugs will be reported in the near future.
Therefore, the target should be directly bumped to 5.15.
Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Nick Hainke <vincent@systemli.org>
Copy config and patch from kernel 5.10 to kernel 5.15.
Signed-off-by: Nick Hainke <vincent@systemli.org>
[Updated the copy]
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Directly copy prebuilt tools in container instead of creating an
archieve and extracting it later in other workflows.
Update build workflow to support this new implementation.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
We can now drop the dl dir in the prebuilt tools tar as package archieve
is not a requirement anymore and won't trigger a package recompile.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Packages in general use 4 check to trigger a recompile:
- timestamp for the build_dir
- timestamp for the staging stamp dir
- depends hash for the build_dir prepared file
- presence of package archieve in dl
If host tools are prebuilt and shipped in a container or manually
installed from an archieve, it would be ideal to skip including the
package archieve and just provide the build_dir prepared files and the
staging stamp file (and the actualy prebuilt tools).
Add some logic to skip dl download for host tools if AUTOREMOVE is
selected and checks for the presence of staging dir stamp file and build
dir stamp file.
If one of these requirements are not met, the package is redownloaded
and rebuilt.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
It's possible to have prebuilt tools already extracted. Add option to
just refresh the timestamps.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Host tools path may be a symbolic link. Use -H with find to follow path
links passed from command line to find command.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Recent backport of NVMEM layout support as well as acommpanying OF changes
introduced a false #nvmem-cell-cells warning as #nvmem-cell-cells are
fully optional.
So, backport an upstream fix for this.
Fixes: 11759a5bf3 ("kernel: backport of changes & helpers")
Signed-off-by: Robert Marko <robimarko@gmail.com>
1ea5855 partname: Introduce fstools_partname_fallback_scan option
While at it also drop AUTORELEASE from PKG_RELEASE.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
This device has two sets of volumes: main ones (`kernel`, `rootfs`, etc) and
'backup' (`kernel.b`, `rootfs.b`, etc). Bootloader tries to determine which set of
volumes to use by looking at contens of `extra-para` and `extra-para.b` volumes.
These volumes contain JSON that looks like this:
```
{
"dbootFlag": "1",
"integerFlag": "1",
"fwFlag": "GOOD",
"score":1
}
```
It looks like the bootloader looks for `"fwFlag": "GOOD"` (as opposed to `BAD`)
then it compares `score` field - whichever 'good' volume has bigger score wins.
This determines which set of volumes to use to boot.
So for example if `extra-para` is good and has bigger score then `kernel`,
`rootfs`, etc volumes are used. This means bootloader needs to explain to the
kernel which volume to use for the rootfs. After looking at bootloader code with
disassembler I think it contains a bug. Relevant part of code looks something
like this:
```
if (image_id == 0) {
rootfs_volume_id = 8;
rootfs_volume_name = "rootfs";
}
else {
rootfs_volume_id = 0xf;
rootfs_volume_name = "rootfs.b";
}
sprintf(
&buffer,
0x800,
"console=ttyS0,115200 noinitrd ubi.mtd=3,2048 ubi.block=0,%s
root=/dev/ubiblock0_%d DKMGT_IMAGE_ID=%d DKMGT_IMAGE_TYPE=ubi",
rootfs_volume_name,
rootfs_volume_id,
image_id
);
```
Where `image_id == 0` if 'normal' (not '*.b' set of volumes is used).
However from device dumps we know that from the factory `rootfs.b` has id 8 and
`rootfs` has id 15.
So from above we can see that ids and names of rootfs volumes do not match. More
over - they are hardcoded in the bootloader.
Both things are problematic for OpwnWRT which completely removes volumes on
update meaning that volume ids may actually change.
So instead of relying on bootloader to provide the kernel with root device this
patch forces kernel to determine root automatically - and it defaults to
`rootfs` volume which is correct for our purposes.
Overall this makes image boot fine from flash after sysupgrade from inirams.
assuming `extra-para*` volumes make bootloader use non-'*.b' set of volumes.
Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com>
Fix DT_DEBUG handling on MIPS in musl libc.
With this change gdb will load the symbol files for shared libraries on MIPS too.
This patch was taken from this thread: https://www.openwall.com/lists/musl/2022/01/09/4
Signed-off-by: Hauke Mehrtens <hmehrtens@maxlinear.com>
Byte swapping code incorrectly uses the number of AES rounds to swap expanded
AES key, while swapping only a single dword in a loop, resulting in swapped
key and partially swapped expanded keys, breaking AES encryption and
decryption on VIA Padlock hardware.
This commit correctly sets the number of swapping loops to be done.
Upstream: 2bcf8e69bd
Acked-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
Signed-off-by: ValdikSS ValdikSS <iam@valdikss.org.ru>
After commit e0d2c59ee995 ("genirq: Always limit the affinity to online
CPUs", 5.10) on Linux, the cpumask passed to irq_set_affinity of irqchip
driver is limited to online CPUs. When irq_do_set_affinity called from
otto timer driver with only one secondary CPU, that CPU is not marked as
online yet, filtered out by cpu_online_mask and fall to error path.
Then, fail to set affinity for that CPU and it leads to instability of
timer on secondary CPU(s).
At least, RTL839x system will be affected.
log:
[ 37.560020] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[ 37.638025] rcu: 1-...!: (0 ticks this GP) idle=6ac/0/0x0 softirq=0/0 fqs=1 (false positive?)
[ 37.752683] (detected by 0, t=6002 jiffies, g=-1179, q=26293)
[ 37.829510] Sending NMI from CPU 0 to CPUs 1:
[ 37.886857] NMI backtrace for cpu 1 skipped: idling at r4k_wait_irqoff+0x1c/0x24
[ 37.984801] rcu: rcu_sched kthread timer wakeup didn't happen for 5999 jiffies! g-1179 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402
[ 38.132743] rcu: Possible timer handling issue on cpu=1 timer-softirq=0
[ 38.221033] rcu: rcu_sched kthread starved for 6000 jiffies! g-1179 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=1
[ 38.356336] rcu: Unless rcu_sched kthread gets sufficient CPU time, OOM is now expected behavior.
[ 38.474440] rcu: RCU grace-period kthread stack dump:
...
Replace to irq_force_affinity from irq_set_affinity and ignore
cpu_online_mask to fix the issue.
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
Tested-by: Olliver Schinagl <oliver@schinagl.nl>
Starting from version 2.39 binutils now warns about sections with rwx
permissions. While this is generally desirable it breaks building
ARM TrustedFirmware-A bl2 which treats warnings as errors.
Disable the warning/error for now to fix build.
Reference: 0579d9f5bc
Signed-off-by: Linhui Liu <liulinhui36@gmail.com>
Dnsmasq DNS cache size is only 150 by default.
Set the uci default value to 1000, so that cache gets used more
and unnecessary DNS queries to upstream can be avoided.
Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
_oob_read returns number of bitflips on success while
bbt_nand_read should return 0.
Fixes: 2d49e49b18 ("mediatek: bmt: use generic mtd api")
Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
c0df2a7 iwinfo: add "band" and "mhz" to the scan output
06ad60f iwinfo: add "band" to the freqlist output
b32fd32 iwinfo: add flags to freqlist output
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Bump ABI to 20230121 due to struct changes
f766138 cli: print the flags on the frequency list
8ee7971 lib: add IWINFO_FREQ_FLAG_NAMES
81184d2 nl80211: fix some comments
2c4ee84 nl80211: prefer non-supplicant-based devices
6194aaf nl80211: simplify iterating over phy's devices
acbf4fe nl80211: remove redundant check in nl80211_phy2ifname()
0172c97 cli: print the frequency and band on the scan list
bbe424f cli: print the band on the frequency list
afa147c nl80211: add "mhz" and "band" to iwinfo_scanlist_entry
0d5ea34 nl80211: add "band" to iwinfo_freqlist_entry
dba0f06 nl80211: add support for radiation and indoor chan restriction
7e3d7de iwinfo: reorganize iwinfo header to enum and defines
9b47b03 devices: add USB devices supported by the mt76 driver
c0fda7c utils: skip comment lines when parsing devices.txt
dbc0ee7 cli: describe USB devices as such
891acee devices: add MediaTek MT7628 card
fac0787 devices: add support for declaring compatible matched devices
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
TP-Link and ASUS OnHub devices are very similar, sharing many of the
same characteristics and much of their Device Tree. They both run a
version of ChromeOS for their factory firmware, and so installation
instructions look very similar to Google Wifi [1].
Things I've tested, and are working:
* Ethernet
* WiFi (2.4 and 5 GHz)
* LEDs
* USB
* eMMC
* Serial console (if you wire it up yourself)
* 2x CPU
* Speaker
== Installation instructions summary ==
1. Flash *-factory.bin to a USB drive (e.g., with `dd`)
2. Insert USB drive, to boot OpenWrt from USB
3. Copy the same *-factory.bin over to device, and flash it to eMMC to
make OpenWrt permanent
== Developer mode, booting from USB (Step 2) ==
To enter Developer Mode and boot OpenWrt from a USB stick:
1. Unplug power
2. Gain access to the "developer switch" through the bottom of the
device
3. Hold down the "reset switch" (near the USB port / power plug)
4. Plug power back in
5. The LED on the device should turn white, then blink orange, then
red. Release the reset switch.
6. Insert USB drive with OpenWrt factory.bin
7. Press the hidden developer switch under the device to boot to USB;
you should see some activity lights (if you have any) on your USB
drive
8. Depending on your configuration, the router's LED(s) should come on.
You're now running OpenWrt off a USB stick.
These instructions are derived from:
https://www.exploitee.rs/index.php/Rooting_The_Google_OnHub#Enabling_%22Developer_Mode%22_on_the_OnHubhttps://www.exploitee.rs/index.php/Asus_OnHub#Enabling_%22Developer_Mode%22_on_the_OnHub
~~Finding the developer switch:~~ for TP-Link, the developer switch is
on the bottom of the device, underneath some of the rubber padding and a
screw. For ASUS, remove the entire base, via 4 screws under the rubber
feet. See the Exploitee instructions for more info and photos.
== Making OpenWrt permanent (on eMMC) (Step 3) ==
Once you're running OpenWrt via USB:
1. Connect Ethernet to the LAN port; router's LAN address should be at
192.168.1.1
2. Connect another system to the router's LAN, and copy the factory.bin
image over, via SCP and SSH:
scp -O openwrt-ipq806x-chromium-tplink_onhub-squashfs-factory.bin root@192.168.1.1:
ssh root@192.168.1.1 -C "dd if=/dev/zero bs=512 seek=7552991 of=/dev/mmcblk0 count=33 && \
dd if=/root/openwrt-ipq806x-chromium-tplink_onhub-squashfs-factory.bin of=/dev/mmcblk0"
3. Reboot and remove the USB drive.
== Developer mode beep ==
Note that every time you boot the OnHub in developer mode, the device
will play a loud "beep" after a few seconds. This is described in the
Chromium docs [2], and is intended to make it clear that the device is
not running Google software. It is nontrivial to completely disable this
beep, although it's possible to "acknowledge" developer mode (and skip
the beep) by using a USB keyboard to press CTRL+D every time you boot.
[1] https://openwrt.org/toh/google/wifi
[2] https://chromium.googlesource.com/chromiumos/docs/+/HEAD/developer_mode.md
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
For IPQ8064 systems based off the "Google Storm" reference platform,
such as the TP-Link OnHub.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
This fixes device tree registration for 'qcom,lpass-cpu' as used by
qcom-ipq8064 SoCs, and allows speaker audio to function.
This patch has been submitted (and merged, for -next; likely v6.3)
upstream.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Refresh target config with `make kernel_menuconfig`, then save the
result. This drops missing symbols or otherwise accounts for defaults.
It should not change any functionality.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Similar to commit 4d8b42d8a7 ("ipq40xx: point to externally compiled
dtbs in recipes").
Currently, we patch our DTS files into the kernel source tree, so the
kernel build process will produce DTBs for us. The kernel-to-DTS
dependency can cause buildroot to perform excessive rebuilds of the
kernel though, which slows down device development iteration.
Buildroot also compiles DTBs on its own, to
$(KDIR)/image-$(DEVICE_DTS).dtb. With small adjustments, we can leverage
this, and stop patching DTS files into the kernel Makefile at the same
time.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
emmc_do_upgrade() relies on identify() from the nand.sh upgrade helper.
This only works because FEATURES=emmc targets also tend to include
FEATURES=nand.
Rename identify_magic() to identify_magic_long() to match the common.sh
style and make it clear it pairs with other *_long() variants (and not,
say *_word()).
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
To bring in isatty() support.
Includes new commits:
be30472bfdbb fs: add `isatty()` function
0a58d510529e nl80211: add support for NL80211_ATTR_MPATH_INFO
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
[ remove additional merge commit ]
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Due to upstream change in U-boot the binaries were renamed [1].
[1] 87ac4b4b4c
Fixes: 2f83369e3e ("uboot-mvebu: update to version 2023.01")
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
Testing target changes was only set for push events. Enable this also
for pull request events to enable testing pr making specific target
changes.
Fixes: 57a02cbbff ("CI: kernel: test each target with additional changes than target/linux")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
ZyXEL NBG7815 is a premium 802.11ax "tri"-band router/AP.
Specifications:
* CPU: Qualcomm IPQ8072A Quad core Cortex-A53 2.2GHz
* RAM: 1 GB 2x Nanya NT5CC256M16ER-EK
* Storage:
* 8MB serial flash Winbond W25Q64DW
* 4GB eMMC flash Kingston EMMC04G-M627
* Ethernet:
* 4x1G RJ45 ports (QCA8074A) with 1x status LED per port
* 1x2.5G RJ45 port (QCA8081) with 1x status LED
* 1x10G RJ45 port (AQR113C) with 1x status LED
* Switch: Qualcomm Atheros QCA8075
* WLAN:
* 2.4GHz: Qualcomm QCN5024 4x4@40MHz 802.11b/g/n/ax 1147 Mbps PHY rate
* 2x 5GHz: Qualcomm QCN5054 4x4 802.11a/b/g/n/ac/ax 2402 PHY rate
* Bluetooth CSR8811 using HSUART, currently unsupported
* USB: 1x USB3.0 Type-A port
* LED-s currently not supported:
* White
* Dark Blu
* Amber
* Purple
* Purple and dark blue
* Red
* Buttons:
* 1x Soft reset
* Power: 12V DC Jack
Installation instructions:
* Disconnect WAN
* Reset device to factory defaults by pushing reset button 15 sec,
LEDs should lit orange color.
* After 5-10 minutes, when the LEDs turn constant dark blue,
put your LAN cable and connect at address 192.168.123.1 by telnet on port 23
* Login with
NBG7815 login: root
password: nbg7815@2019
* cd /tmp/ApplicationData
* wget -O openwrt-ipq807x-generic-zyxel_nbg7815-squashfs-sysupgrade.bin http://...
* wget https://github.com/itorK/nbg7815_tools/blob/main/flash_to_openwrt.sh
* run flash_to_openwrt.sh
If you can't use wget, you can transfer the files via nc.
See https://openwrt.org/inbox/toh/zyxel/nbg7815_armor_g5 for installation details.
Bluetooth usage:
* you need at least package bluez-utils, recommended bluez-daemon
* run following commands to enable and start
hciattach /dev/ttyMSM1 bcsp
hciconfig hci0 up
Many thanks to itorK for his work on this device:
https://github.com/itorK/openwrt/tree/nbg7815
Reviewed-by: Robert Marko <robimarko@gmail.com>
Signed-off-by: André Valentin <avalentin@marcant.net>
Enabling kernel symbol CONFIG_NVMEM_U_BOOT_ENV allows to use u-boot
environement variable ethaddr with nvmen. That way it is possible to assign
the MAC address to the ethernet device driver.
Example of usage in dts:
....
partition@600000 {
compatible = "u-boot,env";
label = "0:appsblenv";
reg = <0x600000 0x10000>;
macaddr_lan: ethaddr {
};
};
....
&dp5 {
status = "okay";
phy-handle = <&qca8081>;
label = "wan";
nvmem-cells = <&macaddr_lan>;
nvmem-cell-names = "mac-address-ascii";
mac-address-increment = <1>;
};
This is needed for Zyxel NBG7815.
Signed-off-by: André Valentin <avalentin@marcant.net>
To download a package the LLVM bins are not strictly needed.
Currently with an example run of make package/bridger/download V=s, the
build fail with
make[2]: Entering directory '/home/ansuel/openwrt-ansuel/openwrt/package/network/services/bridger'
bash: line 1: /home/ansuel/openwrt-ansuel/openwrt/staging_dir/host/llvm-bpf/bin/clang: No such file or directory
bash: line 1: [: : integer expression expected
/home/ansuel/openwrt-ansuel/openwrt/include/bpf.mk:71: *** ERROR: LLVM/clang version too old. Minimum required: 12, found: . Stop.
make[2]: Leaving directory '/home/ansuel/openwrt-ansuel/openwrt/package/network/services/bridger'
time: package/network/services/bridger/download#0.04#0.00#0.06
ERROR: package/network/services/bridger failed to build.
This is wrong since it may be needed to download the required packages
first and then compile them later.
Fix this by ignoring the LLVM bin check on non compile steps.
Tested-by: Robert Marko <robimarko@gmail.com>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Patch the mbedtls source instead of modifying the compile-targets
in the prepare buildstep within OpenWrt.
Signed-off-by: David Bauer <mail@david-bauer.net>
