Enable the CPU frequency scaling statistics in kernel config.
Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
Reviewed-by: Robert Marko <robimarko@gmail.com>
Use generic earlycon on Linux Kernel instead of initialization in platform
setup.
And also, drop bootargs with console= parameter from I-O DATA BSH-G24MB. It
uses 115200bps as baud-rate, the same as default in rtl838x.dtsi.
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
ath25 seems to be a target with low number of users according to download
statistics, most of which are for older releases anyway.
Users that we managed to find are currently building images downstream as
due to low amount of RAM (32MB) default config will not work.
Target also suffers from inability for the 5.15 kernel bump to be tested
which is a requirment for the next release.
So, for those reasons, lets mark it as source-only so that Buildbots dont
use the resources for building the images for this target anymore.
Signed-off-by: Robert Marko <robimarko@gmail.com>
On the realtek target, the subtarget makefiles include a KERNEL_PATCHVER
setting, shadowing KERNEL_PATCHVER from target/linux/realtek/Makefile.
This makes the realtek target an exception in this regard, and makes
switching kernel version a bit bothersome. Remove the overrides so all
subtargets use the same kernel version.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Device is the same as Xiaomi Mi Router 4A Gigabit, except of:
- 5G WiFi is MT7663
- addresses of leds, wifi and eth ports are slightly changed
Specs:
SoC: MT7621
CPU: 2 x 880 MHz
ROM: 16 MB
RAM: 128 MB
WLAN: MT7603, MT7663
MAC addresses:
WAN **** factory 0xe006 (label)
LAN *:f7 factory 0xe000
2.4 GHz *:f8 factory 0x0000+0x4 (mtd-eeprom+0x4)
5 GHz *:f9 factory 0x8000+0x4 (mtd-eeprom+0x4)
Installation:
Factory firmware is based on a custom OpenWrt 17.x.
Installation is the same as for Xiaomi Mi Router 4A Gigabit.
Probably the easiest way to install is to use the script from
this repository: https://github.com/acecilia/OpenWRTInvasion/pull/155
In a more advanced case, you can do everything yourself:
- gain access to the device through one of the exploits described
in the link above
- upload sysupgrade image to /tmp
- overwrite stock firmware:
# mtd -e OS1 -r write /tmp/sysupgrade.bin OS1
Recovery:
Recovery procedure is the same as for Xiaomi Mi Router 4A Gigabit.
Possible options can be found here:
https://openwrt.org/inbox/toh/xiaomi/xiaomi_mi_router_4a_gigabit_edition
One of the ways is to use another router with OpenWrt:
- connect both routers by their LAN ports
- download stock firmware from [1]
- place it inside /tmp/test.bin on the main router
- configure PXE/TFTP on the main router
- power off 4Av2, hold Reset button, power on
- as soon as image download via TFTP starts, Reset can be released
- blinking blue wan LED will indicate the end of the flashing process,
now router can be rebooted
[1] http://cdn.cnbj1.fds.api.mi-img.com/xiaoqiang/rom/r4av2/miwifi_r4av2_firmware_release_2.30.28.bin
Signed-off-by: Dmitry Sokolov <e323w@proton.me>
- drop unneeded default-state for led_power
- concat firmware partitions to extend available free space
- increase spi flash frequency to 32 Mhz (value from stock firmware bootlog)
- drop broken-flash-reset because of onboard flash chip W25Q256FV has reset support
- add compatible for pcie wifi according to kernel documetation
- switch to wan mac address with offset 0x28 in rf-eeprom
Signed-off-by: Maxim Anisimov <maxim.anisimov.ua@gmail.com>
This is cosmetic change. The hex value is related to the device
model and more human friendly.
Signed-off-by: Maxim Anisimov <maxim.anisimov.ua@gmail.com>
Add LTE packages required for operating the LTE modems shipped with
the GL-XE300.
Example configuration for an unauthenticated dual-stack APN:
network.wwan0=interface
network.wwan0.proto='qmi'
network.wwan0.device='/dev/cdc-wdm0'
network.wwan0.apn='internet'
network.wwan0.auth='none'
network.wwan0.delay='10'
network.wwan0.pdptype='IPV4V6'
Signed-off-by: Tom Herbers <mail@tomherbers.de>
1. Convert wireless calibration data to NVMEM.
2. Enable control green status LED and change default LED behaviors.
The three LEDs of LBA-047-CH are in the same position, and the green
LED will be completely covered by the other two LEDs. So don's use
green LED as WAN indicator to ensure that only one LED is on at a time.
LED Factory OpenWrt
blue internet fail failsafe && upgrade
green internet okay run
red boot boot
3. Reduce the SPI clock to 30 MHz because the ath79 target does not
support 50 MHz SPI operation well. Keep the fast-read support to
ensure the spi-mem feature (b3f9842330) is enabled.
4. Remove unused package "uboot-envtools".
5. Split the factory image into two parts: rootfs and kernel.
This change can reduce the factory image size and allow users to
upgrade the OpenWrt kernel loader uImage (OKLI) independently.
The new installation method: First, rename "squashfs-kernel.bin" to
"openwrt-ar71xx-generic-ap147-16M-kernel.bin" and rename "rootfs.bin"
to "openwrt-ar71xx-generic-ap147-16M-rootfs-squashfs.bin". Then we
can press reset button for about 5 seconds to enter tftp download mode.
Finally, set IP address to 192.168.67.100 and upload the above two
parts via tftp server.
Tested on Letv LBA-047-CH
Signed-off-by: Shiji Yang <yangshiji66@qq.com>
Driver for both soc (2.4GHz Wifi) and pci (5 GHz) now pull the calibration
data from the nvmem subsystem.
This allows us to move the userspace caldata extraction for the pci-e ath9k
supported wifi into the device-tree definition of the device.
Currently, "mac-address-ascii" cells only works for ethernet and wmac devices,
so PCI ath9k device uses the old method to calibrate.
Signed-off-by: Edward Chow <equu@openmail.cc>
"842" is a compression scheme and this is the software implementation
which is too slow to really use beyond a proof of concept. It can be
selected in ZRAM, ZSWAP, or `fs/pstore`, and is here for completeness.
In general you need a Power8 or better with 842-in-hardware for it to
be fast, but other 842-accelerators are emerging.
Signed-off-by: Tony Butler <spudz76@gmail.com>
This adds an label-mac-device alias which refrences the mac which is
printed on the Label of the device.
Signed-off-by: Tom Herbers <mail@tomherbers.de>
Adjust the wrong phy-handle definitions for the sfp ports so that they
match the correct switch ports.
Fixes: 89eb8b50d1 ("realtek: dgs-1210-10mp: add full sfp description")
Signed-off-by: Daniel Groth <flygarn12@gmail.com>
FCC ID: A8J-EWS660AP
Engenius EWS660AP is an outdoor wireless access point with
2 gigabit ethernet ports, dual-band wireless,
internal antenna plates, and 802.3at PoE+
**Specification:**
- QCA9558 SOC 2.4 GHz, 3x3
- QCA9880 WLAN mini PCIe card, 5 GHz, 3x3, 26dBm
- AR8035-A PHY RGMII GbE with PoE+ IN
- AR8033 PHY SGMII GbE with PoE+ OUT
- 40 MHz clock
- 16 MB FLASH MX25L12845EMI-10G
- 2x 64 MB RAM
- UART at J1 populated, RX grounded
- 6 internal antenna plates (5 dbi, omni-directional)
- 5 LEDs, 1 button (power, eth0, eth1, 2G, 5G) (reset)
**MAC addresses:**
Base MAC addressed labeled as "MAC"
Only one Vendor MAC address in flash
eth0 *:d4 MAC art 0x0
eth1 *:d5 --- art 0x0 +1
phy1 *:d6 --- art 0x0 +2
phy0 *:d7 --- art 0x0 +3
**Serial Access:**
the RX line on the board for UART is shorted to ground by resistor R176
therefore it must be removed to use the console
but it is not necessary to remove to view boot log
optionally, R175 can be replaced with a solder bridge short
the resistors R175 and R176 are next to the UART RX pin
**Installation:**
2 ways to flash factory.bin from OEM:
Method 1: Firmware upgrade page:
OEM webpage at 192.168.1.1
username and password "admin"
Navigate to "Firmware Upgrade" page from left pane
Click Browse and select the factory.bin image
Upload and verify checksum
Click Continue to confirm and wait 3 minutes
Method 2: Serial to load Failsafe webpage:
After connecting to serial console and rebooting...
Interrupt uboot with any key pressed rapidly
execute `run failsafe_boot` OR `bootm 0x9fd70000`
wait a minute
connect to ethernet and navigate to
"192.168.1.1/index.htm"
Select the factory.bin image and upload
wait about 3 minutes
**Return to OEM:**
If you have a serial cable, see Serial Failsafe instructions
otherwise, uboot-env can be used to make uboot load the failsafe image
ssh into openwrt and run
`fw_setenv rootfs_checksum 0`
reboot, wait 3 minutes
connect to ethernet and navigate to 192.168.1.1/index.htm
select OEM firmware image from Engenius and click upgrade
**TFTP recovery:**
Requires serial console, reset button does nothing
rename initramfs.bin to '0101A8C0.img'
make available on TFTP server at 192.168.1.101
power board, interrupt boot
execute tftpboot and bootm 0x81000000
**Format of OEM firmware image:**
The OEM software of EWS660AP is a heavily modified version
of Openwrt Kamikaze. One of the many modifications
is to the sysupgrade program. Image verification is performed
simply by the successful ungzip and untar of the supplied file
and name check and header verification of the resulting contents.
To form a factory.bin that is accepted by OEM Openwrt build,
the kernel and rootfs must have specific names...
openwrt-ar71xx-generic-ews660ap-uImage-lzma.bin
openwrt-ar71xx-generic-ews660ap-root.squashfs
and begin with the respective headers (uImage, squashfs).
Then the files must be tarballed and gzipped.
The resulting binary is actually a tar.gz file in disguise.
This can be verified by using binwalk on the OEM firmware images,
ungzipping then untaring.
Newer EnGenius software requires more checks but their script
includes a way to skip them, otherwise the tar must include
a text file with the version and md5sums in a deprecated format.
The OEM upgrade script is at /etc/fwupgrade.sh.
OKLI kernel loader is required because the OEM software
expects the kernel to be no greater than 1536k
and the factory.bin upgrade procedure would otherwise
overwrite part of the kernel when writing rootfs.
Note on PLL-data cells:
The default PLL register values will not work
because of the external AR8035 switch between
the SOC and the ethernet port.
For QCA955x series, the PLL registers for eth0 and eth1
can be see in the DTSI as 0x28 and 0x48 respectively.
Therefore the PLL registers can be read from uboot
for each link speed after attempting tftpboot
or another network action using that link speed
with `md 0x18050028 1` and `md 0x18050048 1`.
The clock delay required for RGMII can be applied
at the PHY side, using the at803x driver `phy-mode`.
Therefore the PLL registers for GMAC0
do not need the bits for delay on the MAC side.
This is possible due to fixes in at803x driver
since Linux 5.1 and 5.3
Tested-by: Niklas Arnitz <openwrt@arnitz.email>
Signed-off-by: Michael Pratt <mcpratt@pm.me>
This removes some kernel configuration options which are not needed.
This brings the target closer to the OpenWrt standard configuration.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Make the patches apply cleanly again.
Fixes: 4db8598e42 ("realtek: Do not set KERNEL_ENTRY just to avoid NO_EXCEPT_FILL")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Use the new timer driver for the RTL930x devices.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
[remove old clock provider, select MIPS_EXTERNAL_TIMER and refresh
kernel config]
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Before calling sched_clock_register(), the timer used to drive the
scheduling clock should already be enabled. Otherwise the kernel log
will show strange time jumps during, and the watchdog might not be
pinged in a timely fashion, resulting in reboots.
[ 0.160281] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[ 78.104319] clocksource: Switched to clocksource realtek_otto_timer
Fixes: 3cc8011171 ("realtek: resurrect timer driver")
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Fixes: mxs: add generic subtarget (64ef920)
Adding the generic target caused the TARGET_BOOTFS_PARTSIZE to stay
hidden for these boards, crashing the FAT filesystem creation.
Signed-off-by: Zoltan HERPAI <wigyori@uid0.hu>
Because this comment is followed by another comment, nothing luckily
breaks, so only a cosmetic change.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
Specifications:
SOC: QCA9588 CPU 720 MHz AHB 200 MHz
Switch: AR8236
RAM: 64 MiB DDR2-600
Flash: 8 MiB
WLAN: Wi-Fi4 2.4 GHz 3*3
LAN: LAN ports *4
WAN: WAN port *1
Buttons: reset *1 + wps *1
LEDs: ethernet *5, power, wlan, wps
MAC Address:
use address source
label 70:62:b8:xx:xx:96 lan && wlan
lan 70:62:b8:xx:xx:96 mfcdata@0x35
wan 70:62:b8:xx:xx:97 mfcdata@0x6a
wlan 70:62:b8:xx:xx:96 mfcdata@0x51
Install via Web UI:
Apply factory image in the stock firmware's Web UI.
Install via Emergency Room Mode:
DIR-629 A1 will enter recovery mode when the system fails to boot or
press reset button for about 10 seconds.
First, set IP address to 192.168.0.1 and server IP to 192.168.0.10.
Then we can open http://192.168.0.1 in the web browser to upload
OpenWrt factory image or stock firmware. Some modern browsers may
need to turn on compatibility mode.
Signed-off-by: Shiji Yang <yangshiji66@qq.com>
RTL931x kernel builds were patched to bypass the LINKER_LOAD_ADDRESS
parameter, and hardcode it to 0x80220000. This doesn't make much sense,
since value of LINKER_LOAD_ADDRESS, load-ld, only appears to be a copy
of load-y, adjusted to the linker's taste.
Dropping the hacks for bypassing LINKER_LOAD_ADDRESS results in a kernel
that actually starts booting on an RTL9313 (Netgear MS510TXM), but
currently still hangs when the kernel switches timers.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
This change consolidates Netgear EX7300 series devices into two images
corresponding to devices that share the same manufacturer firmware
image. Similar to the manufacturer firmware, the actual device model is
detected at runtime. The logic is taken from the netgear GPL dumps in a
file called generate_board_conf.sh.
Hardware details for EX7300 v2 variants
---------------------------------------
SoC: QCN5502
Flash: 16 MiB
RAM: 128 MiB
Ethernet: 1 gigabit port
Wireless 2.4GHz (currently unsupported due to lack of ath9k support):
- EX6250 / EX6400 v2 / EX6410 / EX6420: QCN5502 3x3
- EX7300 v2 / EX7320: QCN5502 4x4
Wireless 5GHz:
- EX6250: QCA9986 3x3 (detected by ath10k as QCA9984 3x3)
- EX6400 v2 / EX6410 / EX6420 / EX7300 v2 / EX7320: QCA9984 4x4
Signed-off-by: Wenli Looi <wlooi@ucalgary.ca>
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>
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>
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>
Hannu Nyman