[LEDE-DEV] Issues on brcm47xx, Buildbot config

2016-06-04 Thread p . wassi
Related to my last post to the list "brcm47xx legacy broken in trunk?" I'm not sure whether "legacy broken in trunk" is the right terminology. When I started to dig into the problem, I cloned the repo and built the image myself. It worked immediately. To confirm my findings, I downloaded today's

Re: [LEDE-DEV] Issues on brcm47xx, Buildbot config

2016-06-05 Thread p . wassi
Hi jow, I already had CONFIG_KERNEL_KALLSYMS enabled (seems to be default). However, I've checked with the file, you gave me earlier [1]. I was NOT able to reproduce the problem. I.e. buildbot's images do not boot, while mine boot on WRT54G(L) even when using your config. Regarding [1], I did

[LEDE-DEV] brcm47xx legacy broken in trunk?

2016-05-31 Thread p . wassi
Hi there! I've just revived an old WRT54GL and implanted 32MB RAM into it - it works perfectly well :) However, for me, the latest working image seems to be 15.05.1. I installed openwrt-15.05.1-brcm47xx-legacy-squashfs.trx which has kernel 3.18.23 and can see this on the serial console during

Re: [LEDE-DEV] brcm47xx legacy broken in trunk?

2016-05-31 Thread p . wassi
Ok, I did some further tests. First test was with ASUS WL500gpv2: this runs fine on brcm47xx-legacy from trunk. The second test was with an *unmodified* WRT54GL (having only 16MB of RAM) (It's clear, that 16MB is not enough to run trunk, however, it should at least start booting the kernel.)

Re: [LEDE-DEV] brcm47xx legacy broken in trunk?

2016-06-01 Thread p . wassi
There's been a similar issue 6 years ago (seems to be related to Kernel+CFE+NVRAM) https://dev.openwrt.org/ticket/7693 Any hints on where to start debugging? (Adding some printk statements, etc.) Kernel and especially the boot process (handover from CFE to kernel) is pretty new stuff for me.

Re: [LEDE-DEV] brcm47xx legacy broken in trunk?

2016-05-31 Thread p . wassi
> What about: > openwrt-brcm47xx-legacy-standard-squashfs.trx > lede-brcm47xx-legacy-standard-squashfs.trx > ? Can u try them? That's what I meant with > the trx versions of these for the sysupgrade None of them work. The WRT54GL refuses to boot. I do a tftp recovery with Linksys' firmware then.

[LEDE-DEV] [PATCH 0/2] ar71xx: Add support for Ubiquiti UniFi AP AC PRO

2016-05-11 Thread p . wassi
ot;unifiac-lite", then a new target "unifiac-pro" is introduced. These targets then support the following devices: "unifiac-lite" = UniFi AP AC LITE, UniFi AP AC LR (Longrange) "unifiac-pro" = UniFi AP AC PRO (and possibly also -EDU, wh

[LEDE-DEV] [PATCH 1/2] ar71xx: Rename unifiac to unifiac-lite

2016-05-11 Thread p . wassi
From: P.Wassi To avoid confusion with different unifiac devices, rename existing target "unifiac" to "unifiac-lite", before "unifiac-pro" is introduced. Signed-off-by: P.Wassi --- base-files/etc/board.d/02_network |2 - base-files/etc/diag.sh |

Re: [LEDE-DEV] [PATCH ver. B] ramips: unify etc/board.d/01_leds configuration

2016-07-27 Thread p . wassi
put this functionality in ucidef_set_led_usbdev ? No more need to maintain different (local) functions for each platform. Best regards, P. Wassi ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] ramips: Improve Archer C20i support

2016-07-28 Thread p . wassi
From: P.Wassi Improve / finalise TP-Link Archer C20i support. Signed-off-by: P.Wassi --- This patch adds proper LED and Button support and sets up a correct switch configuration. The only missing thing (which is likely to never be fixed) is the 5GHz phy

[LEDE-DEV] [PATCH] ramips: Rename TP-Link Archer C50 LEDs

2016-07-28 Thread p . wassi
From: P.Wassi Rename LEDs in TP-Link Archer C50 from [manufacturer name] to [board name] ("tp-link" -> "c50") Signed-off-by: P.Wassi --- Change done according to information in https://lists.infradead.org/pipermail/lede-dev/2016-July/002050.html

