Remove file 110-mtd-limit-OTP-nvmem-to-non-nand-devices.patch redundand after adding 440-mtd-don-t-look-for-OTP-legacy-NVMEM-cells-if-proper-.patch in dd78a59
apm821xx: prepare WNDR4700 for 6.6 - add preliminary u-boot-env access
With the default BUILD_BOT configuration on a linux 6.6 kernel,
the WNDR4700's kernel no longer fits into the alloted ~3.5MiB,
even with LZMA compression.
Bigger kernels are possible, but there's a problem with Netgear's
"bootcmd":
> if loadn_dniimg 0 0x180000 0x4e0000 && chk_dniimg 0x4e0000; then nand read 0x800000 0x180000 0x20000;bootm 0x500000 - 0x800040;else fw_recovery; fi"
This loads the dni-image starting offset 0x180000 from the NAND
flash (which is the DTB partition) to 0x4e0000 in the RAM. It then
checks whenever the provided image is "valid". If it is then it
reads the DTB again to 0x800000 in the RAM and starts the extraction
and boot process. (If the image wasn't valid then it starts the
automated firmware recovery).
The issues here are that first: the kernel image gets "squeezed"
between 0x500040 and 0x7fffff... And second, the decompressor
only has area 0x0 - 0x500000 for decompression.
Hence the image now requires to update the bootcmd by providing
new values (which have been successfully tested with the original
Netgear WNDR4700 v1.0.0.56 firmware) for the RAM locations and
make full use of the fact that loadn_dniimg loads the DTB as well.
This needs to be done only once. Just connect a serial adapter to
interface with uboot and overwrite (and save) the new bootcmd.
WARNING: The serial port needs a TTL/RS-232 3.3v level converter!
Steps:
0. Power-off the WNDR4700
1. Connect the serial interface (you need to open the WNDR4700)
2. Power-up the WNDR4700
3. Monitor the boot-sequence and hit "Enter"-key when it says:
"Hit any key to stop autoboot" (Be quick, you have a ~2 second window)
4. in the Prompt enter the following commands (copy & paste)
setenv bootcmd "if loadn_dniimg 0 0x180000 0xce0000 && chk_dniimg 0xce0000; then bootm 0xd00000 - 0xce0040;else fw_recovery; fi"
saveenv
run bootcmd
Note: This new bootcmd will also unbrick devices that were bricked
by the bigger 4.19-6.1 kernels.
Note2: This method was tested with a WNDR4700. A big kernel with most
debug features enabled on v6.6.22 measured 4.30 MiB when compressed
with lzma. The uncompressed kernel is 12.34 MiB. This is over the 3 MiB,
the device reserves for the kernel... But it booted! For bigger kernels,
the device needs repartitioning of the the ubi partition due to the
kernel+dtb not fitting into the partition.
Note3: For initramfs development. I would advice to load the initramfs
images to 0x800000 (or higher). i.e.: tftp 800000 wndr4700.bin
Note4: the fw_recovery uboot command to transfer the factory image to
the flash still works.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Compatiblity with kernel 6.6 for Awinic AW9523B i2c pin controller driver.
It follows the kernel patch: i2c: Drop legacy callback .probe_new() (https://github.com/torvalds/linux/commit/5eb1e6e459cfa025f79c43014f66ff62a55542f1)
and kernel patch: gpiolib: Get rid of not used of_node member (https://github.com/torvalds/linux/commit/70d0fc4288dabd65025fde7774b4f9262afa9034)
ramips: mt7620: alignment with updated snd_soc_dai_driver structure
Fix error: 'struct snd_soc_dai_driver' has no member named 'remove'
It follows the kernel patch: ASoC: soc-dai.h: remove unused call back functions (https://github.com/torvalds/linux/commit/446b31e894935ebbcf84302061a4e0e2efb2368f)
Fix compatibility of ralink net drivers with kernel 6.6.
It follows the kernel patch: u64_stats: Streamline the implementation (https://github.com/torvalds/linux/commit/44b0c2957adc62b86fcd51adeaf8e993171b)
This is an automatically generated commit which aids following Kernel patch history,
as git will see the move and copy as a rename thus defeating the purpose.
See: https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
for the original discussion.
This is an automatically generated commit which aids following Kernel patch history,
as git will see the move and copy as a rename thus defeating the purpose.
See: https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
for the original discussion.
Pawel Dembicki [Thu, 14 Mar 2024 13:17:24 +0000 (14:17 +0100)]
kernel/kirkwood: Restore kernel files for v6.1
This is an automatically generated commit which aids following Kernel patch history,
as git will see the move and copy as a rename thus defeating the purpose.
See: https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
for the original discussion.
Daniel Golle [Wed, 3 Apr 2024 21:54:51 +0000 (22:54 +0100)]
kernel: ltq-vmmc: fix compilation warning/error
Fix compilation warning enum-int-mismatch which results in failure to
build kmod-ltq-vmmc in case CONFIG_KERNEL_WERROR is set.
.../build_dir/target-mips_24kc_musl/linux-lantiq_xrx200/drv_vmmc-1.9.0/src/mps/drv_mps_vmmc_common.c:392:14: error: conflicting types for 'ifx_mps_fastbuf_init' due to enum/integer mismatch; have 'IFX_return_t(void)' [-Werror=enum-int-mismatch]
392 | IFX_return_t ifx_mps_fastbuf_init (IFX_void_t)
| ^~~~~~~~~~~~~~~~~~~~
.../build_dir/target-mips_24kc_musl/linux-lantiq_xrx200/drv_vmmc-1.9.0/src/mps/drv_mps_vmmc_common.c:120:13: note: previous declaration of 'ifx_mps_fastbuf_init' with type 'IFX_int32_t(void)' {aka 'int(void)'}
120 | IFX_int32_t ifx_mps_fastbuf_init (IFX_void_t);
| ^~~~~~~~~~~~~~~~~~~~
.../build_dir/target-mips_24kc_musl/linux-lantiq_xrx200/drv_vmmc-1.9.0/src/mps/drv_mps_vmmc_common.c:420:14: error: conflicting types for 'ifx_mps_fastbuf_close' due to enum/integer mismatch; have 'IFX_return_t(void)' [-Werror=enum-int-mismatch]
420 | IFX_return_t ifx_mps_fastbuf_close (IFX_void_t)
| ^~~~~~~~~~~~~~~~~~~~~
.../build_dir/target-mips_24kc_musl/linux-lantiq_xrx200/drv_vmmc-1.9.0/src/mps/drv_mps_vmmc_common.c:121:13: note: previous declaration of 'ifx_mps_fastbuf_close' with type 'IFX_int32_t(void)' {aka 'int(void)'}
121 | IFX_int32_t ifx_mps_fastbuf_close (IFX_void_t);
| ^~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
Refresh patches and bump PKG_RELEASE while at it.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Felix Fietkau [Thu, 4 Apr 2024 11:19:49 +0000 (13:19 +0200)]
hostapd: slightly clean up patches
- move build/ifdef related changes together to the 200 patch range
- reduce adding/removing include statements across patches
- move patches away from the 99x patch range to simplify maintenance
This adds From:, Date: and Subject: to patches, allowing one to run 'git
am' to import the patches to a hostapd git repository.
From: and Date: fields were taken from the OpenWrt commit where the
patches were first introduced.
Most of the Subject: also followed suit, except for:
- 300-noscan.patch: Took the description from the LuCI web interface
- 350-nl80211_del_beacon_bss.patch: Used the file name
The order of the files in the patch was changed to match what git
format-patch does.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
Patch 050-build_fix.patch fixes the abscence of sha384-kdf.o from the
list of needed objetct files when FILS is selected without any other
option that will select the .o file.
While it is a bug waiting to be fixes upstream, it is not needed for
OpenWrt use case, because OWE already selects sha384-kdf.o, and FILS is
selected along with OWE.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
This brings many changes, including fixes for a couple of memory leaks,
and improved interoperability with 802.11r. There are also many changes
related to 802.11be, which is not enabled at this time.
Isaev Ruslan [Wed, 28 Feb 2024 07:53:54 +0000 (10:53 +0300)]
qualcommax: ipq60xx: add yuncore fap650 support
This commit adds support for the Yuncore FAP650 device.
Specifications:
- Qualcomm IPQ6018+QCA8075+QCN5022+QCN5052
- 512 MB of RAM (DDR3)
- 8 MB of serial flash (SPI NOR)
- 128 MB of parallel flash (NAND)
- 2x2 2.4 GHz WiFi (IPQ6010)
- 2x2 5 GHz WiFi (IPQ6010)
- 2x 2dBi 2.4G MIMO antenna
- 2x 3dBi 5.8G MIMO antenna
- 5x 1 Gbps Ethernet (QCA8075)
- POE: 48V (IEEE 802.3af)
- power: 12V (~1.5A)
- 1x passthru port (rj45 - rj45)
- 1x cisco rj45 console port
- size: 160mm*86mm*29mm
BACKUP YOUR STOCK FIRMWARE:
```
export device=fap650
mkdir -p /tmp/fw_dump_$device
cd /tmp/fw_dump_$device
dmesg > dmesg_$device.log
dtc -I fs /sys/firmware/devicetree/base > $device.dts
cat /proc/device-tree/model > model
cat /proc/mtd > proc_mtd
while read p; do
mtd_dev=$(echo $p | cut -d: -f1)
echo $mtd_dev
dd if=/dev/$mtd_dev of=$mtd_dev
done < proc_mtd
md5sum * > md5sum.log
tar -cvzf ../$device.tar.gz .
export sum=$(md5sum /tmp/$device.tar.gz | cut -d' ' -f1)
mv ../$device.tar.gz /tmp/${device}_${sum}.tar.gz
echo fw backup saved to: /tmp/${device}_${sum}.tar.gz
```
Upload your backup via tftp to the safe place.
INSTALLATION:
1. stock firmware web ui
Rename factory.bin fw image file to factory.ubin. Flash this image
like ordinary stock fw upgrade.
2. stock firmware telnet method
Enter telnet cli (login: root, password: 476t*_f0%g09y) and upload
factory.bin fw image and rename it to factory.ubin
`cd /tmp && wget <your_web_server_ip>/factory.ubin`
`sysupgrade factory.ubin
3. initramfs method
Put imitramfs image to your TFTP server and rename it for example to fap650.initram
Enable serial console and enter to the u-boot cli.
Exec these commands:
`tftpboot <your_tftp_server_ip>:fap650.initram`
`dhcp`
When downloading is finished:
`bootm`
After booting the device, you need to upload to the device factory.ubi fw image.
```
cd /tmp && wget <your_web_server_ip>/factory.ubi`
export rootfs=$(cat /proc/mtd | grep rootfs | cut -d: -f1)
export rootfs_1=$(cat /proc/mtd | grep rootfs_1 | cut -d: -f1)
ubiformat /dev/${rootfs} -y -f factory.ubi
ubiformat /dev/${rootfs_1} -y -f factory.ubi
reboot
```
4. u-boot factory.ubi image method
Put factory.ubi to your TFTP server
Enter u-boot cli and exec these commands:
`tftpboot <your_tftp_server_ip>:factory.ubi`
`dhcp`
After downloading is finished:
`flash rootfs`
`flash rootfs_1`
`reset`
STOCK FIRMWARE RECOVERY:
Boot initramfs image.
Upload your rootfs mtd partition to the device using scp or download
it from the device using wget.
Enter device ssh cli and exec:
```
cd /tmp && wget <your_web_server_ip>/rootfs_mtd`
export rootfs=$(cat /proc/mtd | grep rootfs | cut -d: -f1)
export rootfs_1=$(cat /proc/mtd | grep rootfs_1 | cut -d: -f1)
ubiformat /dev/${rootfs} -y -f /tmp/rootfs_mtd
ubiformat /dev/${rootfs_1} -y -f /tmp/rootfs_mtd
reboot
```
Signed-off-by: Isaev Ruslan <legale.legale@gmail.com>
This is an automatically generated commit which aids following Kernel patch history,
as git will see the move and copy as a rename thus defeating the purpose.
See: https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
for the original discussion.
This is an automatically generated commit which aids following Kernel patch history,
as git will see the move and copy as a rename thus defeating the purpose.
See: https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
for the original discussion.
Stijn Segers [Tue, 19 Mar 2024 21:55:11 +0000 (22:55 +0100)]
mvebu: cortexa9: set DTS dir for 6.6
With 6.6, all DTSes were moved to their vendor subdirectories. ARM64
DTSes already used this scheme, but 32 bit Cortex A9 did not, prior
to 6.6. Introduce a kernel version check to keep backward compatibility
with 6.1.
Suggested-by: Robert Marko <robimarko@gmail.com> Signed-off-by: Stijn Segers <foss@volatilesystems.org>
Stijn Segers [Sat, 23 Mar 2024 21:02:56 +0000 (22:02 +0100)]
mvebu: 6.6: adjust 32 bit ARM DTS path
As of 6.6, all upstream DTSes are moved to their respective vendor subdir.
OpenWrt already followed this practice for ARM64, but not yet for 32 bit
ARM (Armada 37x/38x).
ipq806x: 6.6: add pending patch fixing nandc with new kernel
Add pending patch fixing nandc with new kerenel due to broken convertion
to new nand API. Patch has been sent upstream and will be backported to
stable kernel if accepted.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
ipq806x: 6.6: rework kernel patches for new kernel
Rework kernel patches for new kernel. Mainly adaptation for patch
related to DTS and changes for the downstream div generalize patch that
now use determine_rate.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
ipq806x: split files in 6.1 and 6.6 dedicated directory
Since with recent kernel version DTS moved to a dedicated directory,
it's required to split files to per kernel version to follow kernel
version directory structure.
Also makes use of DEVICE_DTS_DIR to target the correct DTS directory
based on the kernel version.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
This is an automatically generated commit which aids following Kernel patch history,
as git will see the move and copy as a rename thus defeating the purpose.
See: https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
for the original discussion.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
ipq806x: 6.6: add pending patch fixing mtdcore with MTD OTP
Add pending patch fixing mtdcore with MTD OTP with a fragile detection
if Nand supports OTP. Patch has been sent upstream and will be backported
to stable kernel if accepted.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
ipq40xx: split files in 6.1 and 6.6 dedicated directory
Since with recent kernel version DTS moved to a dedicated directory,
it's required to split files to per kernel version to follow kernel
version directory structure.
Also makes use of DEVICE_DTS_DIR to target the correct DTS directory
based on the kernel version.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
This is an automatically generated commit which aids following Kernel patch history,
as git will see the move and copy as a rename thus defeating the purpose.
See: https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
for the original discussion.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Georgi Valkov [Sat, 30 Mar 2024 20:10:27 +0000 (22:10 +0200)]
toolchain/gcc: fix build errors on macOS with Xcode 15.3
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__locale:550:5: error: '__abi_tag__' attribute only applies to structs, variables, functions, and namespaces
_LIBCPP_INLINE_VISIBILITY
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__config:891:37: note: expanded from macro '_LIBCPP_INLINE_VISIBILITY'
# define _LIBCPP_INLINE_VISIBILITY _LIBCPP_HIDE_FROM_ABI
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__config:870:26: note: expanded from macro '_LIBCPP_HIDE_FROM_ABI'
__attribute__((__abi_tag__(_LIBCPP_TOSTRING(_LIBCPP_ODR_SIGNATURE))))
Fixed using backport of upstream commits [1-2] as discussed here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632#c21
[1] Include safe-ctype.h after C++ standard headers, to avoid over-poisoning
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=9970b576b7e4ae337af1268395ff221348c4b34a
mt76: add mt7603 possible workaround for MT7603EN / MT7628AN stability
Add debugfs entry for disabling frames buffering that may be a reason
for mt7603 instability. This patch was sent upstream for review and at
least wasn't rejected yet. Let's add it to let OpenWrt users test if it
really helps.
Example usage:
echo N > /sys/kernel/debug/ieee80211/phy0/mt76/frames_buffering
Sean Khan [Mon, 1 Apr 2024 02:03:22 +0000 (22:03 -0400)]
qca-nss-dp: cp instead of symlink for `nss_dp_arch.h`
Build files shouldn't be symlinked into the staging directory, as doing so
would create a race condition if the build folder for 'qca-nss-dp' gets
deleted for any reason.
We should instead just copy over the required platform file to avoid
breaking compilation for any dependent packages.
Signed-off-by: Sean Khan <datapronix@protonmail.com>
Sean Khan [Tue, 26 Mar 2024 23:40:21 +0000 (19:40 -0400)]
qca-ssdk: rework make to allow parallel building
The current build procedure always wipes away build files, this is
costly as ssdk is a parent dependency on a whole host of packages and
will always end up rebuilding (and in serial) the whole package.
This patch includes:
1. Module Building Optimization: Instead of creating a temporary
directory (temp) and copying files into it for module building,
the directly invoke the module build command with the
necessary paths. This simplifies the build process
and avoids unnecessary file operations, speeding up
the build process and reducing disk usage.
2. Parallel Build Support: By removing the explicit creation of
the temporary directory and associated file copying operations,
and passing in $(MAKE) $(PKG_JOBS) allows building in parallel.
3. Fix `EXTRA_CFLAGS`: This variable is referenced and set within MAKE_FLAGS,
so doesn't preserve spaces. Should have its defined value quoted.
Signed-off-by: Sean Khan <datapronix@protonmail.com>
Installation:
The board comes with a third-party custom OpenWrt image, you can upload
sysupgrade image via LuCI directly WITHOUT keeping configurations.
Or power on the board with pressing reset button for 5 second, then visit
http://192.168.1.1 and upload -factory.bin firmware.
Installation via stock firmware
1. Unlock Telnet access by downloading the backup .tar.gz file
2. Change the Telnet configuration to LAN_Telnet=1
3. Import backup configuration
4. Restart the router
5. Login to telnet with username and password = admin : db40
6. Download sysupgrade binary and mtd_write to the kernel partition
`mtd_write write openwrt-bolt_bl100-squashfs-sysupgrade.bin Kernel`
Felix Fietkau [Sun, 31 Mar 2024 17:42:16 +0000 (19:42 +0200)]
unetd: update to Git HEAD (2024-03-31)
52144f723bec pex: after receiving data update req, notify peer of local address/port 29aacb9386e0 pex: track indirect hosts (reachable via gateway) as peers without adding them to wg 48049524d4fc pex: do not send peer notifications for hosts with a gateway 12ac684ee22a pex: do not query for hosts with a gateway 203c88857354 pex: fix endian issues on config transfer a29d45c71bca network: fix endian issue in converting port to network id cbbe9d337a17 unet-cli: emit id by default 806457664ab6 unet-cli: strip initial newline in usage message
Roland Reinl [Sun, 24 Dec 2023 13:42:23 +0000 (14:42 +0100)]
filogic: Add support for D-Link AQUILA PRO AI M30
Specification:
- MT7981 CPU using 2.4GHz and 5GHz WiFi (both AX)
- MT7531 switch
- 512MB RAM
- 128MB NAND flash with two UBI partitions with identical size
- 1 multi color LED (red, green, blue, white) connected via GCA230718
- 3 buttons (WPS, reset, LED on/off)
- 1 1Gbit WAN port
- 4 1Gbit LAN ports
Disassembly:
- There are four screws at the bottom: 2 under the rubber feets, 2 under the label.
- After removing the screws, the white plastic part can be shifted out of the blue part.
- Be careful because the antennas are mounted on the side and the top of the white part.
Serial Interface
- The serial interface can be connected to the 4 pin holes on the side of the board.
- Pins (from front to rear):
- 3.3V
- RX
- TX
- GND
- Settings: 115200, 8N1
MAC addresses:
- WAN MAC is stored in partition "Odm" at offset 0x81
- LAN (as printed on the device) is WAN MAC + 1
- WLAN MAC (2.4 GHz) is WAN MAC + 2
- WLAN MAC (5GHz) is WAN MAC + 3
Flashing via Recovery Web Interface:
- The recovery web interface always flashes to the currently active partition.
- If OpenWrt is flahsed to the second partition, it will not boot.
- Ensure that you have an OEM image available (encrypted and decrypted version). Decryption is described in the end.
- Set your IP address to 192.168.200.10, subnetmask 255.255.255.0
- Press the reset button while powering on the device
- Keep the reset button pressed until the LED blinks red
- Open a Chromium based and goto http://192.168.200.1 (recovery web interface)
- Download openwrt-mediatek-filogic-dlink_aquila-pro-ai-m30-a1-squashfs-recovery.bin
- The recovery web interface always reports successful flashing, even if it fails
- After flashing, the recovery web interface will try to forward the browser to 192.168.0.1 (can be ignored)
- If OpenWrt was flashed to the first partition, OpenWrt will boot (The status LED will start blinking white and stay white in the end). In this case you're done and can use OpenWrt.
- If OpenWrt was flashed to the second partition, OpenWrt won't boot (The status LED will stay red forever). In this case, the following steps are reuqired:
- Start the web recovery interface again and flash the **decrypted OEM image**. This will be flashed to the second partition as well. The OEM firmware web interface is afterwards accessible via http://192.168.200.1.
- Now flash the **encrypted OEM image** via OEM firmware web interface. In this case, the new firmware is flashed to the first partition. After flashing and the following reboot, the OEM firmware web interface should still be accessible via http://192.168.200.1.
- Start the web recovery interface again and flash the OpenWrt recovery image. Now it will be flashed to the first partition, OpenWrt will boot correctly afterwards and is accessible via 192.168.1.1.
Flashing via U-Boot:
- Open the case, connect to the UART console
- Set your IP address to 192.168.200.2, subnet mask 255.255.255.0. Connect to one of the LAN interfaces of the router
- Run a tftp server which provides openwrt-mediatek-filogic-dlink_aquila-pro-ai-m30-a1-initramfs-kernel.bin.
- Power on the device and select "7. Load image" in the U-Boot menu
- Enter image file, tftp server IP and device IP (if they differ from the default).
- TFTP download to RAM will start. After a few seconds OpenWrt initramfs should start
- The initramfs is accessible via 192.168.1.1, change your IP address accordingly (or use multiple IP addresses on your interface)
- Perform a sysupgrade using openwrt-mediatek-filogic-dlink_aquila-pro-ai-m30-a1-squashfs-sysupgrade.bin
- Reboot the device. OpenWrt should start from flash now
Revert back to stock using the Recovery Web Interface:
- Set your IP address to 192.168.200.2, subnetmask 255.255.255.0
- Press the reset button while powering on the device
- Keep the reset button pressed until the LED blinks red
- Open a Chromium based and goto http://192.168.200.1 (recovery web interface)
- Flash a decrypted firmware image from D-Link. Decrypting an firmware image is described below.
Decrypting a D-Link firmware image:
- Download https://github.com/RolandoMagico/firmware-utils/blob/M32/src/m32-firmware-util.c
- Compile a binary from the downloaded file, e.g. gcc m32-firmware-util.c -lcrypto -o m32-firmware-util
- Run ./m32-firmware-util M30 --DecryptFactoryImage <OriginalFirmware> <OutputFile>
- Example for firmware M30A1_FW101B05: ./m32-firmware-util M30 --DecryptFactoryImage M30A1_FW101B05\(0725091522\).bin M30A1_FW101B05\(0725091522\)_decrypted.bin
Flashing via OEM web interface is not possible, as it will change the active partition and OpenWrt is only running on the first UBI partition.
Controlling the LEDs:
- The LEDs are controlled by a chip called "GCA230718" which is connected to the main CPU via I2C (address 0x40)
- I didn't find any documentation or driver for it, so the information below is purely based on my investigations
- If there is already I driver for it, please tell me. Maybe I didn't search enough
- I implemented a kernel module (leds-gca230718) to access the LEDs via DTS
- The LED controller supports PWM for brightness control and ramp control for smooth blinking. This is not implemented in the driver
- The LED controller supports toggling (on -> off -> on -> off) where the brightness of the LEDs can be set individually for each on cycle
- Until now, only simple active/inactive control is implemented (like when the LEDs would have been connected via GPIO)
- Controlling the LEDs requires three sequences sent to the chip. Each sequence consists of
- A reset command (0x81 0xE4) written to register 0x00
- A control command (for example 0x0C 0x02 0x01 0x00 0x00 0x00 0xFF 0x01 0x00 0x00 0x00 0xFF 0x87 written to register 0x03)
- The reset command is always the same
- In the control command
- byte 0 is always the same
- byte 1 (0x02 in the example above) must be changed in every sequence: 0x02 -> 0x01 -> 0x03)
- byte 2 is set to 0x01 which disables toggling. 0x02 would be LED toggling without ramp control, 0x03 would be toggling with ramp control
- byte 3 to 6 define the brightness values for the LEDs (R,G,B,W) for the first on cycle when toggling
- byte 7 defines the toggling frequency (if toggling enabled)
- byte 8 to 11 define the brightness values for the LEDs (R,G,B,W) for the second on cycle when toggling
- byte 12 is constant 0x87
Comparison to M32/R32:
- The algorithms for decrypting the OEM firmware are the same for M30/M32/R32, only the keys differ
- The keys are available in the GPL sources for the M32
- The M32/R32 contained raw data in the firmware images (kernel, rootfs), the R30 uses a sysupgrade tar instead
- Creation of the recovery image is quite similar, only the header start string changes. So mostly takeover from M32/R32 for that.
- Turned out that the bytes at offset 0x0E and 0x0F in the recovery image header are the checksum over the data area
- This checksum was not checked in the recovery web interface of M32/R32 devices, but is now active in R30
- I adapted the recovery image creation to also calculate the checksum over the data area
- The recovery image header for M30 contains addresses which don't match the memory layout in the DTS. The same addresses are also present in the OEM images
- The recovery web interface either calculates the correct addresses from it or has it's own logic to determine where which information must be written
Signed-off-by: Roland Reinl <reinlroland+github@gmail.com>
Roland Reinl [Tue, 26 Dec 2023 07:31:15 +0000 (08:31 +0100)]
filogic: Add LED driver for GCA230718
Add basic support for the LED driver for GCA230718.
- I didn't find any documentation or driver for it, so the information below is purely based on my investigations
- If there is already I driver for it, please tell me. Maybe I didn't search enough
- I implemented a kernel module (leds-gca230718) to access the LEDs via DTS
- The LED controller supports PWM for brightness control and ramp control for smooth blinking. This is not implemented in the driver
- The LED controller supports toggling (on -> off -> on -> off) where the brightness of the LEDs can be set individually for each on cycle
- Until now, only simple active/inactive control is implemented (like when the LEDs would have been connected via GPIO)
- Controlling the LEDs requires three sequences sent to the chip. Each sequence consists of
- A reset command (0x81 0xE4) written to register 0x00
- A control command (for example 0x0C 0x02 0x01 0x00 0x00 0x00 0xFF 0x01 0x00 0x00 0x00 0xFF 0x87 written to register 0x03)
- The reset command is always the same
- In the control command
- byte 0 is always the same
- byte 1 (0x02 in the example above) must be changed in every sequence: 0x02 -> 0x01 -> 0x03)
- byte 2 is set to 0x01 which disables toggling. 0x02 would be LED toggling without ramp control, 0x03 would be toggling with ramp control
- byte 3 to 6 define the brightness values for the LEDs (R,G,B,W) for the first on cycle when toggling
- byte 7 defines the toggling frequency (if toggling enabled)
- byte 8 to 11 define the brightness values for the LEDs (R,G,B,W) for the second on cycle when toggling
- byte 12 is constant 0x87
Signed-off-by: Roland Reinl <reinlroland+github@gmail.com>
projects / thirdparty / openwrt.git / log
