[OpenWrt-Devel] [PATCH 2/2] brcm47xx: extend firmware validation

From: Rafał Miłecki This provides TRX validation result, so final JSON may look like: { "tests": { "fwtool_signature": true, "fwtool_device_match": true, "trx_valid": true }, "valid": true, "forceable": true } It

[OpenWrt-Devel] [PATCH 1/2] base-files: use JSON for storing firmware validation info

From: Rafał Miłecki So far firmware validation result was binary limited: it was either successful or not. That meant various limitations, e.g.: 1) Lack of proper feedback on validation problems 2) No way of marking firmware as totally broken (impossible to install) This change introduces JSON

Re: [OpenWrt-Devel] [PATCH v4] ramips: add support for Edimax RG21S

Dear Daniel, thanks for spotting this. Indeed, the correct PCI device-id of the MT7615N is 7615.  Interestingly, the kernel module did not care. I'll submit a new v5 patch for the Edimax RG21S and also a new patch for the ASUS RT-AC85p where I made the same mistake. Birger On 22.08.19 16:47,

[OpenWrt-Devel] [PATCH v5] ramips: add support for Edimax RG21S

ramips: add Edimax RG21S SoC:    MediaTek MT7621AT dual-core @ 880MHz RAM:    256M (Nanya NT5CC128M) FLASH:    16MB (Macronix MX25L12835F) WiFi:    - 2.4GHz MediaTek MT7615N bgn     - 5GHz MediaTek MT7615N nac Switch: SoC integrated Gigabit Switch (4 x LAN, 1 x WAN) USB:    No BTN:    Reset, WPS

[OpenWrt-Devel] [PATCH v4] ramips: add support for Asus RT-AC85P

ramips: add support for Asus RT-AC85P SoC:MediaTek MT7621AT dual-core @ 880MHz RAM:256M (Winbond W632GG6KB-1) FLASH: 128MB (Macronix MX30LF1G18AC-TI) WiFi: - 2.4GHz MediaTek MT7615N bgn - 5GHz MediaTek MT7615N nac Switch: SoC integrated Gigabit Switch (4 x LAN, 1 x WAN) USB:

[OpenWrt-Devel] [PATCH v5] ramips: add support for Edimax RG21S

ramips: add support for Asus RT-AC85P SoC:MediaTek MT7621AT dual-core @ 880MHz RAM:256M (Winbond W632GG6KB-1) FLASH: 128MB (Macronix MX30LF1G18AC-TI) WiFi: - 2.4GHz MediaTek MT7615N bgn - 5GHz MediaTek MT7615N nac Switch: SoC integrated Gigabit Switch (4 x LAN, 1 x WAN) USB:

[OpenWrt-Devel] [PATCH v5] ramips: add support for Edimax RG21S

ramips: add support for Edimax RG21S SoC:MediaTek MT7621AT dual-core @ 880MHz RAM:256M (Nanya NT5CC128M) FLASH: 16MB (Macronix MX25L12835F) WiFi: - 2.4GHz MediaTek MT7615N bgn - 5GHz MediaTek MT7615N nac Switch: SoC integrated Gigabit Switch (4 x LAN, 1 x WAN) USB:No BTN:

[OpenWrt-Devel] need help regarding flash layout for new device

Hi, I am in the process of getting OpenWRT running on a new device (Lancom LN-1702: NXP T1013). I have a working u-boot and kernel 4.19, and now I am a bit lost regarding what flash/partition layout to use to get OpenWRT running with minimal modifications. I have: NAND flash on T1013 IFC

[OpenWrt-Devel] [PATCH] bcm53xx: add generic subtarget

Same game as for 853e4dd3062df7cb5704b15d6af6730e3194b571. Add generic to the filenames. CC: Hauke Mehrtens Signed-off-by: Paul Spooren --- target/linux/bcm53xx/Makefile | 1 + target/linux/bcm53xx/generic/target.mk | 1 + 2 files changed, 2 insertions(+) create mode 100644

[OpenWrt-Devel] [PATCH] treewide: add Generic subtarget if missing

As in 853e4dd OpenWrt should follow a unified structure, where every device has a target/subtarget combination, if there is only one subtarget, call it "Generic". This introduces predictable filenames. CC: Alexander Couzens CC: Felix Fietkau CC: Jason Wu CC: John Crispin CC: Luka Perkov CC:

Re: [OpenWrt-Devel] [PATCH v3] ramips: add Asus RT-AC85P

Hi! Although it looks like the Asus RT-AC85P and the Asus RT-AC65P models are identical, but I have separated them into two dts and have introduced the HW version into the names (for the new versions in the future). I have an alternative installation method via SSH: Note: The user/password for

[OpenWrt-Devel] [PATCH v2] ath79: add support for gl-ar750