Re: [LEDE-DEV] [PATCH] ramips: Improve Archer C20i support

2016-07-28 Thread p . wassi
Hi Piotr, here we go. I've just sent in a PATCH v2 with the board name as the LED's name. Additionally I've create a patch for the C50 - is there any reason the LEDs of the C50 aren't renamed (yet)? Best regards, P. Wassi > Hello Paul, > > Please use board name instead of manufact

[LEDE-DEV] [PATCH v2] ramips: Improve TP-Link Archer C20i support

2016-07-28 Thread p . wassi
From: P.Wassi Improve / finalise TP-Link Archer C20i support. Signed-off-by: P.Wassi --- This patch adds proper LED and Button support and sets up a correct switch configuration. The only missing thing (which is likely to never be fixed) is the 5GHz phy

Re: [LEDE-DEV] [PATCH] ramips: add get_port_stats to mt7530 swconfig driver

2016-07-23 Thread p . wassi
ard-coded magic constants) Best regards, P. Wassi ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH ver. B] ramips: unify etc/board.d/01_leds configuration

2016-07-23 Thread p . wassi
Hi, you're correct, this patch does not change any behaviour at the moment. I'm currently doing work on a device which requires a non-default USB triggering device. One option is to just use ucidef_set_led_usbdev for this single device. Then there's the option to bring this functionality

Re: [LEDE-DEV] [PATCH ver. B] ramips: unify etc/board.d/01_leds configuration

2016-07-26 Thread p . wassi
ed functions themselves (using default values as parameters like here), or otherwise have some helper functions like set_usb_led and set_wifi_led but not keeping them seperate per target platform, instead having them available globally? Best regards, P. Wassi _

[LEDE-DEV] [PATCH 0/2] ramips: unify etc/board.d/01_leds configuration

2016-07-23 Thread p . wassi
that everything is mixed up and that's not what a *unified* configuration interface should look like. (My personal favourite therefore is version A). Best regars, P. Wassi ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman

[LEDE-DEV] [PATCH ver. A] ramips: unify etc/board.d/01_leds configuration

2016-07-23 Thread p . wassi
From: P.Wassi Remove local set_*_led functions and replace with ucidef_set_led_* Signed-off-by: P.Wassi --- linux/ramips/base-files/etc/board.d/01_leds | 152 +++- 1 file changed, 72 insertions(+), 80 deletions(-) diff -rupN

[LEDE-DEV] [PATCH] ramips: remove indentation in etc/board.d/01_leds

2016-07-23 Thread p . wassi
From: Paul Wassi Remove indentation at end of line in base-files/etc/board.d/01_leds Signed-off-by: Paul Wassi --- linux/ramips/base-files/etc/board.d/01_leds |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -rupN

[LEDE-DEV] [PATCH ver. B] ramips: unify etc/board.d/01_leds configuration

2016-07-23 Thread p . wassi
From: P.Wassi Enhance local set_*_led functions to allow more parameters Signed-off-by: P.Wassi --- linux/ramips/base-files/etc/board.d/01_leds | 148 1 file changed, 74 insertions(+), 74 deletions(-) diff -rupN

[LEDE-DEV] [PATCH] ramips: add get_port_stats to mt7530 swconfig driver

2016-07-23 Thread p . wassi
From: P.Wassi Add get_port_stats function to mt7530 swconfig driver. Signed-off-by: P.Wassi --- If one uses "switch" as a trigger for the LEDs, in order to have the LEDs blinking when there's traffic, swconfig_leds.c needs to have a get_port_stats function from

[LEDE-DEV] OpenVPN capath + cafile uci options

2016-10-27 Thread p . wassi
y, I'd revoke the 'cafile' option - this could be misleading. Best regards, P. Wassi ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [RFC] mvebu: simplify etc/board.d/02_network

2016-10-28 Thread p . wassi
From: Paul Wassi Unify switch configuration on Linksys WRTxx00AC series. LAN = eth0, WAN = eth1 Signed-off-by: Paul Wassi --- In the OpenWrt wiki, it can be seen that the Linksys WRTxx00AC series has a device dependent switch configuration:

[LEDE-DEV] [PATCH] package net/cifs-utils: missing dependency?

