[OpenWrt-Devel] [PATCH] ath79: Add GL.iNet AR-300M-Lite

2019-03-06 Thread Jeff Kletsky
From: Jeff Kletsky AR300M-Lite is single-Ethernet variant of the AR300M series Its eth0 would otherwise be assigned to the WAN interface making it unreachable firstboot or failsafe. Installation instructions from OEM (OpenWrt variant): * Install sysupgrade.bin using OEM's "Advanced" GUI (LuCI),

Re: [OpenWrt-Devel] ath79: Add GL.iNet AR-300M-Lite

2019-03-06 Thread Jeff Kletsky
Patch updated to include default LED triggers on suggestion of Andreas Ziegler Confirmed to apply cleanly, build, and run on `master` of today. Jeff ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org

[OpenWrt-Devel] [PATCH] build: have scripts/feeds honor feed.mk of the individual feed

2019-03-06 Thread Sven Roederer
The luci and freifunk feed having a common Makefile included by the individual packages. Currently a change to this file will be ignored when running "scripts/feeds update". Add a check for a Makefile "feed.mk" in the root of a feed and include this to the dependencies. Signed-off-by: Sven

Re: [OpenWrt-Devel] [PATCH] ath79: add suport for EnGenius EPG5000

2019-03-06 Thread Petr Štetiar
Tomasz Maciej Nowak [2019-03-06 21:03:53]: > > Tomasz Maciej Nowak [2019-03-04 15:18:53]: > > > >> When doing upgrade from OpenWrt ar71xx image, it is recomended to not keep > >> the > >> old configuration. > > > > why is that? > > The sysfs path to 2.4 wifi has changed, so after the

Re: [OpenWrt-Devel] [PATCH] ath79: add support for jjPlus JA76PF2

2019-03-06 Thread Tomasz Maciej Nowak
W dniu 06.03.2019 o 20:44, Tomasz Maciej Nowak pisze: > W dniu 04.03.2019 o 20:52, Petr Štetiar pisze: >> Tomasz Maciej Nowak [2019-03-04 19:25:12]: >> > [ -f "$CONF_TAR" -a "$SAVE_CONFIG" -eq 1 ] && append="-j > $CONF_TAR" > dd if="$sysup_file" bs=64k skip=1

Re: [OpenWrt-Devel] [PATCH] ath79: add suport for EnGenius EPG5000

2019-03-06 Thread Tomasz Maciej Nowak
Hi, W dniu 04.03.2019 o 21:54, Petr Štetiar pisze: > Tomasz Maciej Nowak [2019-03-04 15:18:53]: > > Hi, > >> When doing upgrade from OpenWrt ar71xx image, it is recomended to not keep >> the >> old configuration. > > why is that? The sysfs path to 2.4 wifi has changed, so after the upgrade

Re: [OpenWrt-Devel] [PATCH] ath79: add support for jjPlus JA76PF2

2019-03-06 Thread Tomasz Maciej Nowak
W dniu 04.03.2019 o 20:52, Petr Štetiar pisze: > Tomasz Maciej Nowak [2019-03-04 19:25:12]: > [ -f "$CONF_TAR" -a "$SAVE_CONFIG" -eq 1 ] && append="-j $CONF_TAR" dd if="$sysup_file" bs=64k skip=1 2>/dev/null | \ - mtd -r $append

Re: [OpenWrt-Devel] [PATCH 1/7] tegra: add new target

2019-03-06 Thread Tomasz Maciej Nowak
Hi, W dniu 05.03.2019 o 11:36, Felix Fietkau pisze: > On 2019-03-04 19:53, Tomasz Maciej Nowak wrote: >> New target introduces initial support for NVIDIA Tegra SoC based devices. >> It focuses on Tegra 2 CPUs, for successors supporting NEON instruction >> set the target should be split in two

[OpenWrt-Devel] [PATCH v2] ath79: add support for jjPlus JA76PF2