This patch supports gl-ar750, which was previously supported by ar71xx. Specification: - SOC: QCA9531 (650MHz) - Flash: 16 MiB (W25Q128FVSG) - RAM: 128 MiB DDR2 - Ethernet: 10/100: 2xLAN + 10/100: 1xWAN - Wireless: 2.4GHz (bgn) and 5GHz (ac) - USB: 1x USB 2.0 port - Switch: 1x switch - Button: 1x

Re: [OpenWrt-Devel] [PATCH v3] ramips: add Asus RT-AC85P

Hi, On 23.08.19 11:04, Gábor Varga wrote: > Hi! > > Although it looks like the Asus RT-AC85P and the Asus RT-AC65P models > are identical, but I have separated them into two dts and have > introduced the HW version into the names (for the new versions in the > future). Are you sure that is

[OpenWrt-Devel] [RFC]remove outdated targets from snapshots

Hi, various targets at OpenWrt/snapshots[0] are no longer build and cause (at least for me) from time to time some trouble. Would it be possible to add a cron job removing all files from snapshots/ which are older than, a week? The folder is not intented as an archive, right? Sunshine,    

Re: [OpenWrt-Devel] [PATCH v3] ramips: add Asus RT-AC85P

Hi! Birger Koblitz ezt írta (időpont: 2019. aug. 23., P, 11:56): > Hi, > > On 23.08.19 11:04, Gábor Varga wrote: > > Hi! > > > > Although it looks like the Asus RT-AC85P and the Asus RT-AC65P models > > are identical, but I have separated them into two dts and have > > introduced the HW version

Re: [OpenWrt-Devel] [PATCH v4] ramips: add support for Asus RT-AC85P

Hi, > a/target/linux/ramips/base-files/lib/upgrade/platform.sh > b/target/linux/ramips/base-files/lib/upgrade/platform.sh > index a65492a309..cd9d8ae650 100755 > --- a/target/linux/ramips/base-files/lib/upgrade/platform.sh > +++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh > @@ -18,9

[OpenWrt-Devel] [PATCH v2] ramips: use gpio_hog instead of gpio-exp

ramips: use gpio_hog instead of gpio-export The `gpio-export` functionality is a hack for missing kernel functionality, which was rejected in upstream kernel long time ago, for details see this email http://lists.infradead.org/pipermail/openwrt-devel/2019-February/015772.html, discussion in

[OpenWrt-Devel] [PATCH v5] ramips: add support for Asus RT-AC85P

ramips: add support for Asus RT-AC85P SoC:MediaTek MT7621AT dual-core @ 880MHz RAM:256M (Winbond W632GG6KB-1) FLASH: 128MB (Macronix MX30LF1G18AC-TI) WiFi: - 2.4GHz MediaTek MT7615N bgn - 5GHz MediaTek MT7615N nac Switch: SoC integrated Gigabit Switch (4 x LAN, 1 x WAN) USB:

Re: [OpenWrt-Devel] Cannot compile cryptodev-linux using x86-64 SDK

On Sat, Aug 17, 2019 at 2:25 AM Jeffery To wrote: > As the subject of this email says, I get an error when trying to compile > cryptodev-linux using the x86-64 SDK. (Though a different error than the > one I found with the armvirt-64 SDK.) > > This error has been happening for a while, at least

Re: [OpenWrt-Devel] [PATCH v2] ramips: use gpio_hog instead of gpio-exp

Hi, On Fri, Aug 23, 2019 at 1:40 PM Birger Koblitz wrote: > > ramips: use gpio_hog instead of gpio-export > > The `gpio-export` functionality is a hack for > missing kernel functionality, which was rejected in upstream kernel long > time > ago, for details see this email >

Re: [OpenWrt-Devel] [PATCH v2] ath79: add support for gl-ar750

Hi! On Fri, Aug 23, 2019 at 5:08 PM Luochongjun wrote: > > This patch supports gl-ar750, which was previously supported by ar71xx. > > Specification: > - SOC: QCA9531 (650MHz) > - Flash: 16 MiB (W25Q128FVSG) > - RAM: 128 MiB DDR2 > - Ethernet: 10/100: 2xLAN + 10/100: 1xWAN > - Wireless: 2.4GHz

[OpenWrt-Devel] [PATCH v2 1/7] ath79: dts: fix ja76pf2 spi frequency

The frequency was filled acording the information from datasheet for particular chip (Winbond 25Q128BVFG). Unfortunately this led to coruption and introduced bad blocks on the chip. Reducing the frequency to commonly used in ath79, made the board more stable and no new bad blocks were spoted.

[OpenWrt-Devel] [PATCH v2 3/7] ar71xx: sysupgrade: accept ath79 combined-image

There is md5 sum of whole image embedded in combined-image header which is checked on sysupgrade. The check will fail for ath79 images which may have embedded metadata. This is because metadata are appended after the combined image is created. To allow smooth transition from ar71xx to ath79, strip

[OpenWrt-Devel] [PATCH v2 2/7] ath79: image: retire combined-image for Adtran/Bluesocket devices