2016-10-28 Thread p . wassi
From: Paul Wassi Add dependency to kmod-fs-cifs Signed-off-by: Paul Wassi --- 'cifsmount' alone is not able to mount a SMB share, after having installed kmod-fs-cifs this was possible. So I guess adding kmod-fs-cifs as a dependency to cifsmount is ok. diff

[LEDE-DEV] [PATCH] kirkwood: disable fault LEDs by default

2016-10-22 Thread p . wassi
From: P.Wassi Set the default value for status-fault LEDs to '0' Signed-off-by: P.Wassi --- The kirkwood-dockstar, kirkwood-goflex* and kirkwood-pogoplug devices have one duo-color status LED (green+orange / health+fault). For the dockstar and pogoplug the

[LEDE-DEV] [PATCH] kirkwood: remove redundant code in etc/board.d/02_network

2016-10-23 Thread p . wassi
From: Paul Wassi Remove redundant code: merge boards/cases that share the same network configuration. Signed-off-by: Paul Wassi --- linux/kirkwood/base-files/etc/board.d/02_network | 13 - 1 file changed, 4 insertions(+), 9 deletions(-) diff

[LEDE-DEV] [RFC] brcm47xx: bump kernel to 4.4

2016-10-23 Thread p . wassi
V2 - https://pwassi.privatedns.org/lede/brcm47xx/#wl500gpv2 I know, that there are much more devices on brcm47xx which are untested yet. However, these are the ones I have at home to play with and everything seems to work fine there. So what do you think about the following 'patch'? Best regards, P. Wassi diff --gi

[LEDE-DEV] [PATCH] kirkwood: Add RTC driver to kernel for working hctosys

2016-10-23 Thread p . wassi
From: Paul Wassi Build the RTC driver into the kernel, (and remove the optional module), in order to make hctosys working. (Currently the module is loaded after hctosys has failed previously) Signed-off-by: Paul Wassi --- It's the same on kirkwood, as it is on

Re: [LEDE-DEV] [PATCH] kirkwood: disable fault LEDs by default

2016-10-23 Thread p . wassi
mmm... I'll prepare some patch(es) for the entire kirkwood target. Best regards, P. Wassi ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [RFC] brcm47xx: bump kernel to 4.4

2016-10-25 Thread p . wassi
e WRT54GL (and probably other devices as well?). So it's _not_ a 4.1 -> 4.4 issue! The last kernel, that booted fine on my devices (with buildbot images) was OpenWRT 15.05.1 - 3.18.23 As you've experienced yourself: local images also work fine. With 4.1 and 4.4. Best regar

[LEDE-DEV] [PATCH] package/boot/uboot-kirkwood: bump to upstream 2016.09.01

2016-10-25 Thread p . wassi
From: Paul Wassi Bump U-Boot for Kirkwood to upstream 2016.09.01. Local patches cleaned up and reworked. Rename OpenWrt/LEDE occurrences. Signed-off-by: Paul Wassi --- This patch bumps uboot-kirkwood to 2016.09.01, some of the local patches can be dropped then

[LEDE-DEV] [PATCH] package/boot/uboot-kirkwood: fix default bootcmd for Seagate Dockstar

2016-10-25 Thread p . wassi
From: Paul Wassi Fix the default value for the 'bootcmd' environment variable. Therefore make the default bootcmd work for buildbot's images. Signed-off-by: Paul Wassi --- The images generated for Dockstar (and probably other devices as well) have an

Re: [LEDE-DEV] [RFC] brcm47xx: bump kernel to 4.4

2016-10-25 Thread p . wassi
> Anyway I finally debugged this local vs. buildbot difference to the > CONFIG_KERNEL_KALLSYMS. Images from buildbot have this symbol enabled > which slightly increases kernel size. Enough to stop it from booting > on WRT300N v1. There must be something more... What I had on WRT54GL:

[LEDE-DEV] [PATCH, v2] kirkwood: remove redundant code in etc/board.d/02_network

2016-10-24 Thread p . wassi
From: Paul Wassi Remove redundant code: merge boards/cases that share the same network configuration. Also fix the alphabetical ordering of the cases. Signed-off-by: Paul Wassi --- linux/kirkwood/base-files/etc/board.d/02_network | 15 - 1 file

[LEDE-DEV] [PATCH, v2] package/system/mtd: fix usage message

