With current kernel reaching 5MB uncompressed, several devices failed
to boot. They either fails on lzma decompression or ends up with a
corrupted kernel image. We already faced this problem two years ago
and it was solved by limiting LZMA dictionary size. Our own lzma-loader
extracts data without
Hi, Paul
Thanks for your answers.
How often do you really need to feed the watchdog?
>> 10s a falling edge triggers dog feeding
Why do you have an additional MCU taking care of capturing the level change,
what else isit doing?
>>MCU is also responsible for other functions, external RTC, a
Works fine locally and in my test infrastructure, worst case the CDN ever goes
offline is that it falls back to regular mirrors.
In case you set up your own feeds, the download.pl would still ask the CDN for
your self created package, what could be considered as a privacy leak. Should
this become
On Mon, Apr 13, 2020 at 10:12 AM Adrian Schmutzler <
freif...@adrianschmutzler.de> wrote:
> This is another episode in just-make-it-compile kernel bumps.
>
> This has been built-tested for all devices, but not tested on device.
>
Here is a test of your branch on an Accton MR3201A:
+PHY ID is 002
Hi Li Zhang.
This version looks much better than the first one,
some comments inline.
W dniu 13.04.2020 o 12:26, Li Zhang pisze:
> This patch adds supports for GL-MV1000.
>
> Specification:
> - SOC: Marvell Armada 88F3720 (1GHz)
> - Flash: 16MB (W25Q128FWSIG)
> - RAM: 1GB DDR4
Copy config and patches to kernel 5.4.
Signed-off-by: Adrian Schmutzler
---
target/linux/ath25/config-5.4 | 171 ++
.../ath25/patches-5.4/107-ar5312_gpio.patch | 212 ++
.../ath25/patches-5.4/108-ar2315_gpio.patch | 363
.../patches-5.4/110-ar2313_ethernet.patch |
Between 4.19 and 5.4, mtd parsers have been moved to "parsers"
subdirectory. Based on this, the selection of myloader.o was
also moved to that subdirectory, while the Kconfig and our local
myloader.c file remained in /drivers/mtd.
This resulted in linking errors like the following (on ath25@5.4):
1. Kernel commit e7bfb3fdbde3 ("mtd: Stop updating erase_info->state
and calling mtd_erase_callback()") removed erase_info->state
updates and calls of mtd_erase_callback(). Do the same for our
local MTD driver
2. Use phy_set_max_speed() to limit advertised speed. This is needed
to supp
Update config with make kernel_oldconfig.
Signed-off-by: Adrian Schmutzler
---
target/linux/ath25/config-5.4 | 73 ---
1 file changed, 41 insertions(+), 32 deletions(-)
diff --git a/target/linux/ath25/config-5.4 b/target/linux/ath25/config-5.4
index 4d3f0c697e..3
Refresh patches to make them apply to kernel 5.4.
Signed-off-by: Adrian Schmutzler
---
.../ath25/patches-5.4/107-ar5312_gpio.patch | 20 +--
.../ath25/patches-5.4/108-ar2315_gpio.patch | 18 -
.../patches-5.4/110-ar2313_ethernet.patch | 12 +--
...
This is another episode in just-make-it-compile kernel bumps.
This has been built-tested for all devices, but not tested on device.
Since there is only a few devices, I did not include a testing kernel,
but bumped directly as I do not think anyone will test in master anyway.
Adrian Schmutzler (6
Signed-off-by: Adrian Schmutzler
---
target/linux/ath25/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/ath25/Makefile b/target/linux/ath25/Makefile
index 4fb082edfd..bf897908dd 100644
--- a/target/linux/ath25/Makefile
+++ b/target/linux/ath25/Makefile
@@
Between 4.19 and 5.4, mtd parsers have been moved to "parsers"
subdirectory. Like for myloader.c in the previous patch,
this patch moves tplinkpart.c to the kernel patches, so the
code and the kernel includes are at the same location and
the path can be adjusted per kernel.
While at it, remove som
Between 4.19 and 5.4, mtd parsers have been moved to "parsers"
subdirectory. Based on this, the selection of myloader.o was
also moved to that subdirectory, while the Kconfig and our local
myloader.c file remained in /drivers/mtd.
This resulted in linking errors like the following (on ath25@5.4):
Hi,
> > Note that we do not add devices to stable branch without a special reason.
> I hesitated submitting these patches to the master, since, according to
> OpenWrt website [1]: OpenWrt support for 4/32 devices will end after
> 2019. So, it seemed to me that these devices--being 8/32, after
Hi!
On 11.04.2020 21:56, m...@adrianschmutzler.de wrote:
> Note that we do not add devices to stable branch without a special reason.
I hesitated submitting these patches to the master, since, according to
OpenWrt website [1]: OpenWrt support for 4/32 devices will end after
2019. So, it seemed to
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hi all:
Would you please conside
I've been using something similar on my system and propose the following
patch (first submission to the list, be gentle ;)):
diff --git a/package/base-files/files/etc/profile
b/package/base-files/files/etc/profile
index 0beff1608f..e8350cfd6a 100644
--- a/package/base-files/files/etc/profile
+++ b
Update config with make kernel_oldconfig and copy patch.
Directly switch to kernel 5.4.
Signed-off-by: Adrian Schmutzler
---
I just stupidly copied/refreshed the patch and the config.
Build-tested, run-test required as I have no hardware.
---
target/linux/arc770/Makefile |
This patch adds supports for GL-MV1000.
Specification:
- SOC: Marvell Armada 88F3720 (1GHz)
- Flash: 16MB (W25Q128FWSIG)
- RAM: 1GB DDR4
- Ethernet: 3x GE (1 WAN + 2 LAN)
- EMMC: 8GB EMMC (KLM8G1GETF-B041)
- MicroSD: 1x microSD slot
- USB: 1x
Is there a difference between using pre-built SDK (from
downloads.openwrt.org) vs the toolchain from git for building custom
packages? I've been using SDK, but here and from PMs on the forum I see
toolchain recommended -- why?
Also, I have only been installing only some libs + luci-base
with ./scr
21 matches
Mail list logo