During review it slipped by that these devices use combined-image which should never be used for newly added ones. Therefore switch to sysupgrade-tar generated images introduced in 8f6f260 ("ath79: routerstation: prepare to use sysupgrade-tar format image"). The sysupgrade accepts both images for

[OpenWrt-Devel] [PATCH v2 0/7] ath79: fixes for devices with RedBoot bootloader

Few fixes with common denominator being RedBoot bootloader, mostly related to images generation. Some of these will need a cherry-pick to 19.07 branch - I'll prepare the patches if theese will be commited. I would like to also put some focus on FS#2428 [1] bug, which will disable sysupgrade for

[OpenWrt-Devel] [PATCH v2 7/7] ath79: image: disable sysupgrade images for routerstations and ja76pf2

Because a bug in handling partial erase blocks in 4.19 kernel, using sysupgrade images will hard brick devices that use RedBoot bootloader and have "FIS directory" with "RedBoot config" on the same erase block. Since flashing the devices from bootloader is safe, and to not cause a situation where

[OpenWrt-Devel] [PATCH v2 4/7] ath79: image: append metadata to routerstations and ja76pf2 images

This target enforces metadata check so add the necessary information. It was previously removed because md5 sum check. When using these sysupgrade images on ar71xx target the check would complain about them not matching. Signed-off-by: Tomasz Maciej Nowak ---

[OpenWrt-Devel] [PATCH v2 5/7] ath79: image: add supported string for routerstations and ja76pf2

Now that the md5 check is fixed and metadata present, sysupgrade on ar71xx will complain about device not being supported by the image. Since the cause is not matching strings for supported devices add them accordingly. Signed-off-by: Tomasz Maciej Nowak ---

[OpenWrt-Devel] [PATCH v2 6/7] ath79: fix FIS partition detection for 4.19 kernel

When bumping to 4.19 the patch responsible for scaning flash for FIS partition got left out. Without it devices with RedBoot bootloader using automatic partitions detection in dts won't boot with the new kernel. Fixes: 3771176 ("ath79: add support for linux 4.19") Signed-off-by: Tomasz Maciej

[OpenWrt-Devel] Questions about IPv6 and NDP-Proxy

Hello I have seen on some old OpenWrt documentation (https://openwrt.org/docs/guide-user/network/ipv6/start#router_advertisement_dhcpv6) that by default when the router cannot receive a IPv6 Prefix Delegation (IPv6-PD) but only an IPv6 in the WAN it can automatically detect it and act as a

[OpenWrt-Devel] [PATCH] uqmi: separate into libuqmi library and uqmi util itself

It is needed to reuse qmi code, e.g. in a modem manager util which is useful on routers with several cell modems. Signed-off-by: Denis Kalashnikov --- package/network/utils/uqmi/Makefile | 25 +- .../utils/uqmi/patches/1-libuqmi.patch| 46 +++ 2 files

Re: [OpenWrt-Devel] Squashfs breakage lottery with UBI WAS: [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24

> "Russell" == Russell Senior writes: > "Christian" == Christian Lamparter writes: Russell> It's mostly inferred from the fact that I saw the error and Russell> kernel panic, and glancing at the kernel squashfs code. I am Russell> not pretending to understand completely how the

Re: [OpenWrt-Devel] Squashfs breakage lottery with UBI WAS: [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24

> "Christian" == Christian Lamparter writes: > I've posted a similar message to the bugreport: > I should have filed the bug first and linked it in my patch. > What's happening here is that mksquashfs4 is being told > through the

[OpenWrt-Devel] [RFC PATCH 2/2] apm821xx: utilize softoff on the MyBook Live Series

This was a requested feature on the forum some long time ago. The original vendor firmware from Western Digital allowed the device to enter a shutdown-like state and remain there indefinitely. Because OpenWrt sets the platform's nowayout watchdog, this device will reboot after some time even when

[OpenWrt-Devel] [RFC PATCH 1/2] softoff: add softoff utility

The softoff package replaces the poweroff command with a scripts that utilize the existing sysupgrade code to perform a "soft" poweroff (in a way that the device is no longer responsive). So this makes it safer to disconnect and be moved. By design, sysupgrade already stops services and closes

[OpenWrt-Devel] Squashfs breakage lottery with UBI WAS: [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24

On Thursday, August 22, 2019 1:00:21 PM CEST Russell Senior wrote: > > Using pad-squashfs ensures that the root.squashfs is assigned sufficient > LEBs on UBI such that all reads of the rootfs succeed, in order to avoid > read failures and kernel panics. > > This fixes one such kernel panic

[OpenWrt-Devel] [lantiq] help in supporting FRITZ!BOX 3272 (Fritz_Box_HW198))

Sat, 24 Aug 2019 01:14:40 +0200 (CEST)ear OpenWRt list, I was looking at trying to add support to the FRITZ!BOX 3272 to OpenWRt. It is based on the Lantiq AR10 platform - for which I wasn't able to find any informations, even tought I see kernel code to support it is already available. From