2016-10-24 Thread p . wassi
From: Paul Wassi Minor fix in the usage message on the explanation of the -p option. Signed-off-by: Paul Wassi --- system/mtd/src/mtd.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/system/mtd/src/mtd.c

Re: [LEDE-DEV] [RFC] brcm47xx: bump kernel to 4.4

2016-10-24 Thread p . wassi
ildbot's images did not boot. (It was kernel 4.1 back then, but it's the exact same behaviour as you describe in the commit message) Additionally builtbot's images worked out-of-the-box on an ASUS WL500gP V2. Best regards, P. Wassi ___ Lede-dev ma

Re: [LEDE-DEV] LED naming convention

2016-11-22 Thread p . wassi
Hi Jonas, thanks for pointing me to > The kernel led naming rules are described in [1] In the meantime I already did a list of all kirkwood devices in LEDE (and of course their LED's names). Depending on where they come from (Kernel or LEDE), I'll send patches to. Best regards, P. Wa

[LEDE-DEV] [PATCH] package/utils/fuse: update to 2.9.7

2016-11-22 Thread p . wassi
From: Paul Wassi Update fuse+libfuse to upstream 2.9.7. Drop the patch for CVE-2015-3202, which is already integrated in the newer version. Rework the other patches. Also switch PKG_SOURCE from @SF to libfuse's github releases. Signed-off-by: Paul Wassi ---

Re: [LEDE-DEV] [RFC] brcm47xx: bump kernel to 4.4

2016-11-22 Thread p . wassi
be coming, I think we can't leave it in this state. Either disable the image generation for that device, or get the image built without KALLSYMS. What do you think about this? Best regards, P. Wassi ___ Lede-dev mailing list Lede-dev@lis

Re: [LEDE-DEV] [PATCH] kernel: update kernel 4.4 to version 4.4.32

2016-11-16 Thread p . wassi
still trying to see if I can improve here, or better put my time into other topics. At the moment I don't see a way I could really do different here (besides using the exact same configuration), so maybe I should look into something different then... Best regards, P.

[LEDE-DEV] [PATCH] kernel: update kernel 4.4 to version 4.4.32

2016-11-15 Thread p . wassi
From: Paul Wassi Refresh patches for all targets that support kernel 4.4. compile/run-tested on kirkwood, ar71xx, brcm47xx. Signed-off-by: Paul Wassi --- This patch is meant to be applied upon 4.4.31! Apply https://patchwork.ozlabs.org/patch/694032/ first.

[LEDE-DEV] [PATCH] package/boot/uboot-kirkwood: bump to upstream 2016.11

2016-11-15 Thread p . wassi
From: Paul Wassi Bump U-Boot for Kirkwood to upstream 2016.11. Local patches refreshed. Signed-off-by: Paul Wassi --- This patch bumps uboot-kirkwood to 2016.11. Compile-tested, run-tested on Seagate Dockstar. package/boot/uboot-kirkwood/Makefile

Re: [LEDE-DEV] [PATCH] kernel: update kernel 4.4 to version 4.4.31

2016-11-16 Thread p . wassi
please directly NAK on the other topic. Best regards, P. Wassi ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] ar71xx: fix drivers/mtd/nand/ar934x_nfc.c

2016-11-15 Thread p . wassi
From: Paul Wassi Fix the incorrect usage of ar934x_nfc_write_page and ar934x_nfc_write_page_raw. Add *page* in the argument list and remove the local variable. Signed-off-by: Paul Wassi --- In the buildlogs of ar71xx-nand [1] you can see a warning >

Re: [LEDE-DEV] [PATCH] ar71xx: fix drivers/mtd/nand/ar934x_nfc.c

2016-11-16 Thread p . wassi
> patch fails to apply to current HEAD. could you check/resend it please Just checked again on a new git clone - everything is fine here. Regards, P. Wassi ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mail

[LEDE-DEV] [PATCH] package/boot/uboot-envtools: add 'dockstar' for kirkwood

2016-11-19 Thread p . wassi
From: Paul Wassi Add board 'dockstar' to known fw_env-configurations. Signed-off-by: Paul Wassi --- In order to get fw_printenv / fw_setenv working out-of-the-box on a dockstar, the /etc/fw_env.config file is needed. This file is usually created by

[LEDE-DEV] LED naming convention