2019-03-06 Thread Tomasz Maciej Nowak
jjPlus JA76PF2 (marketed as IntellusPro2) is a network embedded board. Specification SoC:Atheros AR7161 RAM:64 MB DDR Flash: 16 MB SPI NOR Ethernet: 2x 10/100/1000 Mbps AR8316 LAN (CN11), WAN/PoE (CN6 - close to power barrel

[OpenWrt-Devel] [PATCH v2 3/7] tools: add cbootimage-configs for tegra

2019-03-06 Thread Tomasz Maciej Nowak
This provides board configuraion tables for various Tegra boards needed by cbootimage tool to create flashable bootloader images. Signed-off-by: Tomasz Maciej Nowak --- tools/Makefile| 2 +- tools/cbootimage-configs/Makefile | 32 +++ 2 files

[OpenWrt-Devel] [PATCH v2 4/7] uboot-tegra: add U-Boot for tegra boards

2019-03-06 Thread Tomasz Maciej Nowak
Add U-Boot for NVIDIA Tegra based boards, with the first being CompuLab TrimSlice. This is part of initial support for this board. Signed-off-by: Tomasz Maciej Nowak --- package/boot/uboot-tegra/Makefile | 59 +++ .../tegra/base-files/lib/upgrade/platform.sh | 2 +

[OpenWrt-Devel] [PATCH v2 1/7] tegra: add new target

2019-03-06 Thread Tomasz Maciej Nowak
New target introduces initial support for NVIDIA Tegra SoC based devices. It focuses on Tegra 2 CPUs, for successors supporting NEON instruction set the target should be split in two subtargets. This initial commit doesn't create any device image, it's groundwork for further additions.

[OpenWrt-Devel] [PATCH v2 7/7] tegra: add kernel 4.19 support

2019-03-06 Thread Tomasz Maciej Nowak
Signed-off-by: Tomasz Maciej Nowak --- target/linux/generic/config-4.19 | 1 + target/linux/tegra/config-4.19| 565 ++ ...interrupts-due-to-tegra2-silicon-bug.patch | 77 +++ ...enable-front-panel-leds-in-TrimSlice.patch | 46 ++ 4 files changed,

[OpenWrt-Devel] [PATCH v2 6/7] tegra: add support for CompuLab TrimSlice

2019-03-06 Thread Tomasz Maciej Nowak
It is a small form factor computer with rich amount of expansion ports. Some hardware specs and supported features in this commit: CPU: NVIDIA Tegra 2 @ 1GHz RAM: 1GB DDR2-667 Storage: SDHC card slot µSDHC card slot USB to SATA bridge (depends on model) 1MB SPI NOR

[OpenWrt-Devel] [PATCH v2 5/7] kernel: package rtc-em3027 module

2019-03-06 Thread Tomasz Maciej Nowak
Support for Microelectronic EM3027 real time clock chip. Signed-off-by: Tomasz Maciej Nowak --- package/kernel/linux/modules/other.mk | 18 ++ 1 file changed, 18 insertions(+) diff --git a/package/kernel/linux/modules/other.mk b/package/kernel/linux/modules/other.mk index

[OpenWrt-Devel] [PATCH v2 2/7] tools: add cbootimage for tegra

2019-03-06 Thread Tomasz Maciej Nowak
Tegra BCT and bootable flash image generator/compiler >From documentation: This project provides a tool which compiles BCT (Boot Configuration Table) images to place into the boot flash of a Tegra-based device. The tool will either: a) Compile a textual representation of a BCT into a binary

[OpenWrt-Devel] [PATCH v2 0/7] tegra: add new target with support for CompuLab TrimSlice

2019-03-06 Thread Tomasz Maciej Nowak
This is continuation of effort in [1] PR to old LEDE source tree. It received few improvement and some commits got split. Main changes worth mentioning: - update tools and U-Boot to recent versions, - added support for 4.19 kernel - now SD card image is also an rescue image with embedded of

Re: [OpenWrt-Devel] Random PARTUUID on every rebuild

2019-03-06 Thread Mike Jones
On Wed, Mar 6, 2019 at 5:32 AM Jo-Philipp Wich wrote: > Hi, > > the random PARTUUID has been chosen to ensure that a given boot grub > partition (containing grub config, kernel, sysupgrade restore tarball) > boots the correct corresponding rootfs in case multiple openwrt > partitions are present

Re: [OpenWrt-Devel] [PATCH] mac80211: Select better ch/VHT for sub-band radios

2019-03-06 Thread Jeff Kletsky
On 3/3/19 2:44 PM, Jeff Kletsky wrote: From: Jeff Kletsky Certain wireless devices have limitations on the channels on which they can operate. For some of these devices, the present default of ch. 36 (VHT80) is outside of the capabilities of the device. For 5 GHz, provide a default of the

[OpenWrt-Devel] Recursive dependency - openconnect

2019-03-06 Thread Koen Vandeputte
Hi All, Could someone with more knowledge regarding dependencies take a look at this? koen@bob:~/firmware/builds/generic_cns3xxx$ make menuconfig feeds/packages/net/openconnect/Config.in:6:error: recursive dependency detected! For a resolution refer to

Re: [OpenWrt-Devel] coverity results are now public

2019-03-06 Thread Petr Štetiar
Alexander Couzens [2019-03-05 04:40:02]: Hi, > I changed the project to allow everybody to view the defects. can you please try harder? :-) I can view some stats, but no details about actual defects. Am I doing it wrong? -- ynezz ___ openwrt-devel

Re: [OpenWrt-Devel] Random PARTUUID on every rebuild

2019-03-06 Thread Jo-Philipp Wich
Hi, the random PARTUUID has been chosen to ensure that a given boot grub partition (containing grub config, kernel, sysupgrade restore tarball) boots the correct corresponding rootfs in case multiple openwrt partitions are present on the device (e.g. different versions on different block

Re: [OpenWrt-Devel] [PATCH] ramips: ethernet: fix to interrupt handling

2019-03-06 Thread Mingyu Li
the original code use status register to keep there still have some pkts in buffer. need next napi call to receive it. if 128 packets in buffer. you clear status first. because napi max handle 64 packets in buffer. so 64 packets need to handle in next napi poll. if no new packet comming. the