[OpenWrt-Devel] Pending ath79 issues on ar9342 and 4.14/4.19 kernels
Hi,
this is more like my todo list shared with 蝈蝈 (Guo), but I hope, that I
could get some inputs from others as well. I'm aware about following issues
with ath79 on ar9342 so far, and I don't know how to fix some of them
properly. BTW, everything described bellow works fine on ar71xx using 4.14 or
4.19 kernels.
1. MAC reset issue
While converting UBNT Nanostation M XW to ath79, I've found out, that the MAC
isn't properly reset on ath79, resulting in disfunctional networking due to
MAC_CFG2_CRC_EN bit set in AG71XX_REG_MAC_CFG2. My first naive attempt to fix
this issue[A], but I wasn't satisfied with this fix it so I've asked for help
with proper fix.
With the help of blogic/Guo I've found out, that we need to reset MDIO/GMAC in
one step, otherwise resetting of MAC doesn't work. ar71xx does this, but ath79
doesn't, in ath79 we reset MDIO and GMAC separately. I'm able to reset MAC
properly in ath79 with following changes:
{
reset-names = "mac", "mdio";
resets = < 9>, < 22>;
};
and using `devm_reset_control_array_get_exclusive` to reset the MAC. But then
there's issue with MDIO configuration, since MDIO is configured/probed before
MAC reset and issue with fast reset as well, since on ar71xx it's only
reseting GMAC0 (bit 9) so it needs someone with better complete picture to fix
it properly.
2. Different MDIO divider values
I've observed this on UBNT Bullet M XW. On ar71xx it's using
MII_CFG_CLK_DIV_58 fallback value because ag71xx_mdio_get_divider() doesn't
return anything, but on ath79 it's using MII_CFG_CLK_DIV_50 as computed in
ag71xx_mdio_get_divider(). I'm not sure if it has significant impact on
anything.
3. TX hang workaround is not enabled (DMA engine stuck)
On ath79 we enable this workaround only for `qca,ar7240-eth`, but in ar71xx
it's enabled for is_ar724x SoCs (ar724x, ar933x, ar934x, qca9533, tp9343,
qca955x, qca956x). What is correct? To me it seems, that we should enable it
for same set of SoCs in ath79 as well, but I'm not 100% sure.
4. Transmit queue 0 timed out
On ath79 and UBNT Bullet M XW I'm experiencing weird issues during network
setup[B] which I'm able to reproduce easily with following commands:
uci set network.lan.ipaddr='192.168.1.20'
uci commit network
ifup lan
Resulting after some time in:
...
WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:461 dev_watchdog+0x16c/0x280
NETDEV WATCHDOG: eth0 (ag71xx): transmit queue 0 timed out
...
Sometimes I'm not able to use networking anymore, sometimes it's enough to
just ifdown/ifup lan and the network is backup.
While trying to fix this issue, I've found out about 2. and 3., but fixing
them in the same way as on ar71xx doesn't help with this issue. Proper MAC
reset as described in 1. doesn't help with this issue either.
Any idea what might possibly cause this? Dump of registers looks same on
ar71xx/ath79 so it's probably something related to code path changes.
A.
https://github.com/ynezz/openwrt/commit/9d8f7d52072352dd3ecb4a3c5067307903c48346
B. https://github.com/openwrt/openwrt/pull/1635#issuecomment-448638246
-- ynezz
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 5/7] procd: add start-console support
This adds a hotplug function to (re-)start inittab entries with askfirst or
respawn.
At the moment the devices used with these actions must be present during boot
otherwise such lines are skipped.
However, this prevents having inittab entries with consoles for e.g. USB gadget
devices which only appear after kernel module loading and after configuring them
with configfs.
While it was possible to only scan the inittab for the desired item to start,
I assume the inittab to be short and re-running the whole list will be
negligible.
Signed-off-by: Michael Heimpold
---
plug/hotplug.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/plug/hotplug.c b/plug/hotplug.c
index 80e6e4d..6b5960a 100644
--- a/plug/hotplug.c
+++ b/plug/hotplug.c
@@ -297,12 +297,27 @@ send_to_kernel:
exit(-1);
}
+static void handle_start_console(struct blob_attr *msg, struct blob_attr *data)
+{
+ char *dev = blobmsg_get_string(blobmsg_data(data));
+
+ DEBUG(2, "Start console request for %s\n", dev);
+
+ procd_inittab_run("respawn");
+ procd_inittab_run("askfirst");
+
+ DEBUG(2, "Done starting console for %s\n", dev);
+
+ exit(-1);
+}
+
enum {
HANDLER_MKDEV = 0,
HANDLER_RM,
HANDLER_EXEC,
HANDLER_BUTTON,
HANDLER_FW,
+ HANDLER_START_CONSOLE,
};
static struct cmd_handler {
@@ -336,6 +351,10 @@ static struct cmd_handler {
.name = "load-firmware",
.handler = handle_firmware,
},
+ [HANDLER_START_CONSOLE] = {
+ .name = "start-console",
+ .handler = handle_start_console,
+ },
};
static void queue_next(void)
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/7] procd: simplify code in procd_inittab_run
This is a trial to make it more obvious what the historically
grown code is actually doing.
Signed-off-by: Michael Heimpold
---
v2: use Jo-Philipp Wich's proposal
inittab.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/inittab.c b/inittab.c
index 4b9..c9e6c13 100644
--- a/inittab.c
+++ b/inittab.c
@@ -259,12 +259,9 @@ void procd_inittab_run(const char *handler)
list_for_each_entry(a, , list)
if (!strcmp(a->handler->name, handler)) {
- if (a->handler->multi) {
- a->handler->cb(a);
- continue;
- }
a->handler->cb(a);
- break;
+ if (!a->handler->multi)
+ break;
}
}
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 0/7] procd: console hotplugging support
This series extends procd to allow starting consoles for devices which are not present during boot or after kernel module loading. This is for example the case when a USB gadget serial device is created with configfs. Here the kernel module is loaded but the tty device only appears after gadget is configured. Having a console configured in inittab for e.g. ttyGS0 does not work at the moment due to late appearing of this device. The changes in this series are the first step to make this work, the next one would be to extend the hotplug.json script to re-trigger inittab entry processing. The series also includes some nitpicks I stumbled over during coding. It can also be found in a Github repo: https://github.com/mhei/openwrt-procd/tree/console-hotplugging Michael Heimpold (7): procd: simplify code in procd_inittab_run procd: guard fork_worker calls procd: skip respawn in case device disappeared procd: shift arguments for askfirst only once procd: add start-console support procd: add upgraded binary to .gitignore procd: replace exit(-1) with exit(EXIT_FAILURE) .gitignore | 1 + initd/init.c| 2 +- initd/preinit.c | 6 +++--- initd/zram.c| 4 ++-- inittab.c | 48 + plug/coldplug.c | 3 ++- plug/hotplug.c | 31 +++-- upgraded/upgraded.c | 2 +- 8 files changed, 66 insertions(+), 31 deletions(-) -- 2.17.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 6/7] procd: add upgraded binary to .gitignore
Signed-off-by: Michael Heimpold --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 9d80a74..eaf1ef4 100644 --- a/.gitignore +++ b/.gitignore @@ -2,6 +2,7 @@ procd askfirst udevtrigger init +upgraded/upgraded .* Makefile CMakeCache.txt -- 2.17.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 3/7] procd: skip respawn in case device disappeared
Signed-off-by: Michael Heimpold
---
inittab.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/inittab.c b/inittab.c
index b8552e9..18023f5 100644
--- a/inittab.c
+++ b/inittab.c
@@ -123,6 +123,11 @@ static void child_exit(struct uloop_process *proc, int ret)
DEBUG(4, "pid:%d, exitcode:%d\n", proc->pid, ret);
proc->pid = 0;
+ if (!dev_exist(a->id)) {
+ DEBUG(4, "Skipping respawn: device '%s' does not exist
anymore\n", a->id);
+ return;
+ }
+
uloop_timeout_set(>tout, a->respawn);
}
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 7/7] procd: replace exit(-1) with exit(EXIT_FAILURE)
Signed-off-by: Michael Heimpold
---
initd/init.c| 2 +-
initd/preinit.c | 6 +++---
initd/zram.c| 4 ++--
plug/coldplug.c | 3 ++-
plug/hotplug.c | 14 +++---
upgraded/upgraded.c | 2 +-
6 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/initd/init.c b/initd/init.c
index 0349e6e..8d012f6 100644
--- a/initd/init.c
+++ b/initd/init.c
@@ -91,7 +91,7 @@ main(int argc, char **argv)
execvp(kmod[0], kmod);
ERROR("Failed to start kmodloader: %m\n");
- exit(-1);
+ exit(EXIT_FAILURE);
}
if (pid <= 0) {
ERROR("Failed to start kmodloader instance: %m\n");
diff --git a/initd/preinit.c b/initd/preinit.c
index fbb36df..0b0d291 100644
--- a/initd/preinit.c
+++ b/initd/preinit.c
@@ -23,7 +23,7 @@
#include
#include
-
+#include
#include
#include "init.h"
@@ -135,7 +135,7 @@ preinit(void)
if (!plugd_proc.pid) {
execvp(plug[0], plug);
ERROR("Failed to start plugd: %m\n");
- exit(-1);
+ exit(EXIT_FAILURE);
}
if (plugd_proc.pid <= 0) {
ERROR("Failed to start new plugd instance: %m\n");
@@ -157,7 +157,7 @@ preinit(void)
if (!preinit_proc.pid) {
execvp(init[0], init);
ERROR("Failed to start preinit: %m\n");
- exit(-1);
+ exit(EXIT_FAILURE);
}
if (preinit_proc.pid <= 0) {
ERROR("Failed to start new preinit instance: %m\n");
diff --git a/initd/zram.c b/initd/zram.c
index b41bfd9..2f92b3f 100644
--- a/initd/zram.c
+++ b/initd/zram.c
@@ -65,7 +65,7 @@ early_insmod(char *module)
modprobe[1] = path;
execvp(modprobe[0], modprobe);
ERROR("Can't exec %s: %m\n", modprobe[0]);
- exit(-1);
+ exit(EXIT_FAILURE);
}
if (pid <= 0) {
@@ -108,7 +108,7 @@ mount_zram_on_tmp(void)
if (!pid) {
execvp(mkfs[0], mkfs);
ERROR("Can't exec %s: %m\n", mkfs[0]);
- exit(-1);
+ exit(EXIT_FAILURE);
} else if (pid <= 0) {
ERROR("Can't exec %s: %m\n", mkfs[0]);
return -1;
diff --git a/plug/coldplug.c b/plug/coldplug.c
index c6a89c3..e2d1074 100644
--- a/plug/coldplug.c
+++ b/plug/coldplug.c
@@ -16,6 +16,7 @@
#include
#include
+#include
#include
#include "../procd.h"
@@ -55,7 +56,7 @@ void procd_coldplug(void)
if (!udevtrigger.pid) {
execvp(argv[0], argv);
ERROR("Failed to start coldplug: %m\n");
- exit(-1);
+ exit(EXIT_FAILURE);
}
if (udevtrigger.pid <= 0) {
diff --git a/plug/hotplug.c b/plug/hotplug.c
index 6b5960a..ed61490 100644
--- a/plug/hotplug.c
+++ b/plug/hotplug.c
@@ -206,7 +206,7 @@ static void handle_exec(struct blob_attr *msg, struct
blob_attr *data)
argv[i] = NULL;
execvp(argv[0], [0]);
}
- exit(-1);
+ exit(EXIT_FAILURE);
}
static void handle_button_start(struct blob_attr *msg, struct blob_attr *data)
@@ -231,7 +231,7 @@ static void handle_firmware(struct blob_attr *msg, struct
blob_attr *data)
if (!file || !dir || !dev) {
ERROR("Request for unknown firmware %s/%s\n", dir, file);
- exit(-1);
+ exit(EXIT_FAILURE);
}
path = alloca(strlen(dir) + strlen(file) + 2);
@@ -256,11 +256,11 @@ send_to_kernel:
load = open(loadpath, O_WRONLY);
if (!load) {
ERROR("Failed to open %s: %m\n", loadpath);
- exit(-1);
+ exit(EXIT_FAILURE);
}
if (write(load, "1", 1) == -1) {
ERROR("Failed to write to %s: %m\n", loadpath);
- exit(-1);
+ exit(EXIT_FAILURE);
}
close(load);
@@ -268,7 +268,7 @@ send_to_kernel:
fw = open(syspath, O_WRONLY);
if (fw < 0) {
ERROR("Failed to open %s: %m\n", syspath);
- exit(-1);
+ exit(EXIT_FAILURE);
}
len = s.st_size;
@@ -294,7 +294,7 @@ send_to_kernel:
DEBUG(2, "Done loading %s\n", path);
- exit(-1);
+ exit(EXIT_FAILURE);
}
static void handle_start_console(struct blob_attr *msg, struct blob_attr *data)
@@ -308,7 +308,7 @@ static void handle_start_console(struct blob_attr *msg,
struct blob_attr *data)
DEBUG(2, "Done starting console for %s\n", dev);
- exit(-1);
+ exit(EXIT_FAILURE);
}
enum {
diff --git a/upgraded/upgraded.c b/upgraded/upgraded.c
index 0b82f20..db98701 100644
--- a/upgraded/upgraded.c
+++ b/upgraded/upgraded.c
@@ -56,7 +56,7 @@ static void sysupgrade(char *path, char *command)
/* Child */
execvp(args[0], args);
fprintf(stderr, "Failed to
[OpenWrt-Devel] [PATCH 2/7] procd: guard fork_worker calls
Usually respawn(), askfirst(), askconsole() and rcrespawn() are run only
one time to start a worker child for the given inittab entry.
In case we want to allow calling these functions several times, we need
to ensure that we do not start multiple workers at the same time for the
same inittab item.
For this, we can re-use the remembered pid of the worker child,
however, we need to reset this pid to allow a new instance in case the
previous child exited.
Signed-off-by: Michael Heimpold
---
inittab.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/inittab.c b/inittab.c
index c9e6c13..b8552e9 100644
--- a/inittab.c
+++ b/inittab.c
@@ -120,14 +120,17 @@ static void child_exit(struct uloop_process *proc, int
ret)
{
struct init_action *a = container_of(proc, struct init_action, proc);
- DEBUG(4, "pid:%d\n", proc->pid);
-uloop_timeout_set(>tout, a->respawn);
+ DEBUG(4, "pid:%d, exitcode:%d\n", proc->pid, ret);
+ proc->pid = 0;
+
+ uloop_timeout_set(>tout, a->respawn);
}
static void respawn(struct uloop_timeout *tout)
{
struct init_action *a = container_of(tout, struct init_action, tout);
- fork_worker(a);
+ if (!a->proc.pid)
+ fork_worker(a);
}
static void rcdone(struct runqueue *q)
@@ -163,7 +166,8 @@ static void askfirst(struct init_action *a)
a->respawn = 500;
a->proc.cb = child_exit;
- fork_worker(a);
+ if (!a->proc.pid)
+ fork_worker(a);
}
static void askconsole(struct init_action *a)
@@ -197,7 +201,8 @@ static void askconsole(struct init_action *a)
a->respawn = 500;
a->proc.cb = child_exit;
- fork_worker(a);
+ if (!a->proc.pid)
+ fork_worker(a);
}
static void rcrespawn(struct init_action *a)
@@ -206,7 +211,8 @@ static void rcrespawn(struct init_action *a)
a->respawn = 500;
a->proc.cb = child_exit;
- fork_worker(a);
+ if (!a->proc.pid)
+ fork_worker(a);
}
static struct init_handler handlers[] = {
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 4/7] procd: shift arguments for askfirst only once
In case we want to process an inittab item multiple times (e.g. in case
of hotplugging) we must not shift the arguments for askfirst multiple
times. So check whether we already did it.
Signed-off-by: Michael Heimpold
---
inittab.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/inittab.c b/inittab.c
index 18023f5..45118f4 100644
--- a/inittab.c
+++ b/inittab.c
@@ -165,9 +165,12 @@ static void askfirst(struct init_action *a)
}
a->tout.cb = respawn;
- for (i = MAX_ARGS - 1; i >= 1; i--)
- a->argv[i] = a->argv[i - 1];
- a->argv[0] = ask;
+ /* shift arguments only if not yet done */
+ if (a->argv[0] != ask) {
+ for (i = MAX_ARGS - 1; i >= 1; i--)
+ a->argv[i] = a->argv[i - 1];
+ a->argv[0] = ask;
+ }
a->respawn = 500;
a->proc.cb = child_exit;
@@ -200,9 +203,12 @@ static void askconsole(struct init_action *a)
}
a->tout.cb = respawn;
- for (i = MAX_ARGS - 1; i >= 1; i--)
- a->argv[i] = a->argv[i - 1];
- a->argv[0] = ask;
+ /* shift arguments only if not yet done */
+ if (a->argv[0] != ask) {
+ for (i = MAX_ARGS - 1; i >= 1; i--)
+ a->argv[i] = a->argv[i - 1];
+ a->argv[0] = ask;
+ }
a->respawn = 500;
a->proc.cb = child_exit;
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] ath9k broken
I have found that my ath9k-based WiFi card is malfunctioning with recent OpenWrt master builds. I build things myself, but my configuration (both the build configuration and /etc/config/wireless and so on) has not changed other than doing a "git pull" to get the latest source from https://git.openwrt.org/openwrt/openwrt.git. I have a R52n-M miniPCI inside a Microtik RouterBoard 493G. Running iwinfo detects the card and prints the appropriate information. Running ifconfig also prints the card's information. Running "brctl show" shows the WiFi adapter bridged with my Ethernet interface. Despite this, none of my client devices detect a WiFi signal from the card. Has anything changed with respect to how to configure things? Is there a bug in the ath9k driver? -- Mike :wq ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] config: enable some useful features on !SMALL_FLASH devices
Daniel Golle [2019-01-01 17:56:25]: Hi, > On Sun, Dec 30, 2018 at 11:26:58AM +0100, Petr Štetiar wrote: > > Daniel Golle [2018-12-29 06:51:32]: > > > > > config KERNEL_AIO > > > config KERNEL_FHANDLE > > > config KERNEL_FANOTIFY > > > + default y if !SMALL_FLASH > > > > What about `FEATURES += nas` to make it clear and don't abuse SMALL_FLASH. > > This is not necessarily only used on NAS devices. systemd requires > FHANDLE and FANOTIFY (eg. when running inside LXC container), lvm2 > needs AIO. Both could well run on a modern router or SBC having USB or > an SDCARD slot. to me it's still just NAS and container use cases. I'm afraid, that adding more bloat to kernels for devices with USB and MMC/SD card slots would be rejected also. > > > config KERNEL_CGROUPS > > > config KERNEL_CPUSETS > > > config KERNEL_CGROUP_CPUACCT > > > config KERNEL_RESOURCE_COUNTERS > > > config KERNEL_MEMCG > > > config KERNEL_MEMCG_KMEM > > > menuconfig KERNEL_CGROUP_SCHED > > > config KERNEL_FAIR_GROUP_SCHED > > > config KERNEL_RT_GROUP_SCHED > > > config KERNEL_NAMESPACES > > > config KERNEL_LXC_MISC > > > config KERNEL_SECCOMP_FILTER > > > config KERNEL_SECCOMP > > > - default n > > > + default y if !SMALL_FLASH > > > > What about `FEATURES += containers` ? > > From what I understood FEATURES is supposed to reflect hardware > capabilities Well, almost. I've found `squashfs` and `ext4` in there also. > -- all the above are generic software features useful on any device having > the capacity (ie. flash and RAM) to make use of them. But as other Daniel already suggested, !SMALL_FLASH isn't proper group selection either. Speaking about the capacity, did you measured how much those features add to the kernel images? > > Daniel Engberg [2018-12-30 10:21:46]: > > > > > however KERNEL_CGROUPS, config KERNEL_NAMESPACES, config KERNEL_LXC_MISC, > > > KERNEL_SECCOMP_FILTER are very limited use cases to my knowledge and more > > > or > > > less only used on x86*? > > > > There are other quite powerful platforms like mvebu, imx6, ipq etc. where > > you > > could use this as well. > > I use LXC on oxnas/ox820 (ARM11mpcore) and ramips/mt7621 (MIPS1004Kc), Ok, looking at IMAGE_SIZE values for mt7621 yields following results: IMAGE_SIZE := 6016k TP-LINK RE350 v1 IMAGE_SIZE := 7798784 I-O DATA WN-GX300GR IMAGE_SIZE := $(ralink_default_fw_size_4M) MT7621 EVB IMAGE_SIZE := $(ralink_default_fw_size_8M) AP-MT7621A-V60 EVB So it wouldn't be wise to add more bloat into kernels for those devices. > running Debian inside LXC containers (and it's annoying that I can't > use regular OpenWrt releases or buildbot-generated snapshots on the). I would like to do the same, but on the other hand I also understand, why your patch as it is wouldn't be accepted. Our containers/NAS use cases are still very rare, thus it makes no sense to enable those features by default to every other !SMALL_FLASH target. As you can see on mt7621, it's not marked as SMALL_FLASH, yet there are devices which might be considered SMALL_FLASH. Now I realize, that it couldn't be handled with FEATURES anyway, as this is always too broad group selection and ideally you want to enable those features for specific devices only, meaning different kernels, images etc. -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] MIPS stack security and other problems
On Tue, Jan 1, 2019 at 9:44 AM Hauke Mehrtens wrote: > > On 12/18/18 12:46 PM, Hauke Mehrtens wrote: > > On 12/17/18 1:54 AM, Dave Taht wrote: > >> > >> A pretty deep look at home MIPS and arm routers, and a surprising bug in > >> Linux/MIPS - by mudge and co: > >> > >> https://cyber-itl.org/2018/12/07/a-look-at-home-routers-and-linux-mips.html > >> > >> I have no idea if current openwrt, or what prior releases... are subject to > >> the problems they outline. > > > > In the second paper "Build Safety of Software in 28 Popular Home Router" > > [0] they checked the "security" of multiple popular devices, by checking > > if they activate ASLR, Non stack Exec, Relro and stack guards. The best > > device was the Linksys wrt32x and this is based on OpenWrt with not so > > many modifications. ;-) Just something like Samba downgrade to 3.0.37. > > The paper also wonders why the other Linksys devices like the wrt1900ac > > are much worse, but they probably do not use OpenWrt or a much older > > version. The GPL source code tar.gz of the Linksys wrt32x, begins with > > cloning from https://github.com/openwrt/openwrt.git > > > > > > It is also interesting how different this approve to security checking > > is to what the German BSI published in the "BSI TR-03148: Secure > > Broadband Router:" [1]. > > You can build a device which scores 100% in the one and 0% in the other, > > there is no overlap. ;-) > > > > Hauke > > > > > > [0]: > > https://cyber-itl.org/assets/papers/2018/build_safety_of_software_in_28_popular_home_routers.pdf > > [1]: > > https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03148/TR03148.pdf?__blob=publicationFile=2 > > It looks like they ran checksec from > http://github.com/slimm609/checksec.sh on the root file system of the > devices and came up with these results. The numbers for the Linksys > wrt32x look very similar to current OpenWrt master, even for MIPS CPUs. > > I attached two outputs of checksec to this mail from the lantiq target > with a MIP24Kc CPU. One with master and the current default > configuration and one with master + activated ASLR configuration option. > > You can generate these yourself like this: > ../checksec.sh/checksec -d build_dir/target-mips_24kc_musl/root-lantiq/ This is not accurate for some of the busybox symlinks. Some of them are linked to "busybox", giving the proper result. Others to /bin/busybox which gives a result for the local machine. Maybe should be fixed. > > ASLR increases the image size by about 2.8%: > Without ASLR: 5.386.965 bytes > With ASLR: 5.540.565 bytes > > This is caused by increased user space binary size, see for example > busybox binary which is 7% bigger: > Without ASLR: 425.532 bytes > With ASLR: 457.336 bytes > > The fortified function count does not work with fortify-headers, but > only with glibc. With glibc some function calls are getting replaced > with calls to *_chk functions which are taking extra arguments, this is > done by some glibc header magic. For musl libc OpenWrt uses > fortify-headers which overwrites the original functions and inlined some > extra security checks into the calling application. The result should be > similar, so I assume that we have at least in most places similar > security for the glibc fortified functions. > I checked this by compiling an test application and checked the > assembler code, it contained some extra size checks. > > It looks like the detection does not work correctly for kernel modules. > > Currently RELRO is not activated for the following libraries: > root-lantiq/usr/lib/libbz2.so.1.0 > root-lantiq/usr/lib/libbz2.so.1.0.6 > root-lantiq/lib/libgcc_s.so.1 > this looks like a bug. > > For libgcc_s.so.1 also NX is disabled, which is not good. > > Some binaries do not use a stack canary, I assume that these binaries For ramips, it seems to be most binaries for me. Maybe something wrong with the build settings... > just do not have an array on the stack which could be exploited. The > compiler adds stack canaries only to functions which the compiler thinks > need it. > > ASLR is deactivated for root-lantiq/sbin/vdsl_cpe_control, because this > application does not link any more when ASLR is activated, this is a bug > in the package build system. > > Hauke > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: align GL-AR750S boardname to other GL.iNet devices
Hi Christian, On 01.01.2019 18:23, Christian Lamparter wrote: On Tuesday, January 1, 2019 1:03:22 PM CET Christoph Krapp via openwrt-devel wrote: 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. I had this problem (DMARC Reject/Quarantine policy) in the past as well. If you want to fix it you need to convert your account from googlemail.com to gmail.com (and update your git config and commits to reflect the change). As for the patch: -define Device/glinet_ar750s +define Device/glinet_gl-ar750s ATH_SOC := qca9563 DEVICE_TITLE := GL.iNet GL-AR750S DEVICE_PACKAGES := kmod-usb2 kmod-ath10k-ct ath10k-firmware-qca988x-ct IMAGE_SIZE := 16000k SUPPORTED_DEVICES += gl-ar750s endef -TARGET_DEVICES += glinet_ar750s +TARGET_DEVICES += glinet_gl-ar750s The "Device/glinet_ar750s" change to "Device/glinet_gl-ar750s" will likely break sysupgrade from existing "glinet_ar750s" images. This is because the now deprecated glinet_ar750s identifier was not added to the SUPPORTED_DEVICES variable. Other than that, it looks good. And this is fine as there hasn't been any stable release with ath79. Please, keep the correct name only. -- Cheers, Piotr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: align GL-AR750S boardname to other GL.iNet devices
01/01/2019 18:23, Christian Lamparter: The "Device/glinet_ar750s" change to "Device/glinet_gl-ar750s" will likely break sysupgrade from existing "glinet_ar750s" images. This is because the now deprecated glinet_ar750s identifier was not added to the SUPPORTED_DEVICES variable. Other than that, it looks good. Should be fine here, as no ath79 release image for the ar750s exists. At least I only take care of compatibility to release images. Mathias ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: align GL-AR750S boardname to other GL.iNet devices
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 --- > I had this problem (DMARC Reject/Quarantine policy) in the past as well. > If you want to fix it you need to convert your account from googlemail.com > to gmail.com (and update your git config and commits to reflect the change). Thx for the hint. Will try that next time. > The "Device/glinet_ar750s" change to "Device/glinet_gl-ar750s" will likely > break sysupgrade from existing "glinet_ar750s" images. This is because the > now deprecated glinet_ar750s identifier was not added to the > SUPPORTED_DEVICES variable. Other than that, it looks good. As the support for this device got merged 2 days ago i don't think its that important. Furthermore commits like 8ba76d6 & 6e78d54 got merged without the requested addition, even tough these devices are support way longer. Regards, Christoph --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/2] ath79: add support for devolo WiFi pro 1200i
Hardware
CPU: Qualcomm Atheros QCA9558
RAM: 128M DDR2
FLASH: 16MiB
ETH: 1x Atheros AR8035 (PoE in)
WiFi2: QCA9558 2T2R
WiFi5: QCA9880 2T2R
BTN: 1x Reset
LED: 1x LED blue
1x LED red
BEEP: 1x GPIO attached piezo beeper
UART: 3.3V GND TX RX (115200-N-8) (3.3V is square pad)
Header is located next to reset-button
Installation
Make sure you set a password for the root user as prompted on first
setup!
1. Upload OpenWRT sysupgrade image via SSH to the device.
Use /tmp as the destination folder on the device.
User is root, password the one set in the web interface.
2. Install OpenWRT with
> sysupgrade -n -F /tmp/
Signed-off-by: David Bauer
---
.../ath79/base-files/etc/board.d/02_network | 1 +
.../etc/hotplug.d/firmware/11-ath10k-caldata | 1 +
.../ath79/dts/qca9558_devolo_dvl1200i.dts | 51 +++
target/linux/ath79/image/generic.mk | 8 +++
4 files changed, 61 insertions(+)
create mode 100644 target/linux/ath79/dts/qca9558_devolo_dvl1200i.dts
diff --git a/target/linux/ath79/base-files/etc/board.d/02_network
b/target/linux/ath79/base-files/etc/board.d/02_network
index c5c163c6ec..04d68fd533 100755
--- a/target/linux/ath79/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/base-files/etc/board.d/02_network
@@ -10,6 +10,7 @@ ath79_setup_interfaces()
case "$board" in
avm,fritz300e|\
+ devolo,dvl1200i|\
devolo,dvl1750c|\
devolo,dvl1750i|\
ocedo,koala|\
diff --git
a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index bd26f35f50..7adedfef8f 100644
--- a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -88,6 +88,7 @@ case "$FIRMWARE" in
"ath10k/cal-pci-:00:00.0.bin")
case $board in
devolo,dvl1200e|\
+ devolo,dvl1200i|\
devolo,dvl1750c|\
devolo,dvl1750i)
ath10kcal_extract "art" 20480 2116
diff --git a/target/linux/ath79/dts/qca9558_devolo_dvl1200i.dts
b/target/linux/ath79/dts/qca9558_devolo_dvl1200i.dts
new file mode 100644
index 00..5900d8b487
--- /dev/null
+++ b/target/linux/ath79/dts/qca9558_devolo_dvl1200i.dts
@@ -0,0 +1,51 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include
+#include
+
+#include "qca9558_devolo_dvl1xxx.dtsi"
+
+/ {
+ compatible = "devolo,dvl1200i", "qca,qca9557";
+ model = "devolo WiFi pro 1200i";
+
+ aliases {
+ led-boot = _blue;
+ led-failsafe = _red;
+ led-running = _blue;
+ led-upgrade = _red;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ status_blue: status_blue {
+ label = "dvl1200i:blue:status";
+ gpios = < 14 GPIO_ACTIVE_LOW>;
+ default-state = "on";
+ };
+
+ status_red: status_red {
+ label = "dvl1200i:red:status";
+ gpios = < 15 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ beeper {
+ compatible = "gpio-beeper";
+ gpios = < 4 GPIO_ACTIVE_HIGH>;
+ };
+};
+
+ {
+ pll-data = <0xbe00 0x8101 0x80001313>;
+};
+
+_config {
+ rxdv-delay = <3>;
+ rxd-delay = <3>;
+ txen-delay = <3>;
+ txd-delay = <3>;
+ rgmii-enabled = <1>;
+};
diff --git a/target/linux/ath79/image/generic.mk
b/target/linux/ath79/image/generic.mk
index b8c67e1638..db66720130 100644
--- a/target/linux/ath79/image/generic.mk
+++ b/target/linux/ath79/image/generic.mk
@@ -170,6 +170,14 @@ define Device/devolo_dvl1200e
endef
TARGET_DEVICES += devolo_dvl1200e
+define Device/devolo_dvl1200i
+ ATH_SOC := qca9558
+ DEVICE_TITLE := devolo WiFi pro 1200i
+ DEVICE_PACKAGES := kmod-ath10k-ct ath10k-firmware-qca988x-ct
+ IMAGE_SIZE := 15936k
+endef
+TARGET_DEVICES += devolo_dvl1200i
+
define Device/devolo_dvl1750c
ATH_SOC := qca9558
DEVICE_TITLE := devolo WiFi pro 1750c
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] ath79: add support for devolo WiFi pro 1750i
Hardware
CPU: Qualcomm Atheros QCA9558
RAM: 128M DDR2
FLASH: 16MiB
ETH: 1x Atheros AR8035 (PoE in)
WiFi2: QCA9558 3T3R
WiFi5: QCA9880 3T3R
BTN: 1x Reset
LED: 1x LED blue
1x LED red
BEEP: 1x GPIO attached piezo beeper
UART: 3.3V GND TX RX (115200-N-8) (3.3V is square pad)
Header is located next to reset-button
Installation
Make sure you set a password for the root user as prompted on first
setup!
1. Upload OpenWRT sysupgrade image via SSH to the device.
Use /tmp as the destination folder on the device.
User is root, password the one set in the web interface.
2. Install OpenWRT with
> sysupgrade -n -F /tmp/
Signed-off-by: David Bauer
---
.../ath79/base-files/etc/board.d/02_network | 1 +
.../etc/hotplug.d/firmware/11-ath10k-caldata | 3 +-
.../ath79/dts/qca9558_devolo_dvl1750i.dts | 51 +++
target/linux/ath79/image/generic.mk | 8 +++
4 files changed, 62 insertions(+), 1 deletion(-)
create mode 100644 target/linux/ath79/dts/qca9558_devolo_dvl1750i.dts
diff --git a/target/linux/ath79/base-files/etc/board.d/02_network
b/target/linux/ath79/base-files/etc/board.d/02_network
index e24c58e208..c5c163c6ec 100755
--- a/target/linux/ath79/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/base-files/etc/board.d/02_network
@@ -11,6 +11,7 @@ ath79_setup_interfaces()
case "$board" in
avm,fritz300e|\
devolo,dvl1750c|\
+ devolo,dvl1750i|\
ocedo,koala|\
ocedo,raccoon|\
pcs,cap324|\
diff --git
a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 441893a752..bd26f35f50 100644
--- a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -88,7 +88,8 @@ case "$FIRMWARE" in
"ath10k/cal-pci-:00:00.0.bin")
case $board in
devolo,dvl1200e|\
- devolo,dvl1750c)
+ devolo,dvl1750c|\
+ devolo,dvl1750i)
ath10kcal_extract "art" 20480 2116
ath10kcal_patch_mac_crc $(macaddr_add $(mtd_get_mac_binary art
0) -1)
;;
diff --git a/target/linux/ath79/dts/qca9558_devolo_dvl1750i.dts
b/target/linux/ath79/dts/qca9558_devolo_dvl1750i.dts
new file mode 100644
index 00..bd3702eb36
--- /dev/null
+++ b/target/linux/ath79/dts/qca9558_devolo_dvl1750i.dts
@@ -0,0 +1,51 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include
+#include
+
+#include "qca9558_devolo_dvl1xxx.dtsi"
+
+/ {
+ compatible = "devolo,dvl1750i", "qca,qca9557";
+ model = "devolo WiFi pro 1750i";
+
+ aliases {
+ led-boot = _blue;
+ led-failsafe = _red;
+ led-running = _blue;
+ led-upgrade = _red;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ status_blue: status_blue {
+ label = "dvl1750i:blue:status";
+ gpios = < 14 GPIO_ACTIVE_LOW>;
+ default-state = "on";
+ };
+
+ status_red: status_red {
+ label = "dvl1750i:red:status";
+ gpios = < 15 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ beeper {
+ compatible = "gpio-beeper";
+ gpios = < 4 GPIO_ACTIVE_HIGH>;
+ };
+};
+
+ {
+ pll-data = <0xbe00 0x8101 0x80001313>;
+};
+
+_config {
+ rxdv-delay = <3>;
+ rxd-delay = <3>;
+ txen-delay = <3>;
+ txd-delay = <3>;
+ rgmii-enabled = <1>;
+};
diff --git a/target/linux/ath79/image/generic.mk
b/target/linux/ath79/image/generic.mk
index 326633835d..b8c67e1638 100644
--- a/target/linux/ath79/image/generic.mk
+++ b/target/linux/ath79/image/generic.mk
@@ -178,6 +178,14 @@ define Device/devolo_dvl1750c
endef
TARGET_DEVICES += devolo_dvl1750c
+define Device/devolo_dvl1750i
+ ATH_SOC := qca9558
+ DEVICE_TITLE := devolo WiFi pro 1750i
+ DEVICE_PACKAGES := kmod-ath10k-ct ath10k-firmware-qca988x-ct
+ IMAGE_SIZE := 15936k
+endef
+TARGET_DEVICES += devolo_dvl1750i
+
define Device/dlink_dir-825-b1
ATH_SOC := ar7161
DEVICE_TITLE := D-LINK DIR-825 B1
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] MIPS stack security and other problems
On 12/18/18 12:46 PM, Hauke Mehrtens wrote: On 12/17/18 1:54 AM, Dave Taht wrote: A pretty deep look at home MIPS and arm routers, and a surprising bug in Linux/MIPS - by mudge and co: https://cyber-itl.org/2018/12/07/a-look-at-home-routers-and-linux-mips.html I have no idea if current openwrt, or what prior releases... are subject to the problems they outline. In the second paper "Build Safety of Software in 28 Popular Home Router" [0] they checked the "security" of multiple popular devices, by checking if they activate ASLR, Non stack Exec, Relro and stack guards. The best device was the Linksys wrt32x and this is based on OpenWrt with not so many modifications. ;-) Just something like Samba downgrade to 3.0.37. The paper also wonders why the other Linksys devices like the wrt1900ac are much worse, but they probably do not use OpenWrt or a much older version. The GPL source code tar.gz of the Linksys wrt32x, begins with cloning from https://github.com/openwrt/openwrt.git It is also interesting how different this approve to security checking is to what the German BSI published in the "BSI TR-03148: Secure Broadband Router:" [1]. You can build a device which scores 100% in the one and 0% in the other, there is no overlap. ;-) Hauke [0]: https://cyber-itl.org/assets/papers/2018/build_safety_of_software_in_28_popular_home_routers.pdf [1]: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03148/TR03148.pdf?__blob=publicationFile=2 It looks like they ran checksec from http://github.com/slimm609/checksec.sh on the root file system of the devices and came up with these results. The numbers for the Linksys wrt32x look very similar to current OpenWrt master, even for MIPS CPUs. I attached two outputs of checksec to this mail from the lantiq target with a MIP24Kc CPU. One with master and the current default configuration and one with master + activated ASLR configuration option. You can generate these yourself like this: ../checksec.sh/checksec -d build_dir/target-mips_24kc_musl/root-lantiq/ ASLR increases the image size by about 2.8%: Without ASLR: 5.386.965 bytes With ASLR: 5.540.565 bytes This is caused by increased user space binary size, see for example busybox binary which is 7% bigger: Without ASLR: 425.532 bytes With ASLR: 457.336 bytes The fortified function count does not work with fortify-headers, but only with glibc. With glibc some function calls are getting replaced with calls to *_chk functions which are taking extra arguments, this is done by some glibc header magic. For musl libc OpenWrt uses fortify-headers which overwrites the original functions and inlined some extra security checks into the calling application. The result should be similar, so I assume that we have at least in most places similar security for the glibc fortified functions. I checked this by compiling an test application and checked the assembler code, it contained some extra size checks. It looks like the detection does not work correctly for kernel modules. Currently RELRO is not activated for the following libraries: root-lantiq/usr/lib/libbz2.so.1.0 root-lantiq/usr/lib/libbz2.so.1.0.6 root-lantiq/lib/libgcc_s.so.1 this looks like a bug. For libgcc_s.so.1 also NX is disabled, which is not good. Some binaries do not use a stack canary, I assume that these binaries just do not have an array on the stack which could be exploited. The compiler adds stack canaries only to functions which the compiler thinks need it. ASLR is deactivated for root-lantiq/sbin/vdsl_cpe_control, because this application does not link any more when ASLR is activated, this is a bug in the package build system. Hauke RELRO STACK CANARY NXPIE RPATH RUNPATHSymbols FORTIFY Fortified Fortifiable Filename Full RELRO Canary found NX enabledDSO No RPATH No RUNPATH 264 Symbols Yes 0 12 bin-aslr/root-lantiq/usr/lib/libnl-tiny.so Full RELRO Canary found NX enabledDSO No RPATH No RUNPATH 138 Symbols Yes 0 12 bin-aslr/root-lantiq/usr/lib/libip6tc.so.0.1.0 Full RELRO Canary found NX enabledDSO No RPATH No RUNPATH 286 Symbols Yes 0 22 bin-aslr/root-lantiq/usr/lib/libxtables.so.12.2.0 Full RELRO Canary found NX enabledDSO No RPATH No RUNPATH 290 Symbols Yes 0 21 bin-aslr/root-lantiq/usr/lib/libjson-c.so.2 Full RELRO Canary found NX enabledDSO No RPATH No RUNPATH 174 Symbols Yes 0 8 bin-aslr/root-lantiq/usr/lib/libiptext6.so Full RELRO Canary found NX enabledDSO No RPATH No RUNPATH 230 Symbols Yes 0 24
Re: [OpenWrt-Devel] [PATCH] ath79: align GL-AR750S boardname to other GL.iNet devices
On Tuesday, January 1, 2019 1:03:22 PM CET Christoph Krapp via openwrt-devel wrote: > 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. I had this problem (DMARC Reject/Quarantine policy) in the past as well. If you want to fix it you need to convert your account from googlemail.com to gmail.com (and update your git config and commits to reflect the change). As for the patch: >-define Device/glinet_ar750s >+define Device/glinet_gl-ar750s > ATH_SOC := qca9563 > DEVICE_TITLE := GL.iNet GL-AR750S > DEVICE_PACKAGES := kmod-usb2 kmod-ath10k-ct ath10k-firmware-qca988x-ct > IMAGE_SIZE := 16000k > SUPPORTED_DEVICES += gl-ar750s > endef >-TARGET_DEVICES += glinet_ar750s >+TARGET_DEVICES += glinet_gl-ar750s The "Device/glinet_ar750s" change to "Device/glinet_gl-ar750s" will likely break sysupgrade from existing "glinet_ar750s" images. This is because the now deprecated glinet_ar750s identifier was not added to the SUPPORTED_DEVICES variable. Other than that, it looks good. Regards, Christian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] brcm2708: boot-part feature integration
This patch adds the boot-part feature which enables the brcm2708 target move from the custom boot partition size config option to the generic CONFIG_TARGET_KERNEL_PARTSIZE. Note: For people using custom images: Just like with CONFIG_TARGET_ROOTFS_PARTSIZE changing the value can cause sysupgrade to repartition the device! Make sure to have a backup in this case. Signed-off-by: Christian Lamparter --- config/Config-images.in | 1 + target/linux/brcm2708/Makefile| 2 +- target/linux/brcm2708/image/Config.in | 5 - target/linux/brcm2708/image/Makefile | 4 ++-- 4 files changed, 4 insertions(+), 8 deletions(-) delete mode 100644 target/linux/brcm2708/image/Config.in diff --git a/config/Config-images.in b/config/Config-images.in index 245aed098b..a0c7b7a94d 100644 --- a/config/Config-images.in +++ b/config/Config-images.in @@ -270,6 +270,7 @@ menu "Target Images" int "Kernel partition size (in MB)" depends on GRUB_IMAGES || USES_BOOT_PART default 8 if TARGET_apm821xx_sata + default 20 if TARGET_brcm2708 default 16 config TARGET_ROOTFS_PARTSIZE diff --git a/target/linux/brcm2708/Makefile b/target/linux/brcm2708/Makefile index f4dd86767c..11908f5c2f 100644 --- a/target/linux/brcm2708/Makefile +++ b/target/linux/brcm2708/Makefile @@ -10,7 +10,7 @@ include $(TOPDIR)/rules.mk ARCH:=arm BOARD:=brcm2708 BOARDNAME:=Broadcom BCM27xx -FEATURES:=ext4 audio usb usbgadget display gpio fpu squashfs rootfs-part +FEATURES:=ext4 audio usb usbgadget display gpio fpu squashfs rootfs-part boot-part MAINTAINER:=Álvaro Fernández Rojas SUBTARGETS:=bcm2708 bcm2709 bcm2710 diff --git a/target/linux/brcm2708/image/Config.in b/target/linux/brcm2708/image/Config.in deleted file mode 100644 index f7abd9d39d..00 --- a/target/linux/brcm2708/image/Config.in +++ /dev/null @@ -1,5 +0,0 @@ -config BRCM2708_SD_BOOT_PARTSIZE - int "Boot (SD Card) filesystem partition size (in MB)" - depends on TARGET_brcm2708 - default 20 - diff --git a/target/linux/brcm2708/image/Makefile b/target/linux/brcm2708/image/Makefile index f2d8cec326..cd00d7f394 100644 --- a/target/linux/brcm2708/image/Makefile +++ b/target/linux/brcm2708/image/Makefile @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk include $(INCLUDE_DIR)/image.mk FAT32_BLOCK_SIZE=1024 -FAT32_BLOCKS=$(shell echo $$(($(CONFIG_BRCM2708_SD_BOOT_PARTSIZE)*1024*1024/$(FAT32_BLOCK_SIZE +FAT32_BLOCKS=$(shell echo $$(($(CONFIG_TARGET_KERNEL_PARTSIZE)*1024*1024/$(FAT32_BLOCK_SIZE define Build/Compile $(CP) $(LINUX_DIR)/COPYING $(KDIR)/COPYING.linux @@ -44,7 +44,7 @@ endef define Build/sdcard-img ./gen_rpi_sdcard_img.sh $@ $@.boot $(IMAGE_ROOTFS) \ - $(CONFIG_BRCM2708_SD_BOOT_PARTSIZE) $(CONFIG_TARGET_ROOTFS_PARTSIZE) + $(CONFIG_TARGET_KERNEL_PARTSIZE) $(CONFIG_TARGET_ROOTFS_PARTSIZE) endef ### Devices ### -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/2] mac80211: ath10k: remove "ath10k: fix otp failure result" patch
Initially this patch was introduced as a quick fix following
the removal of 936-ath10k_skip_otp_check.patch which caused
multiple ath10k pcie devices in various ipq806x and ar71xx/ath79
targets to malfunction.
Thankfully, the affected devices have been updated to utilize
the pre-caldata method. And finally with the switch to ath10k-ct,
which never had the patch or any reports of similar issues, I
think it's time to remove this patch since it is no longer needed.
Signed-off-by: Christian Lamparter
---
.../ath/936-ath10k-fix-otp-failure-result.patch | 11 ---
1 file changed, 11 deletions(-)
delete mode 100644
package/kernel/mac80211/patches/ath/936-ath10k-fix-otp-failure-result.patch
diff --git
a/package/kernel/mac80211/patches/ath/936-ath10k-fix-otp-failure-result.patch
b/package/kernel/mac80211/patches/ath/936-ath10k-fix-otp-failure-result.patch
deleted file mode 100644
index e1990b8018..00
---
a/package/kernel/mac80211/patches/ath/936-ath10k-fix-otp-failure-result.patch
+++ /dev/null
@@ -1,11 +0,0 @@
a/drivers/net/wireless/ath/ath10k/core.c
-+++ b/drivers/net/wireless/ath/ath10k/core.c
-@@ -943,7 +943,7 @@ static int ath10k_core_get_board_id_from
- if (ret) {
- ath10k_err(ar, "could not execute otp for board id check: %d\n",
- ret);
-- return ret;
-+ return -EOPNOTSUPP;
- }
-
- board_id = MS(result, ATH10K_BMI_BOARD_ID_FROM_OTP);
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] treewide: dts: Unify naming of gpio-keys nodes
Christian Lamparter [2018-12-31 17:41:34]: > I hope you know what you are up against because unless you also do the changes > upstream this will happen again and again. :\ / :) My plan is to first wait for comments here, see if it gets merged eventualy and then start poking upstream. I still didn't received any feedback yet(good sign?) on my last `treewide: dts: Remove default-state=off property...`[1] upstream attempt so I don't know if it's worth the effort. Anyway, I guess, that in most of the cases, people are just copy from the DTS files from the OpenWrt repository and some of them even wonder[2] why they need to use generic `leds` node names if it's not the case in the rest of the DTS files in OpenWrt tree: @mkresin: would you please rename the node to the generic "leds". @arapov: @mkresin, by the way, the rest of *.dts in ramips/ using gpio-leds. Do you still think it is good to deviate from the rest here? 1. https://patchwork.kernel.org/patch/10732465/ 2. https://github.com/openwrt/openwrt/pull/1686#discussion_r244512451 3. https://openwrt.org/submitting-patches#dts_checklist -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] config: enable some useful features on !SMALL_FLASH devices
Hi! On Sun, Dec 30, 2018 at 11:26:58AM +0100, Petr Štetiar wrote: > Daniel Golle [2018-12-29 06:51:32]: > > > config KERNEL_AIO > > config KERNEL_FHANDLE > > config KERNEL_FANOTIFY > > + default y if !SMALL_FLASH > > What about `FEATURES += nas` to make it clear and don't abuse SMALL_FLASH. This is not necessarily only used on NAS devices. systemd requires FHANDLE and FANOTIFY (eg. when running inside LXC container), lvm2 needs AIO. Both could well run on a modern router or SBC having USB or an SDCARD slot. > > > config KERNEL_CGROUPS > > config KERNEL_CPUSETS > > config KERNEL_CGROUP_CPUACCT > > config KERNEL_RESOURCE_COUNTERS > > config KERNEL_MEMCG > > config KERNEL_MEMCG_KMEM > > menuconfig KERNEL_CGROUP_SCHED > > config KERNEL_FAIR_GROUP_SCHED > > config KERNEL_RT_GROUP_SCHED > > config KERNEL_NAMESPACES > > config KERNEL_LXC_MISC > > config KERNEL_SECCOMP_FILTER > > config KERNEL_SECCOMP > > - default n > > + default y if !SMALL_FLASH > > What about `FEATURES += containers` ? From what I understood FEATURES is supposed to reflect hardware capabilities -- all the above are generic software features useful on any device having the capacity (ie. flash and RAM) to make use of them. > > Daniel Engberg [2018-12-30 10:21:46]: > > > however KERNEL_CGROUPS, config KERNEL_NAMESPACES, config KERNEL_LXC_MISC, > > KERNEL_SECCOMP_FILTER are very limited use cases to my knowledge and more or > > less only used on x86*? > > There are other quite powerful platforms like mvebu, imx6, ipq etc. where you > could use this as well. I use LXC on oxnas/ox820 (ARM11mpcore) and ramips/mt7621 (MIPS1004Kc), running Debian inside LXC containers (and it's annoying that I can't use regular OpenWrt releases or buildbot-generated snapshots on the). Cheers Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ath79: align GL-AR750S boardname to other GL.iNet devices
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 ---
As the official device name is GL-AR750S, rename the board accordingly.
Signed-off-by: Christoph Krapp
---
target/linux/ath79/base-files/etc/board.d/02_network | 2 +-
.../base-files/etc/hotplug.d/firmware/11-ath10k-caldata | 9 +++--
...63_glinet_ar750s.dts => qca9563_glinet_gl-ar750s.dts} | 2 +-
target/linux/ath79/image/generic.mk | 4 ++--
4 files changed, 7 insertions(+), 10 deletions(-)
rename target/linux/ath79/dts/{qca9563_glinet_ar750s.dts =>
qca9563_glinet_gl-ar750s.dts} (98%)
diff --git a/target/linux/ath79/base-files/etc/board.d/02_network
b/target/linux/ath79/base-files/etc/board.d/02_network
index e24c58e208..6776506893 100755
--- a/target/linux/ath79/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/base-files/etc/board.d/02_network
@@ -100,7 +100,7 @@ ath79_setup_interfaces()
tplink,tl-wr810n-v2)
ucidef_set_interfaces_lan_wan "eth1" "eth0"
;;
- glinet,ar750s)
+ glinet,gl-ar750s)
ucidef_add_switch "switch0" \
"0@eth0" "2:lan:2" "3:lan:1" "1:wan"
;;
diff --git
a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 441893a752..faee781970 100644
--- a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -99,13 +99,10 @@ case "$FIRMWARE" in
elecom,wrc-1750ghbk2-i)
ath10kcal_extract "ART" 20480 2116
;;
- glinet,ar750s|\
- tplink,re450-v2)
- ath10kcal_extract "art" 20480 2116
- ath10kcal_patch_mac $(macaddr_add $(cat
/sys/class/net/eth0/address) +1)
- ;;
engenius,ews511ap|\
- glinet,gl-x750)
+ glinet,gl-ar750s|\
+ glinet,gl-x750|\
+ tplink,re450-v2)
ath10kcal_extract "art" 20480 2116
ath10kcal_patch_mac $(macaddr_add $(cat
/sys/class/net/eth0/address) +1)
;;
diff --git a/target/linux/ath79/dts/qca9563_glinet_ar750s.dts
b/target/linux/ath79/dts/qca9563_glinet_gl-ar750s.dts
similarity index 98%
rename from target/linux/ath79/dts/qca9563_glinet_ar750s.dts
rename to target/linux/ath79/dts/qca9563_glinet_gl-ar750s.dts
index ab33bc13e3..439acaae85 100644
--- a/target/linux/ath79/dts/qca9563_glinet_ar750s.dts
+++ b/target/linux/ath79/dts/qca9563_glinet_gl-ar750s.dts
@@ -7,7 +7,7 @@
#include "qca956x.dtsi"
/ {
- compatible = "glinet,ar750s", "qca,qca9563";
+ compatible = "glinet,gl-ar750s", "qca,qca9563";
model = "GL.iNet GL-AR750S";
chosen {
diff --git a/target/linux/ath79/image/generic.mk
b/target/linux/ath79/image/generic.mk
index 326633835d..858c1662cc 100644
--- a/target/linux/ath79/image/generic.mk
+++ b/target/linux/ath79/image/generic.mk
@@ -289,14 +289,14 @@ define Device/glinet_gl-ar300m-nor
endef
TARGET_DEVICES += glinet_gl-ar300m-nor
-define Device/glinet_ar750s
+define Device/glinet_gl-ar750s
ATH_SOC := qca9563
DEVICE_TITLE := GL.iNet GL-AR750S
DEVICE_PACKAGES := kmod-usb2 kmod-ath10k-ct ath10k-firmware-qca988x-ct
IMAGE_SIZE := 16000k
SUPPORTED_DEVICES += gl-ar750s
endef
-TARGET_DEVICES += glinet_ar750s
+TARGET_DEVICES += glinet_gl-ar750s
define Device/glinet_gl-x750
ATH_SOC := qca9531
--
2.19.2
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