2016-11-15 Thread p . wassi
quilt in order to match (1)? Maybe this would be accepted upstream too, since it's currently not consistent. Best regards, P. Wassi ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] kernel: update kernel 4.4 to version 4.4.31

2016-11-15 Thread p . wassi
it really been missed? Best regards, P. Wassi > + Refresh patches > compile/run-tested on cns3xxx & imx6. > > Signed-off-by: Koen Vandeputte <koen.vandepu...@ncentric.com> > --- > include/kernel-version.mk | 4 ++-- &g

[LEDE-DEV] [PATCH] kernel: update kernel 4.4 to version 4.4.29

2016-10-31 Thread p . wassi
From: Paul Wassi Refresh patches for all targets that support kernel 4.4. compile/run-tested on ar71xx, brcm47xx, kirkwood. Signed-off-by: Paul Wassi --- include/kernel-version.mk |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [LEDE-DEV] [RFC] mvebu: simplify etc/board.d/02_network

2016-10-31 Thread p . wassi
anged. (In fact, only /etc/config/network is touched, but will remain fully compatible to any config which is backup'ed/restored during a sysupgrade) Best regards, P. Wassi ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/m

Re: [LEDE-DEV] [PATCH] kernel: update kernel 4.4 to version 4.4.29

2016-11-01 Thread p . wassi
line renumbering, etc.) > (I'll be sending in .28 -> .30 shortly). I tested 4.4.30 on kirkwood, brcm47xx, ar71xx Best regards, P. Wassi ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] kernel: update kernel 4.4 to version 4.4.30

2016-11-02 Thread p . wassi
se 'problems' (offsets), I'd not notice them a week/weeks later during a kernel upgrade. Or am I overall totally going in the wrong direction and refreshing is not that big deal I'm currently facing? Best regards, P. Wassi ___ Lede-dev mailing list Lede-

Re: [LEDE-DEV] [PATCH] kernel: update kernel 4.4 to version 4.4.30

2016-11-02 Thread p . wassi
(or refreshes that have been missed in previous updates) )? Best regards, P. Wassi ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [RFC] mvebu: simplify etc/board.d/02_network

2016-10-29 Thread p . wassi
egards, P. Wassi ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [RFC] mvebu: simplify etc/board.d/02_network

2016-10-29 Thread p . wassi
> Have you tested your patch on these mvebu devices? or just in theory? I've successfully tested on WRT1200AC, which is affected by this patch. (I.e. eth0 and eth1 are swapped then) That's the only mvebu device I have here right now. ___ Lede-dev

[LEDE-DEV] [PATCH] kernel: update kernel 4.4 to version 4.4.28

2016-10-29 Thread p . wassi
From: Paul Wassi Refresh patches for all targets that support kernel 4.4. compile/run-tested on ar71xx, brcm47xx, kirkwood. Signed-off-by: Paul Wassi --- include/kernel-version.mk |

Re: [LEDE-DEV] [PATCH] kernel: update kernel 4.4 to version 4.4.30

2016-11-02 Thread p . wassi
man target is completely removed! This is not patch refreshing! Looking through the upstream changes 4.4.29->4.4.30 and the list of local LEDE/OpenWrt patches, the only thing required for a bump to 4.4.30 is the change in kernel-version.mk Best regards, P. Wassi [1] Add a space in an empt

Re: [LEDE-DEV] [PATCH] kernel: update kernel 4.4 to version 4.4.30

2016-11-01 Thread p . wassi
tand where I have to adjust my workflow. Best regards, P. Wassi ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] kernel: update kernel 4.4 to version 4.4.30

2016-11-02 Thread p . wassi
gt; overkill and not appropriate I think the change in target/linux/mvebu/patches-4.4/053-ARM-dts-Add-SolidRun-Armada-388-Clearfog-A1-DT-file.patch is to be discussed seperately (and probably not needed or 'harmful' (?) at all), so this patch+refreshing for 4.4.30 shouldn't be applied to the tree as it is. Bes

[LEDE-DEV] Convert ar71xx to devicetree

2016-12-08 Thread p . wassi
r71xx device per device (maybe a SoC at a time). Can this migration be done in live ar71xx, or can there be a clone of this target (like ar71xx-dt)? Who else is working on this? Best regards, P. Wassi ___ Lede-dev mailing list Lede-dev@lists.infradead.

