ot-filesystem; 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
cron does not
understand '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
check, 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
> 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
let me know if I
can 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
OpenWrt but have 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
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
PR 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-de
ing another user/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
> (...) 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.
ed?
Once 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
-) I guess, 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
x20
> [140116.83] [<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 see
that it's 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]:
> [
dule+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
just while editing 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
1-1
> uci - 2016-07-04-e1bf4356-1
> uclient-fetch - 2016-12-09-52d955fd-1
> uhttpd - 2016-10-25-1628fa4b-1
> uhttpd-mod-ubus - 2016-10-25-1628fa4b-1
> usign - 2015-07-04-ef641914-1
> wpad-mini - 2016-12-19-ad02e79d-2
Further, when using the 'factory' image in [2] (for th
27; quotation 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
> 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 have
> 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-te
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
o disabled all 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
OR flash working)
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/
witch over to ath79 and lock ar71xx, once *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
ing list, we could convert ar71xx 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
> 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 :)
Bes
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 cas
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@lists.infradead.org
http://lists.
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
---
Compile/run-tested in combination wit
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 rega
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 uci-defaults/30_uboot-envtools but it currentl
Hi Rafal,
ok, then I'll really better stop sending those patches. Anyway, I'll
keep an eye on that, compare upcoming ones to local ones if everything is
fine then and eventually actively come back later to this topic.
Thanks, best regards
ailinglist.
Don't get me wrong, I'm 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 i
> 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
for .32?
If it's for .32 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
rough our local 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
still producing false positives?
Best regards,
P. Wassi
[1]:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/diff/?id=v4.4.31&id2=v4.4.30&dt=2
> + Refresh patches
> compile/run-tested on cns3xxx & imx6.
>
> Signed-off-by: Koen Vandepu
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.
include/kernel-version.mk
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
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
> drivers/mtd/nand/ar934x_nfc.c: In function 'a
alize my mail: is cgroup.c a false
positive of
my script, or has it really been missed?
Best regards,
P. Wassi
> + Refresh patches
> compile/run-tested on cns3xxx & imx6.
>
> Signed-off-by: Koen Vandeputte
> ---
> include/kernel-version.mk |
e more careful at the next patch. If my patch caused those
'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. Wa
lf and one for the
internal
refreshes (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
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
taining the caiman 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 s
get me wrong, I just want to understand 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
flicts, 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
rts which is changed.
(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://l
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 a/include/kernel-version.mk b/include/ker
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 +-
target/linux/brcm2708/patc
> 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 mailin
egards,
P. Wassi
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
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 --git a/net/cifs-utils/Makefile b/net
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:
https://wiki.openwrt.org/toh/linksys/wrt_ac_series#swi
penSSL is able to read.
Anyway, 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
From: Paul Wassi
Bump U-Boot for Kirkwood to upstream 2016.09.01. Local patches
cleaned up and reworked.
Signed-off-by: Paul Wassi
---
This patch bumps uboot-kirkwood to 2016.09.01, some of the local patches
can be dropped then (since already integrated upstream). Other patches
are reworked. Pa
1229451 | FAIL <= this is the untouched kernel with KALLSYMS enabled
1237671 | Ok
1279313 | Ok
So there must be more than just the bare vmlinux-size.
Best regards,
P. Wassi
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists
From: Paul Wassi
The pogo_e02's dts file has its LEDs named "pogo_e02:(...)"
Fix the status-LED's name for this device.
Signed-off-by: Paul Wassi
---
linux/kirkwood/base-files/etc/diag.sh |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/target/linux/kirkwood/base-fi
> 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:
http://lists.
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 _uncompressed_ uImage. The bootcmd is 'bootz
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 (since already integrated upstream
4.1 for the 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
ot'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
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 b/package/system/mtd/src/mtd.c
--- a/package/system/mtd/sr
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 changed, 5 insertions(+), 10 deleti
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 b/package/system/mtd/src/mtd.c
--- a/package/system/mtd/sr
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 imx6 here:
https://patchwork.ozla
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 --git a/target/linux/kirkwood/base-fi
e02:orange:fault"
Hmmm... 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
S WL500gP 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,
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 orange fault LED is enabled by default
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
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
linux/ramips/base-files/etc/board.d/01_leds |
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 (Mediatek MT7610) - due to the missing dr
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 (Mediatek MT7610) - due to the missing dr
directly 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
ify the ucidef_set_led 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
_
From: P.Wassi
Introduce an optional parameter at the local set_usb_led and
set_wifi_led function such that they can take a triggering
device. If no parameter is passed, behaviour is unchanged.
Signed-off-by: P.Wassi
---
This allows use of this functions in future devices, which
do not use USB 1-
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 (addition
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
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 the swconfig driver.
The function
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 a/target/linux/ramips/base-files/etc/board.d/01_leds
b/target/lin
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 a/target/linux/ramips/base-files/etc/board.d/01_leds
b/ta
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 a/target/linux/ramips/base-files/etc/board.d/01_leds
b/target/linux/
s Ok. It's just 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
From: Paul Wassi
Clean-up duplicate cases and fix alphabetical ordering in
base-files/etc/board.d/02_network
Signed-off-by: Paul Wassi
---
linux/ramips/base-files/etc/board.d/02_network | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff -rupN a/target/linux/ramips/bas
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 the
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
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.
Tha
> 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.
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.)
Res
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 st
From: P.Wassi
Add support for the Ubiquiti UniFi AP AC PRO
Signed-off-by: P.Wassi
---
The UniFi AP AC PRO has a built in switch and therefore needs
different Ethernet initialisation/setup. The patch below addresses this
and brings support for the mentioned device.
base-files/etc/board.d/02_netw
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 |
iac-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
From: Paul Wassi
Fix eth0 support for the Ubiquiti UniFi AP AC
Signed-off-by: Paul Wassi
---
In openwrt r48937 a patch was introduced which changes the default behaviour
of ath79_register_eth(). The patch below addresses this issue and provides
proper
device setup. Eth is then working out of th
96 matches
Mail list logo
