On 2017-10-28 21:59, Florian Fainelli wrote:
I recently updated my Netgear WNDR4300 to LEDE 17.01.4 and the only
thing that appears broken is the USB LED trigger. The LED works fine
and while the USB port is detected, functional, setting it as a
trigger does not make the LED blink. Was there any
Hi,
I'm working on setting IPv6 access on my LEDE router. Unfortunately I
do not find a proper ISATAP support on current distribution.
ISATAP is quite similar to 6in4, except that it needs combining
provider's prefix and local IPv4 address to get the local IPv6
address. On this side it also show
Hi all,
I'm currently trying to use jshn.sh but it changes the data and makes it
unusable.
Below an example:
root@LEDE:~# json_string="{ \"foo-bar\": 10 }"
root@LEDE:~# echo $json_string
{ "foo-bar": 10 }
root@LEDE:~# json_init
root@LEDE:~# json_load "$json_string"
root@LEDE:~# json_dump
{ "foo_
Hi all -
I have pushed an update to kernel 4.9 for ixp4xx to my staging repo at:
https://git.lede-project.org/lede/thess/staging.git ixp4xx-kernel-4.9
I have only tested it on an Actiontec MI424WR and an NSLU2.
Any feedback appreciated. I will merge it soon if no problems arise.
/ted
___
In this rework/cleanup:
- fix pinctrl node name (partially pulled from upstream)
- move xo and times nodes to SoC dtsi (partially pulled from upstream)
- remove crypto nodes from board dts (as those are olready in dtsi)
- move ap-dk01 tcsr nodes to dtsi (as those are common)
- remove counter entry
Signed-off-by: Roman Yeryomin
---
.../arch/arm/boot/dts/qcom-ipq4019-nbg6617.dts | 2 +-
...-v3-1-2-dts-ipq4019-Fix-pinctrl-node-name.patch | 44 ++
...dts-ipq4019-ap-dk04-fix-pinctrl-node-name.patch | 11 ++
3 files changed, 56 insertions(+), 1 deletion(-)
create mo
xo and timer are common thing and it makes more sense to keep them in SoC dtsi
Signed-off-by: Roman Yeryomin
---
...q4019-Move-xo-and-timer-nodes-to-SoC-dtsi.patch | 78 ++
...ipq4019-ap-dk04-remove-xo-and-timer-nodes.patch | 27
2 files changed, 105 insertions(+)
c
crypto and cryptobam are already present in dtsi used by these boards:
- fritz4040
- nbg6617
- rt-ac58u
Signed-off-by: Roman Yeryomin
---
.../files-4.9/arch/arm/boot/dts/qcom-ipq4019-fritz4040.dts| 8
.../ipq806x/files-4.9/arch/arm/boot/dts/qcom-ipq4019-nbg6617.dts | 8
tcsr configuration is the same for all ap-dk01 boards
Signed-off-by: Roman Yeryomin
---
.../arch/arm/boot/dts/qcom-ipq4019-fritz4040.dts | 28 ---
.../arch/arm/boot/dts/qcom-ipq4019-nbg6617.dts | 28 ---
.../arch/arm/boot/dts/qcom-ipq4019-rt-ac58u.dts| 29 --
That is mdio/ethernet and wifi are present on all ap-dk01 boards.
Signed-off-by: Roman Yeryomin
---
.../arch/arm/boot/dts/qcom-ipq4019-fritz4040.dts | 20 --
.../arch/arm/boot/dts/qcom-ipq4019-nbg6617.dts | 24
.../arch/arm/boot/dts/qcom-ipq4019-rt-ac58u.dts
There is no code implementing "qcom,qca-gcnt", so no point in keeping it.
Signed-off-by: Roman Yeryomin
---
.../ipq806x/files-4.9/arch/arm/boot/dts/qcom-ipq4019-fritz4040.dts | 5 -
.../ipq806x/files-4.9/arch/arm/boot/dts/qcom-ipq4019-nbg6617.dts | 5 -
.../ipq806x/files-4.9/arch/a
All ap-dk01 boards have different spi chips, thus no point in keeping it in
dtsi.
Signed-off-by: Roman Yeryomin
---
.../arch/arm/boot/dts/qcom-ipq4019-fritz4040.dts| 6 --
.../arch/arm/boot/dts/qcom-ipq4019-nbg6617.dts | 8
.../arch/arm/boot/dts/qcom-ipq4019-rt-a
Supported frequencies of all ipq40xx chips are 48, 200, 500 and 716.8 MHz.
Previous 666MHz setting was most likely related to instability of early
chips/boards made before mass production.
Signed-off-by: Roman Yeryomin
---
.../files-4.9/arch/arm/boot/dts/qcom-ipq4019-fritz4040.dts | 9
AP-DK01.1-C1 is QCA dev board with:
- ipq4018 quad core ARM @716.8MHz, 2x2 dual (11n+11ac) radio
- 256MB RAM
- 32MB SPI flash
- QCA8075 multiport ethernet phy (WAN port, 4x LAN ports)
First installation via u-boot:
sf probe
sf erase 0x18 0x1a0
tftpboot 0x8400 lede-ipq806x-AP-DK01.1-C1-
On 28 October 2017 at 03:54, Florian Fainelli wrote:
...
>
> Quite frankly, if the goal is just to give Zoltan and Imre a hard time
> and nitpick on everything possible just to delay (purposely or not) the
> remerge, then you are doing a great job at it, but this goes against
> rule #12.
>
No,
On 10/29/2017 09:21 PM, Paul Spooren wrote:
> Hi all,
>
> I'm currently trying to use jshn.sh but it changes the data and makes it
> unusable.
>
> Below an example:
>
> root@LEDE:~# json_string="{ \"foo-bar\": 10 }"
> root@LEDE:~# echo $json_string
> { "foo-bar": 10 }
> root@LEDE:~# json_init
>
16 matches
Mail list logo