Re: [LEDE-DEV] Convert ar71xx to devicetree

2016-12-08 Thread p . wassi
e *every* device is converted? Best regards, P. Wassi ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Convert ar71xx to devicetree

2016-12-08 Thread p . wassi
ges into logical units and push them somewhere... Best regards, p. Wassi ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Convert ar71xx to devicetree

2016-12-08 Thread p . wassi
orking) Without knowing the reason for this patch, there'd possibly be some need for workarounds if we wanted to have both in one kernel. Best regards, P. Wassi ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinf

Re: [LEDE-DEV] Convert ar71xx to devicetree

2016-12-08 Thread p . wassi
the mach-*.c files. Beginning with a new target, we could start with a *clean* arch directory. Best regards, P. Wassi ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH RFC 2/3] openvpn: use proper quoting of push option in openvpn.config

2016-12-09 Thread p . wassi
ion in the init script? I.e. removing the 'push' option from the append_params list and instead do the workaround for quoatition there. Best regards, P. Wassi ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Convert ar71xx to devicetree

2016-12-09 Thread p . wassi
> Done. Pushed the cleanup commit to my staging tree Thank you, Felix. This commit works perfectly on DT boards :) (I did not test it on non-DT devices) In the meantime I've prepared DT things here: https://github.com/p-wassi/lede-source/tree/ath79_devicetree This branch is compile-tes

Re: [LEDE-DEV] Convert ar71xx to devicetree

2016-12-09 Thread p . wassi
> looks like the link to privatedns.org is causing this. I've just checked on the web server's access log: there was no bot checking the contents of my site, so it must really be related to the URI itself. As this is not the first time, I'm sending these URIs to the list, this 'feature' must

[LEDE-DEV] Model detection for UBNT Rocket Ti master

2016-11-29 Thread p . wassi
quot;)") > [5.964739] procd: - early - > [6.623608] procd: - ubus - As a result, the system is not initalized correctly -> no network, no overlay-fs, ... I'm currently rebuilding to see wheter it's the comment that follows the escaped newline for the first case statemen

Re: [LEDE-DEV] Model detection for UBNT Rocket Ti master

2016-11-29 Thread p . wassi
> I'm currently rebuilding to see wheter it's the comment that follows the > escaped newline > for the first case statement. Ok. A multi-line case statement must not be followed by a comment. My testing device boots up fine again :) Best regards,

Re: [LEDE-DEV] mt7621 cpu stalls - need help testing

2017-06-29 Thread p . wassi
, things apply for 4.9 as well? Thanks, P. Wassi [1]: https://git.lede-project.org/?p=lede/blogic/staging.git;a=commit;h=fbaf5cfccb305730d981757fb573635913c6242a > Hi, > > there have been various bug reports related to mt7621 where one of the > cores seems to have dead locked. w

Re: [LEDE-DEV] [PATCH v2] ramips: add support for Ubiquiti EdgeRouter X-SFP

2017-06-09 Thread p . wassi
ing a config file the router rebooted. Does someone else also have this issue? Best regards, P. Wassi > On 07/06/17 12:10, John Crispin wrote: > > > On 07/06/17 01:36, Sven Roederer wrote: > > John, > > > > just checked with master build f500799 as initrd-kernel. Looks

Re: [LEDE-DEV] [PATCH v2] ramips: add support for Ubiquiti EdgeRouter X-SFP

2017-06-12 Thread p . wassi
not an issue with the Edgerouters but with SQM. My SQM configuration was basically just using cake + piece_of_cake.qos, but that's clearly off topic for now. (I'm also CC'ing this mail to Toke, the maintainer of sqm-scripts). Regards, P. Wassi [1]: > [ 260.61] Task dump for CP

Re: [LEDE-DEV] [PATCH v2] ramips: add support for Ubiquiti EdgeRouter X-SFP

2017-06-09 Thread p . wassi
0x6c/0x84 > [ 260.88] [<803ca838>] schedule_timeout+0x160/0x19c > [ 260.89] [<80078ea0>] rcu_gp_kthread+0x7f4/0x7fc > [ 260.90] [<80044b98>] kthread+0xd8/0xec > [ 260.91] [<8000a318>] ret_from_kernel_thread+0x14/0x1c >From what I've seen now, it's

