In working with porting the dual-firmware, NAND-based Linksys EA8300
to OpenWrt, one of the puzzles was why it wouldn't "take" a change of
boot partition reliably. After digging into it some, I found that when
a previous Linksys device was ported to the ipq40xx platform, the
boot-counter reset was
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 first non-disabled channel
returned by `iw ph
W dniu 21.03.2019 o 19:02, Hauke Mehrtens pisze:
> On 3/21/19 6:25 PM, Tomasz Maciej Nowak wrote:
>> Hi Hauke,
>>
>> W dniu 21.03.2019 o 17:57, Hauke Mehrtens pisze:
>>> This driver is needed for the I2C mux on the board.
>>
>> This symbol CONFIG_I2C_MUX_PCA954x is in
>> target/linux/mvebu/cortexa
Some ESPRESSObin boards come with soldered eMMC flash, backport upstream
patches adding this device and add patch to sync sdhci nodes order with
U-Boot.
Signed-off-by: Tomasz Maciej Nowak
---
...l-armada37xx-Add-emmc-sdio-pinctrl-d.patch | 40 +++
...l-armada-37xx-Enable-emmc-on-espress.pat
Currently sysupgrade overwrites whole disk and destroys partitions added
by user. Sync the sysupgrade code with the one present in x86 target to
remedy this behaviour.
Signed-off-by: Tomasz Maciej Nowak
---
.../mvebu/base-files/lib/upgrade/platform.sh | 9 ++-
.../mvebu/base-files/lib/upgrade/
This commit adds U-Boot environment defaults which extend the
bootloader to automatically boot the ESPRESSObin board from other
connected mediums i.e. SATA disk or USB disk.
The assigned boot probe order is as follows:
1. USB (usb0), 2. SATA (scsi0), 3. µSD (mmc0), 4. eMMC (mmc1).
U-Boot will itera
Since some boards could be also booted from other mediums than SD card,
lets make the upgrade block device autodetected.
Signed-off-by: Tomasz Maciej Nowak
---
.../base-files/lib/preinit/79_move_config | 9 +
.../mvebu/base-files/lib/upgrade/sdcard.sh| 19 +--
2
This will allow to drop additional packages and in result shrink image
size.
Cc: Jonas Gorski
Signed-off-by: Tomasz Maciej Nowak
---
target/linux/mvebu/image/cortex-a9.mk | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/linux/mvebu/image/cortex-a9.mk
b/target/linu
Let's take this oportunity to implement boot-part and rootfs-part feature
flags.
Signed-off-by: Tomasz Maciej Nowak
---
config/Config-images.in | 2 +-
target/linux/mvebu/Makefile | 2 +-
target/linux/mvebu/image/Makefile | 16 ++--
3 files changed, 8 insertions(+),
Since most of devices using SD card image to boot, use ext4 as boot
files system we can drop fat fs related packages. Also move packages
which are added repeatedly across subtargets to their default packages,
with droping the ones that are enabled in target kernel configugation.
Signed-off-by: Tom
This series includes more or less dependent/related commits, so I decided
to send them in one bulk.
In few points what this series is about:
1. Align features of SD card image with other targets using block boot
devices, commits:
"mvebu: make bootfs size for sdcard image configurable"
"m
This allows to configure rules to push or pop vlan headers.
Signed-off-by: Hauke Mehrtens
---
package/kernel/linux/modules/netsupport.mk | 16
1 file changed, 16 insertions(+)
diff --git a/package/kernel/linux/modules/netsupport.mk
b/package/kernel/linux/modules/netsupport.mk
This allows to classify packets based on a configurable combination
of packet keys and masks.
Signed-off-by: Hauke Mehrtens
---
package/kernel/linux/modules/netsupport.mk | 16
1 file changed, 16 insertions(+)
diff --git a/package/kernel/linux/modules/netsupport.mk
b/package/k
This adds Multi-queue priority scheduler (MQPRIO).
Signed-off-by: Hauke Mehrtens
---
package/kernel/linux/modules/netsupport.mk | 16
1 file changed, 16 insertions(+)
diff --git a/package/kernel/linux/modules/netsupport.mk
b/package/kernel/linux/modules/netsupport.mk
index 003
This can be used for IPsec.
Signed-off-by: Hauke Mehrtens
---
package/kernel/linux/modules/crypto.mk | 12
1 file changed, 12 insertions(+)
diff --git a/package/kernel/linux/modules/crypto.mk
b/package/kernel/linux/modules/crypto.mk
index d70eb92..1add16e 100644
--- a/package/kern
On 3/21/19 6:25 PM, Tomasz Maciej Nowak wrote:
> Hi Hauke,
>
> W dniu 21.03.2019 o 17:57, Hauke Mehrtens pisze:
>> This driver is needed for the I2C mux on the board.
>
> This symbol CONFIG_I2C_MUX_PCA954x is in
> target/linux/mvebu/cortexa72/config-default so it should be also deleted in
> thi
Hi Hauke,
W dniu 21.03.2019 o 17:57, Hauke Mehrtens pisze:
> This driver is needed for the I2C mux on the board.
This symbol CONFIG_I2C_MUX_PCA954x is in
target/linux/mvebu/cortexa72/config-default so it should be also deleted in
this patch.
>
> Signed-off-by: Hauke Mehrtens
> ---
> target/
Currently leds migration scripts in ar71xx and lantiq share a lot of
logic and introducing leds migration to another target would mean
copying this code, again. Therefore add common logic to library in
base-files package.
Suggested-by: Petr Štetiar
Signed-off-by: Petr Štetiar
Signed-off-by: Toma
With transition from ar71xx to ath79 some of devices change their naming
of LEDs. When upgrading from ar71xx target images this will require the
user to adjust previously working configuration. This commit adds
migration script which can be used to rename old names to new ones.
With this previously
This driver is needed for the I2C mux on the board.
Signed-off-by: Hauke Mehrtens
---
target/linux/mvebu/image/cortex-a72.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/mvebu/image/cortex-a72.mk
b/target/linux/mvebu/image/cortex-a72.mk
index ac5b802..df0ace1
The name in the device tree file is written with two C.
Signed-off-by: Hauke Mehrtens
---
target/linux/mvebu/base-files/lib/mvebu.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/mvebu/base-files/lib/mvebu.sh
b/target/linux/mvebu/base-files/lib/mvebu.sh
index
From: Markus Scheck
SOC: Qualcomm Atheros QCA9558
RAM: 128MB
FLASH: 16MB (Macronix MX25L12845EMI-10G)
WLAN1: QCA9558 2.4GHz 802.11bgn 3SS
WLAN2: QCA9880 5GHz 802.11ac 3SS
LED: Power, LAN1, LAN2, 2.4GHz, 5GHz
Serial:Next to SPI Flash,
Pinout is 3V3 - GND - TX - RX (Square Pin is 3V3)
subcribe openwrt-devel___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
SoC: MediaTek MT7621
RAM: 64M (Winbond W9751G6KB-25)
FLASH: 16MB (Macronix MX25L12835F)
WiFi: MediaTek MT7662E bgn 2SS
WiFi: MediaTek MT7662E nac 2SS
BTN: ON/OFF - Reset - WPS - AP/Extender toggle
LED:- Arrow Right (blue)
- Arrow Left (blue)
- WiFi 1 (red/green)
Hi,
On Thu, Mar 21, 2019 at 2:23 PM Bjørn Mork wrote:
>
> Kristian Evensen writes:
>
> > - 2x SIM card slots (full size)
>
> Really? Am I the only one who remember credit card sized SIMs? :-)
>
> They were the only kind we had when GSM was introduced around here in
> 1991/1992. See for example
Kristian Evensen writes:
> - 2x SIM card slots (full size)
Really? Am I the only one who remember credit card sized SIMs? :-)
They were the only kind we had when GSM was introduced around here in
1991/1992. See for example the description of the GSM version of the
MicroTAC Classic:
https://en
ZBT WE826-E is a dual-SIM version of the ZBT WE826. The router has the
following specifications:
- MT7620A (580 MHz)
- 128MB RAM
- 32MB of flash (SPI NOR)
- 5x 10/100Mbps Ethernet (MT7620A built-in switch)
- 1x microSD slot
- 1x miniPCIe slot (only USB2.0 bus)
- 2x SIM card slots (full size)
- 1x
Hi,
> Is there any kind of "official" roadmap/checklist available what "needs"
> to be done?
not that I am aware of, but from the top of my head:
- make sure all targets are ported properly to 4.14
- disable all devices which cannot cannot handle the increased kernel
size anymore
- drop all ta
Sven Eckelmann writes:
> On Saturday, 16 March 2019 13:18:48 CET Xuebing Wang wrote:
> [...]
>> 1) Firmware inside QSDK (QCA closed source?) for AP-DK04.1-C1 based
>> routers.
>> 2) Firmware from kvalo/linux-firmware
>>
>> Are these "2 lines" of firmware essentially the same?
>
> They should
On 2019-03-18 14:10, Petr Štetiar wrote:
Daniel Engberg [2019-03-18 13:55:07]:
Hi,
Having a look at https://www.python.org/dev/peps/pep-0537/#lifespan it
seems
like a good idea to stick with 3.7?
it's a PITA to demand versions which are not packaged in current
versions of LTS
Linux distro
Hi,
Is there any kind of "official" roadmap/checklist available what "needs"
to be done?
Best regards,
Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
31 matches
Mail list logo