Re: [LEDE-DEV] [PATCH v2] ramips: add support for Ubiquiti EdgeRouter X-SFP

2017-06-15 Thread p . wassi
000] [<8006a7bc>] generic_handle_irq+0x24/0x3c > [140116.83] [<8000c2c8>] do_IRQ+0x1c/0x34 > [140116.83] [<80202c80>] plat_irq_dispatch+0xb4/0xdc > [140116.83] [<8000a820>] except_vec_vi_end+0xb4/0xc0 @Paul: yeah, FS#764 really seems to be related. Sa

Re: [LEDE-DEV] [PATCH] brcm47xx: relocate loader to higher address

2017-10-08 Thread p . wassi
my compiling machine finishes your ar71xx with kernel 4.9, I'll test this one here :-) Happy to see, that this problem seems to be solved. Regards, P. Wassi ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] brcm47xx: relocate the stack in loader

2017-10-10 Thread p . wassi
> (...) Relocate it to a different memory region which is > still under the 8MB RAM, but in the higher area. Ok, I can confirm that this is working fine with both, the WRT54GL and the WL500GP V2 on Linux 4.9.52. Thanks for debugging and fixing! Regards, P.

Re: [LEDE-DEV] [OpenWrt-Devel] OpenWrt -> LEDE git tree merge

2017-10-23 Thread p . wassi
R at [2] - everything is compile-tested and run-tested on real HW. Best regards, P. Wassi [1]: https://forum.openwrt.org/viewtopic.php?pid=320942#p320942 [2]: https://github.com/lede-project/source/pull/1446 ___ Lede-dev mailing list Lede-dev@lis

Re: [LEDE-DEV] uhttpd problems with env variable in cgi

2017-10-22 Thread p . wassi
/pswd, that border is at >= 16 chars. Anyway, I've landed at libubox - is this a libubox issue, is the blob_buf_init not used as intended, or am I foolish when interpreting pi's member variables after doing blob_buf_init? Regards, P. Wassi ___ Lede-dev

Re: [LEDE-DEV] [PATH] uhttpd: store relative query string offset

2017-10-30 Thread p . wassi
Hi Jo, > please give this patch a try. I was able to reproduce your issue and > this patch fixed the issue for me. Confirmed. Just tested on my devices here. Thanks for fixing! Regards, P. Wassi ___ Lede-dev mailing list Lede-dev@lists.infrade

[LEDE-DEV] brcm63xx not booting on newer kernels (JFFS2)

2018-02-13 Thread p . wassi
provide further information, P. Wassi [0.00] Linux version 4.9.77 (buildbot@builds) (gcc version 5.5.0 (OpenWrt GCC 5.5.0 r6038-13e8d54) ) #0 Mon Feb 12 14:21:43 2018 [0.00] Detected Broadcom 0x6368 CPU revision b2 [0.00] CPU frequency is 400 MHz [0.00] 64MB of RAM

[LEDE-DEV] U-Boot v2018.01 requiring GCC6

2018-02-13 Thread p . wassi
, whether GCC5 is still fine for Kirkwood? While the bootloader may not be that important in day to day business, eventually a 'regular' package might have a requirement for a newer compiler too... Best, P. Wassi [1]: http://git.denx.de/?p=u-boot.git;a=commit;h

Re: [LEDE-DEV] brcm63xx not booting on newer kernels (JFFS2)

2018-02-13 Thread p . wassi
> I just pushed a fix for this. I can now confirm operation on both 4.9 and 4.14 :) Thanks for fixing! P. Wassi ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] kernel version status

2018-02-19 Thread p . wassi
what's the current status here?) Anyway, for ath79: any help needed for converting the mach-files to dts? Best regards, P. Wassi ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] cron problem

2018-02-19 Thread p . wassi
d '7', so you have to use '0' for Sundays there. Maybe this causes the behaviour you perceived. Best regards, P. Wassi ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] LEDE Intel Galileo Gen 2 port

2018-01-01 Thread p . wassi
seen, that the built code is based upon linux 3.18, so the kernel there's quite old. Since then I have put that project aside. (So many other things to do...) Looking forward to hearing from you, Best regards, P. Wassi [1]: https://uk.rs-online.com/web/p/iot-development-kits/1244038/ [2]: https://g