Re: [LEDE-DEV] openwrt/packages

[Philip Prindeville]

> On Oct 10, 2017, at 3:44 PM, Val Kulkov  wrote:
> 
> What is the most appropriate forum for discussing issues related to
> the community management of openwrt/packages?
> 
> Unless I am missing something, there is no forum, no wiki nor any
> other place for discussing openwrt/packages other than the "Issues"
> section at Github which is dedicated to discussing technical issues
> with particular packages.
> 
> The reason I am asking is that IMO there is quite a bit of easily
> avoidable digital rot at openwrt/packages. I would like to offer my
> thoughts to those who are in charge of openwrt/packages, but I don't
> know who they are and how to reach them.



For most packages, look at the PKG_MAINTAINER in the Makefile.

If there isn’t one, look at the git commit log.

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] KRACK (Key Reinstallation Attacks), now patched upstream in hostapd

[Jim Gettys]

On Mon, Oct 16, 2017 at 6:41 AM, Stijn Tintel  wrote:
> On 16-10-17 13:15, Stijn Tintel wrote:
>> On 16-10-17 13:12, Koen Vandeputte wrote:
>>>
>>> On 2017-10-16 11:48, Nick Lowe wrote:
 Referencing https://www.krackattacks.com/

 Patches can be found at: https://w1.fi/security/2017-1/ and an
 advisory at http://seclists.org/oss-sec/2017/q4/83

 Patches can also be found committed at https://w1.fi/cgit/hostap/log/

 I think we need to get these patches integrated in to LEDE asap, or
 move to the hostapd development branch where there are currently
 committed.
>>> I'm currently updating my patch-in-transit to incorporate these fixes.
>>> http://patchwork.ozlabs.org/patch/823136/
>> Felix already has the patches in his staging tree [1], and we are
>> preparing the 17.01 branch for releasing 17.01.4.
>>
> Sorry, hit sent too soon and forgot to add the URL. Anyway, both master
> and the lede-17.01 branch now contain these fixes.

Outstanding response!

Will this require a upgrade of the base image, or can we just upgrade
packages?  If so,
which ones?
  - Jim
>
> Stijn
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] test at91 target with kernel 4.9

[Ben Whitten]

Hi,

> I added kernel 4.9 support for the at91 target, could someone please
> test this on some device if it is still working and report back so I can
> fix the problems or merge this to master.

Just fired up on my board and I haven't detected any problems so far,
ethernet came up at least.

Ben

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [RFC] at91: fix build of legacy target

[Hauke Mehrtens]

On 10/16/2017 10:03 AM, Mathias Kresin wrote:
> 16.10.2017 00:44, Hauke Mehrtens:
>> Changing the order of the devices fixes the build problem seen by the
>> build bot. I do not understand why this is making any difference at all,
>> this is probably only hiding a different bug.
>>
>> Signed-off-by: Hauke Mehrtens 
>> ---
>>
>> Without this patch I am getting the following error message:
>>
>> cat
>> /home/hauke/openwrt/lede/build_dir/target-arm_arm926ej-s_musl_eabi/linux-at91_legacy/tmp/lede-at91-legacy-tny_a9260-squashfs-factory.bin.dtb
>> >>
>> /home/hauke/openwrt/lede/build_dir/target-arm_arm926ej-s_musl_eabi/linux-at91_legacy/tmp/lede-at91-legacy-tny_a9260-squashfs-factory.bin
>>
>> dd
>> if=/home/hauke/openwrt/lede/build_dir/target-arm_arm926ej-s_musl_eabi/linux-at91_legacy/tmp/lede-at91-legacy-tny_a9260-squashfs-factory.bin
>> of=/home/hauke/openwrt/lede/build_dir/target-arm_arm926ej-s_musl_eabi/linux-at91_legacy/tmp/lede-at91-legacy-tny_a9260-squashfs-factory.bin.new
>> bs= conv=sync
>> dd: invalid number: ''
>> Makefile:74: recipe for target
>> '/home/hauke/openwrt/lede/build_dir/target-arm_arm926ej-s_musl_eabi/linux-at91_legacy/tmp/lede-at91-legacy-tny_a9260-squashfs-factory.bin'
>> failed
>> make[5]: ***
>> [/home/hauke/openwrt/lede/build_dir/target-arm_arm926ej-s_musl_eabi/linux-at91_legacy/tmp/lede-at91-legacy-tny_a9260-squashfs-factory.bin]
>> Error 1
>> make[5]: Leaving directory
>> '/home/hauke/openwrt/lede/target/linux/at91/image'
>> Makefile:24: recipe for target 'install' failed
> 
> Hey Hauke,
> 
> your issue is:
> 
> define Device/Default
>   DTB_SIZE :=
> endef
> 
> define Device/production-dtb
>   $(Device/production)
>   $(Device/dtb)
>   DTB_SIZE := 128k
>   IMAGE/factory.bin := append-dtb | pad-to (DTB_SIZE) \
>   | append-kernel | pad-to (KERNEL_SIZE) | append-ubi
> endef
> 
> The pad-to (DTB_SIZE) references the DTB_SIZE variable from
> Device/Default instead of Device/production-dtb.
> 
> The best would be to move DTB_SIZE := 128k to Device/Default (which is
> safe since we don't have different DTB_SIZE values). Another way to fix
> the issue is to change the pad-to parameter to pad-to $$(DTB_SIZE).
> 
> But I've to admit, I fail to see why it works as intended if you change
> the order of the build code and it's most likely the reason why I didn't
> noticed the issue at the time I merged
> c2f052acaeb480e89d3ce39c47f49ad16b3464ac.
> 
> Mathias

Hi Mathias,

thanks for the help, I created a fix and pushed it with that fix it
builds at least for me, lest see if the build bot is fixed now too.

Probably this depends on the order these two variables have in some
internal representation and this gets affected by other things.

Hauke

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH lede-17.01 1/4] x86/generic: use HIGHMEM64G instead of HIGHMEM4G to fix PAE and Xen + revert

[Baptiste Jonglez]

On 16-10-17, Felix Fietkau wrote:
> On 2017-10-16 09:43, Baptiste Jonglez wrote:
> > Hi,
> > 
> > Any chance to get this patch serie merged to the lede-17.01 branch?
> > As far as I can tell:
> > 
> > - Xen support is still broken in 17.01
> > - this patch serie still applies cleanly
> Done. Sorry for the delay.

Thanks!

Jow, I noticed your subsequent revert in 46e29bd0788, can you explain a
bit more about the rationale?  Isn't it safe to refresh kernel config this
way?

As far as I can tell, all symbols removed by the refresh were redundant
with either the generic config or the x86 target config (except for
CONFIG_X86_X2APIC and CONFIG_ACPI_VIDEO which are not defined anywhere).

Thanks,
Baptiste


signature.asc
Description: PGP signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v2] ipq806x: add ap.dk01.1 board support

[Christian Lamparter]

On Monday, October 16, 2017 10:10:52 PM CEST Roman Yeryomin wrote:
> On 2017-10-16 20:32, Christian Lamparter wrote:
> > Added John, maybe he has more comments.
(This time with the right mail address - sorry)

> >> Changes:
> >> - add partitions
> >> - enable wifi and ethernet
> >> - set max cpu speed to 710MHz
> >> - set memory size to 256MB
> >> - add image generation
> >> - extract pre-cal data from ART partition
> >> 
> >> Wirespeed NAT can be achieved with spreading rx interrupts over 
> >> different
> >> cores. Wifi needs love -- too slow. Could be that latest ath10k helps,
> >> didn't test yet.
> > That "Wifi needs love" stinks of board-2.bin issues. And we had to deal
> > with this before:
> > 
> > 
> > Verify that you have the correct (and up to date) board-2.bin for the 
> > board.
> > please add the board's board-2.bin to the ipq-wifi package.
> 
> I was going to deal with wifi related issues later.
Please don't defere the wireless issue. Fix it now.

In the mail, Michal Kazior who was working for Qualcomm Atheros at the time
stated quite clearly:

"Please don't do that. Your basically pushing bogus data as board data
to the device. I'm a ltittle surprised firmware didn't notice. Anyway,
expect the device to misbehave (crash, hang, regulatory violations)
with this "board.bin"."

and also:

"board-2 is a key-value store of actual board files. Some devices,
notably qca61x4 hw3+ and qca4019 need distinct board files to be
uploaded. Otherwise they fail in various ways."

> >> 
> >> +define Device/AP-DK01.1-C1
> >> +  PROFILES += $$(DEVICE_NAME)
> >> +  DEVICE_TITLE := QCA AP-DK01.1-C1
> >> +  BOARD_NAME := ap-dk01.1-c1
> >> +  DEVICE_DTS := qcom-ipq4019-ap.dk01.1-c1
> >This "qcom-ipq4019-ap.dk01.1-c1" is important later on.
> > 
> >> +  KERNEL_LOADADDR := 0x80208000
> >> +  KERNEL_INSTALL := 1
> >> +  KERNEL_SIZE := 4096k
> >> +  IMAGE_SIZE := 26624k
> >> +  FILESYSTEMS := squashfs
> >> +  $(call Device/FitImage)
> > Any reason why this include is not at the top of the define?
> 
> This is kernel image generation, right before full image.
> Actually I don't understand why it's put on top.
But you did notice that all other devices definitions have it on top as well?
Are you really sure, that you really want to trigger people with OCD to do
make a "cleanup" patch later? You could avoid this altogether right now.

[...]

> >> +@@ -20,6 +20,11 @@
> >> +  model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK01.1";
> >> +  compatible = "qcom,ipq4019";
> > I think this should be "qcom,ipq4019-ap.dk01.1-c1", "qcom,ipq4019".
> > The device-tree folks stick to their rules in the
> > usage-model.txt / 2.2 Platform Identification
> > 
> 
> I didn't change that. And will not in v3, since I'm going to patch 
> qcom-ipq4019-ap.dk01.1-c1.dts
This has to be done! Again the usage-model.txt clearly states that:
"The 'compatible' property contains a sorted list of strings starting
with the *exact name of the machine*, followed by an optional list of
boards it is compatible with sorted from most compatible to least."
(Read the rest of 2.2 Platform Identification as well)

Also, Mathias Kresin has plans to use the first "compatible" entry
as an unique identifier for the userspace scripts. (And remove
ipq806x current custom board identifier script that relies on the
model)

part of this work has already been merged see:
https://github.com/lede-project/source/blob/master/package/base-files/files/lib/preinit/02_sysinfo
 
Since the "qcom,ipq4019" compatible is already used by the AP-DK04.1-C1,
this will cause a conflict with your "AP-DK01.1-C1"... And then the
userspace won't know "which is which".

> >> +  clocks {
> >> + xo: xo {
> >> + compatible = "fixed-clock";
> >> diff --git 
> >> a/target/linux/ipq806x/patches-4.9/864-02-dts-ipq4019-ap.dk01.1-fix-max-cpu-speed.patch
> >>  
> >> b/target/linux/ipq806x/patches-4.9/864-02-dts-ipq4019-ap.dk01.1-fix-max-cpu-speed.patch
> >> new file mode 100644
> >> index 000..e9540f4
> >> --- /dev/null
> >> +++ 
> >> b/target/linux/ipq806x/patches-4.9/864-02-dts-ipq4019-ap.dk01.1-fix-max-cpu-speed.patch
> >> @@ -0,0 +1,15 @@
> >> +--- a/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
> >>  b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
> >> +@@ -135,3 +135,12 @@
> >> +  };
> >> +  };
> >> + };
> >> ++
> >> ++&cpu0_opp_table {
> >> ++ /delete-node/ opp@66600;
> >> ++
> >> ++ opp@71000 {
> >> ++ opp-hz = /bits/ 64 <71000>;
> >> ++ clock-latency-ns = <256000>;
> >> ++ };
> >> ++};
> > This looks rather familiar. Like exactly a 1:1 copy from the FB4040's 
> > dts
> > right here:
> > https://github.com/lede-project/source/blob/master/target/linux/ipq806x/files-4.9/arch/arm/boot/dts/qcom-ipq4019-fritz4040.dts#L286
> > Is this true?
> > 
> > There's a reason to stick with th

Re: [LEDE-DEV] KRACK (Key Reinstallation Attacks), now patched upstream in hostapd

[Dave Taht]

+10 on the rapid response! I lost a lot of sleep over this last night.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Serial data getting lost - bug or a feature?

[Valent Turkovic]

Hi,
I'm working with Lede on ar71xx platform (Carambola2 wifi module) to
gather sensor data over serial, save it and transfer it to "could".

Previous firmware was based on OpenWrt Chaos Calmer but latest one is
based upon Lede 17.01.01. I'll test it also with 17.01.03 soon.

What I have discovered is that now with using Lede sometimes there are
missing characters while reading data from serial connection.

Data is not constantly being read, but sensor device is logging data
usually for 8 hours and then data is read via serial in one big
"download". During these downloads I have never seen a character go
missing while Chaos Calmer was used.

What was even stranger is that sometimes I did get these "bad logs"
(ie ones with few missing characters) but sometimes log download went
perfectly!

After some head scratching and troubleshooting I managed to reproduce
this "bug" 100% and it was due to wifi! But only if wifi was enabled
and not being used!

So if radio was enabled, in sta mode but not connected to AP errors
would happen! It I would disable wifi or if radio was associated with
AP then there would be no errors during reading data from serial
connection.

Is there any explanation for this behaviour? Is this a bug or a
feature? Is there any change between OpenWrt CC version and Lede that
could explain this?

Thanks in advance for any insight and answers,
Valent.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v2] ipq806x: add ap.dk01.1 board support

[Roman Yeryomin]

On 2017-10-16 20:32, Christian Lamparter wrote:

Added John, maybe he has more comments.

On Monday, October 16, 2017 5:04:19 PM CEST Roman Yeryomin wrote:

AP.DK01.1 is QCA dev board with:
- ipq4028 (quad core ARM @710MHz, 2x2 dual an+ac radios)

   ^^ might not be correct. more to this below.

- 256MB RAM
- 32MB SPI flash
- QCA8075 ethernet switch (WAN port, 4x LAN ports)

First installation via u-boot:
sf probe
sf erase 0x18 0x1a0
tftpboot 0x8400 lede-ipq806x-AP-DK01.1-C1-squashfs-sysupgrade.bin
sf write 0x8400 0x18 0x1a0

From what I know, tftpboot sets $filesize enviroment variable. This has
the advantage that you don't need to write all the 
random?/uninitialized

memory to the flash. After all 0x1a0 is like 26MiB.


I didn't actually, but also didn't know about $filesize, thanks for the 
hint



Changes:
- add partitions
- enable wifi and ethernet
- set max cpu speed to 710MHz
- set memory size to 256MB
- add image generation
- extract pre-cal data from ART partition

Wirespeed NAT can be achieved with spreading rx interrupts over 
different

cores. Wifi needs love -- too slow. Could be that latest ath10k helps,
didn't test yet.

That "Wifi needs love" stinks of board-2.bin issues. And we had to deal
with this before:


Verify that you have the correct (and up to date) board-2.bin for the 
board.

please add the board's board-2.bin to the ipq-wifi package.


I was going to deal with wifi related issues later.


Changes since v1:
- add hw description and install instruction

Signed-off-by: Roman Yeryomin 
---
 .../etc/hotplug.d/firmware/11-ath10k-caldata   |  6 ++
 target/linux/ipq806x/base-files/lib/ipq806x.sh |  3 +
 target/linux/ipq806x/image/Makefile| 18 -
 ...s-ipq4019-ap.dk01.1-add-256MB-memory-node.patch | 14 
 ...2-dts-ipq4019-ap.dk01.1-fix-max-cpu-speed.patch | 15 
 ...4-03-dts-ipq4019-ap.dk01.1-add-partitions.patch | 72 
++
 ...pq4019-ap.dk01.1-enable-wifi-and-ethernet.patch | 87 
++

 7 files changed, 214 insertions(+), 1 deletion(-)
 create mode 100644 
target/linux/ipq806x/patches-4.9/864-01-dts-ipq4019-ap.dk01.1-add-256MB-memory-node.patch
 create mode 100644 
target/linux/ipq806x/patches-4.9/864-02-dts-ipq4019-ap.dk01.1-fix-max-cpu-speed.patch
 create mode 100644 
target/linux/ipq806x/patches-4.9/864-03-dts-ipq4019-ap.dk01.1-add-partitions.patch
 create mode 100644 
target/linux/ipq806x/patches-4.9/864-04-dts-ipq4019-ap.dk01.1-enable-wifi-and-ethernet.patch


diff --git a/target/linux/ipq806x/image/Makefile 
b/target/linux/ipq806x/image/Makefile

index 3a76c7f..60b3a71 100644
--- a/target/linux/ipq806x/image/Makefile
+++ b/target/linux/ipq806x/image/Makefile
@@ -264,7 +264,23 @@ define Device/AP-DK04.1-C1
DEVICE_TITLE := QCA AP-DK04.1-C1
 endef

+define Device/AP-DK01.1-C1
+   PROFILES += $$(DEVICE_NAME)
+   DEVICE_TITLE := QCA AP-DK01.1-C1
+   BOARD_NAME := ap-dk01.1-c1
+   DEVICE_DTS := qcom-ipq4019-ap.dk01.1-c1

   This "qcom-ipq4019-ap.dk01.1-c1" is important later on.


+   KERNEL_LOADADDR := 0x80208000
+   KERNEL_INSTALL := 1
+   KERNEL_SIZE := 4096k
+   IMAGE_SIZE := 26624k
+   FILESYSTEMS := squashfs
+   $(call Device/FitImage)

Any reason why this include is not at the top of the define?


This is kernel image generation, right before full image.
Actually I don't understand why it's put on top.


+   IMAGES := sysupgrade.bin
+	IMAGE/sysupgrade.bin := append-kernel | pad-to {KERNEL_SIZE} | 
append-rootfs | pad-rootfs | append-metadata

+   DEVICE_PACKAGES := ath10k-firmware-qca4019
+endef
+
 TARGET_DEVICES += AP148 AP148-legacy C2600 D7800 DB149 EA8500 
FRITZ4040 R7500 \

- R7500v2 R7800 NBG6817 VR2600v AP-DK04.1-C1
+ R7500v2 R7800 NBG6817 VR2600v AP-DK04.1-C1 AP-DK01.1-C1

 $(eval $(call BuildImage))
diff --git 
a/target/linux/ipq806x/patches-4.9/864-01-dts-ipq4019-ap.dk01.1-add-256MB-memory-node.patch 
b/target/linux/ipq806x/patches-4.9/864-01-dts-ipq4019-ap.dk01.1-add-256MB-memory-node.patch

new file mode 100644
index 000..8a80979
--- /dev/null
+++ 
b/target/linux/ipq806x/patches-4.9/864-01-dts-ipq4019-ap.dk01.1-add-256MB-memory-node.patch

@@ -0,0 +1,14 @@
+--- a/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
 b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi

Why are you patching the qcom-ipq4019-ap.dk01.1.dtsi?
And not the qcom-ipq4019-ap.dk01.1-c1.dts?


Hmm, missed that one.


+@@ -20,6 +20,11 @@
+   model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK01.1";
+   compatible = "qcom,ipq4019";

I think this should be "qcom,ipq4019-ap.dk01.1-c1", "qcom,ipq4019".
The device-tree folks stick to their rules in the
usage-model.txt / 2.2 Platform Identification



I didn't change that. And will not in v3, since I'm g

Re: [LEDE-DEV] [PATCH v2] ipq806x: add ap.dk01.1 board support

[Christian Lamparter]

Added John, maybe he has more comments.

On Monday, October 16, 2017 5:04:19 PM CEST Roman Yeryomin wrote:
> AP.DK01.1 is QCA dev board with:
> - ipq4028 (quad core ARM @710MHz, 2x2 dual an+ac radios)
   ^^ might not be correct. more to this below.
> - 256MB RAM
> - 32MB SPI flash
> - QCA8075 ethernet switch (WAN port, 4x LAN ports)
> 
> First installation via u-boot:
> sf probe
> sf erase 0x18 0x1a0
> tftpboot 0x8400 lede-ipq806x-AP-DK01.1-C1-squashfs-sysupgrade.bin
> sf write 0x8400 0x18 0x1a0
>From what I know, tftpboot sets $filesize enviroment variable. This has
the advantage that you don't need to write all the random?/uninitialized
memory to the flash. After all 0x1a0 is like 26MiB.

> Changes:
> - add partitions
> - enable wifi and ethernet
> - set max cpu speed to 710MHz
> - set memory size to 256MB
> - add image generation
> - extract pre-cal data from ART partition
> 
> Wirespeed NAT can be achieved with spreading rx interrupts over different
> cores. Wifi needs love -- too slow. Could be that latest ath10k helps,
> didn't test yet.
That "Wifi needs love" stinks of board-2.bin issues. And we had to deal
with this before:


Verify that you have the correct (and up to date) board-2.bin for the board.
please add the board's board-2.bin to the ipq-wifi package.
> Changes since v1:
> - add hw description and install instruction
> 
> Signed-off-by: Roman Yeryomin 
> ---
>  .../etc/hotplug.d/firmware/11-ath10k-caldata   |  6 ++
>  target/linux/ipq806x/base-files/lib/ipq806x.sh |  3 +
>  target/linux/ipq806x/image/Makefile| 18 -
>  ...s-ipq4019-ap.dk01.1-add-256MB-memory-node.patch | 14 
>  ...2-dts-ipq4019-ap.dk01.1-fix-max-cpu-speed.patch | 15 
>  ...4-03-dts-ipq4019-ap.dk01.1-add-partitions.patch | 72 ++
>  ...pq4019-ap.dk01.1-enable-wifi-and-ethernet.patch | 87 
> ++
>  7 files changed, 214 insertions(+), 1 deletion(-)
>  create mode 100644 
> target/linux/ipq806x/patches-4.9/864-01-dts-ipq4019-ap.dk01.1-add-256MB-memory-node.patch
>  create mode 100644 
> target/linux/ipq806x/patches-4.9/864-02-dts-ipq4019-ap.dk01.1-fix-max-cpu-speed.patch
>  create mode 100644 
> target/linux/ipq806x/patches-4.9/864-03-dts-ipq4019-ap.dk01.1-add-partitions.patch
>  create mode 100644 
> target/linux/ipq806x/patches-4.9/864-04-dts-ipq4019-ap.dk01.1-enable-wifi-and-ethernet.patch
> 
> diff --git a/target/linux/ipq806x/image/Makefile 
> b/target/linux/ipq806x/image/Makefile
> index 3a76c7f..60b3a71 100644
> --- a/target/linux/ipq806x/image/Makefile
> +++ b/target/linux/ipq806x/image/Makefile
> @@ -264,7 +264,23 @@ define Device/AP-DK04.1-C1
>   DEVICE_TITLE := QCA AP-DK04.1-C1
>  endef
>  
> +define Device/AP-DK01.1-C1
> + PROFILES += $$(DEVICE_NAME)
> + DEVICE_TITLE := QCA AP-DK01.1-C1
> + BOARD_NAME := ap-dk01.1-c1
> + DEVICE_DTS := qcom-ipq4019-ap.dk01.1-c1
   This "qcom-ipq4019-ap.dk01.1-c1" is important later on.

> + KERNEL_LOADADDR := 0x80208000
> + KERNEL_INSTALL := 1
> + KERNEL_SIZE := 4096k
> + IMAGE_SIZE := 26624k
> + FILESYSTEMS := squashfs
> + $(call Device/FitImage)
Any reason why this include is not at the top of the define?

> + IMAGES := sysupgrade.bin
> + IMAGE/sysupgrade.bin := append-kernel | pad-to {KERNEL_SIZE} | 
> append-rootfs | pad-rootfs | append-metadata
> + DEVICE_PACKAGES := ath10k-firmware-qca4019
> +endef
> +
>  TARGET_DEVICES += AP148 AP148-legacy C2600 D7800 DB149 EA8500 FRITZ4040 
> R7500 \
> -   R7500v2 R7800 NBG6817 VR2600v AP-DK04.1-C1
> +   R7500v2 R7800 NBG6817 VR2600v AP-DK04.1-C1 AP-DK01.1-C1
>  
>  $(eval $(call BuildImage))
> diff --git 
> a/target/linux/ipq806x/patches-4.9/864-01-dts-ipq4019-ap.dk01.1-add-256MB-memory-node.patch
>  
> b/target/linux/ipq806x/patches-4.9/864-01-dts-ipq4019-ap.dk01.1-add-256MB-memory-node.patch
> new file mode 100644
> index 000..8a80979
> --- /dev/null
> +++ 
> b/target/linux/ipq806x/patches-4.9/864-01-dts-ipq4019-ap.dk01.1-add-256MB-memory-node.patch
> @@ -0,0 +1,14 @@
> +--- a/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
>  b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
Why are you patching the qcom-ipq4019-ap.dk01.1.dtsi?
And not the qcom-ipq4019-ap.dk01.1-c1.dts?

> +@@ -20,6 +20,11 @@
> + model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK01.1";
> + compatible = "qcom,ipq4019";
I think this should be "qcom,ipq4019-ap.dk01.1-c1", "qcom,ipq4019".
The device-tree folks stick to their rules in the 
usage-model.txt / 2.2 Platform Identification


> + 
> ++memory {
> ++device_type = "memory";
> ++reg = <0x8000 0x1000>;
> ++};
> ++
This shouldn't be in the .dtsi. Not all IPQ4019 have 256MiBs of RAM.
The ASUS RT-AC58U only has 128 MiB. And on the o

[LEDE-DEV] [PATCH v2] ipq806x: add ap.dk01.1 board support

[Roman Yeryomin]

AP.DK01.1 is QCA dev board with:
- ipq4028 (quad core ARM @710MHz, 2x2 dual an+ac radios)
- 256MB RAM
- 32MB SPI flash
- QCA8075 ethernet switch (WAN port, 4x LAN ports)

First installation via u-boot:
sf probe
sf erase 0x18 0x1a0
tftpboot 0x8400 lede-ipq806x-AP-DK01.1-C1-squashfs-sysupgrade.bin
sf write 0x8400 0x18 0x1a0

Further via sysupgrade.

Changes:
- add partitions
- enable wifi and ethernet
- set max cpu speed to 710MHz
- set memory size to 256MB
- add image generation
- extract pre-cal data from ART partition

Wirespeed NAT can be achieved with spreading rx interrupts over different
cores. Wifi needs love -- too slow. Could be that latest ath10k helps,
didn't test yet.

Changes since v1:
- add hw description and install instruction

Signed-off-by: Roman Yeryomin 
---
 .../etc/hotplug.d/firmware/11-ath10k-caldata   |  6 ++
 target/linux/ipq806x/base-files/lib/ipq806x.sh |  3 +
 target/linux/ipq806x/image/Makefile| 18 -
 ...s-ipq4019-ap.dk01.1-add-256MB-memory-node.patch | 14 
 ...2-dts-ipq4019-ap.dk01.1-fix-max-cpu-speed.patch | 15 
 ...4-03-dts-ipq4019-ap.dk01.1-add-partitions.patch | 72 ++
 ...pq4019-ap.dk01.1-enable-wifi-and-ethernet.patch | 87 ++
 7 files changed, 214 insertions(+), 1 deletion(-)
 create mode 100644 
target/linux/ipq806x/patches-4.9/864-01-dts-ipq4019-ap.dk01.1-add-256MB-memory-node.patch
 create mode 100644 
target/linux/ipq806x/patches-4.9/864-02-dts-ipq4019-ap.dk01.1-fix-max-cpu-speed.patch
 create mode 100644 
target/linux/ipq806x/patches-4.9/864-03-dts-ipq4019-ap.dk01.1-add-partitions.patch
 create mode 100644 
target/linux/ipq806x/patches-4.9/864-04-dts-ipq4019-ap.dk01.1-enable-wifi-and-ethernet.patch

diff --git 
a/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata 
b/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 39757eb..271667f 100644
--- a/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -50,6 +50,9 @@ case "$FIRMWARE" in
fritz4040)
/usr/bin/fritz_cal_extract -i 1 -s 0x400 -e 0x207 -l 12064 -o 
/lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader_config")
;;
+   ap-dk01.1-c1)
+   ath10kcal_extract "ART" 4096 12064
+   ;;
esac
;;
 "ath10k/pre-cal-ahb-a80.wifi.bin")
@@ -57,6 +60,9 @@ case "$FIRMWARE" in
fritz4040)
/usr/bin/fritz_cal_extract -i 1 -s 0x400 -e 0x208 -l 12064 -o 
/lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader_config")
;;
+   ap-dk01.1-c1)
+   ath10kcal_extract "ART" 20480 12064
+   ;;
esac
;;
 
diff --git a/target/linux/ipq806x/base-files/lib/ipq806x.sh 
b/target/linux/ipq806x/base-files/lib/ipq806x.sh
index e8ff7ea..940c7ef 100644
--- a/target/linux/ipq806x/base-files/lib/ipq806x.sh
+++ b/target/linux/ipq806x/base-files/lib/ipq806x.sh
@@ -14,6 +14,9 @@ ipq806x_board_detect() {
machine=$(cat /proc/device-tree/model)
 
case "$machine" in
+   *"AP-DK01.1-C1")
+   name="ap-dk01.1-c1"
+   ;;
*"AP148")
name="ap148"
;;
diff --git a/target/linux/ipq806x/image/Makefile 
b/target/linux/ipq806x/image/Makefile
index 3a76c7f..60b3a71 100644
--- a/target/linux/ipq806x/image/Makefile
+++ b/target/linux/ipq806x/image/Makefile
@@ -264,7 +264,23 @@ define Device/AP-DK04.1-C1
DEVICE_TITLE := QCA AP-DK04.1-C1
 endef
 
+define Device/AP-DK01.1-C1
+   PROFILES += $$(DEVICE_NAME)
+   DEVICE_TITLE := QCA AP-DK01.1-C1
+   BOARD_NAME := ap-dk01.1-c1
+   DEVICE_DTS := qcom-ipq4019-ap.dk01.1-c1
+   KERNEL_LOADADDR := 0x80208000
+   KERNEL_INSTALL := 1
+   KERNEL_SIZE := 4096k
+   IMAGE_SIZE := 26624k
+   FILESYSTEMS := squashfs
+   $(call Device/FitImage)
+   IMAGES := sysupgrade.bin
+   IMAGE/sysupgrade.bin := append-kernel | pad-to {KERNEL_SIZE} | 
append-rootfs | pad-rootfs | append-metadata
+   DEVICE_PACKAGES := ath10k-firmware-qca4019
+endef
+
 TARGET_DEVICES += AP148 AP148-legacy C2600 D7800 DB149 EA8500 FRITZ4040 R7500 \
- R7500v2 R7800 NBG6817 VR2600v AP-DK04.1-C1
+ R7500v2 R7800 NBG6817 VR2600v AP-DK04.1-C1 AP-DK01.1-C1
 
 $(eval $(call BuildImage))
diff --git 
a/target/linux/ipq806x/patches-4.9/864-01-dts-ipq4019-ap.dk01.1-add-256MB-memory-node.patch
 
b/target/linux/ipq806x/patches-4.9/864-01-dts-ipq4019-ap.dk01.1-add-256MB-memory-node.patch
new file mode 100644
index 000..8a80979
--- /dev/null
+++ 
b/target/linux/ipq806x/patches-4.9/864-01-dts-ipq4019-ap.dk01.1-add-256MB-memory-node.patch
@@ -0,0 +1,14 @@
+--- a/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
 b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
+@@ -20,6 +20,11 @@
+   model = "Qualcomm Technologi

Re: [LEDE-DEV] KRACK (Key Reinstallation Attacks), now patched upstream in hostapd

[Stijn Tintel]

On 16-10-17 13:15, Stijn Tintel wrote:
> On 16-10-17 13:12, Koen Vandeputte wrote:
>>
>> On 2017-10-16 11:48, Nick Lowe wrote:
>>> Referencing https://www.krackattacks.com/
>>>
>>> Patches can be found at: https://w1.fi/security/2017-1/ and an
>>> advisory at http://seclists.org/oss-sec/2017/q4/83
>>>
>>> Patches can also be found committed at https://w1.fi/cgit/hostap/log/
>>>
>>> I think we need to get these patches integrated in to LEDE asap, or
>>> move to the hostapd development branch where there are currently
>>> committed.
>> I'm currently updating my patch-in-transit to incorporate these fixes.
>> http://patchwork.ozlabs.org/patch/823136/ 
> Felix already has the patches in his staging tree [1], and we are
> preparing the 17.01 branch for releasing 17.01.4.
>
Sorry, hit sent too soon and forgot to add the URL. Anyway, both master
and the lede-17.01 branch now contain these fixes.

Stijn

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] KRACK (Key Reinstallation Attacks), now patched upstream in hostapd

[Felix Fietkau]

On 2017-10-16 11:48, Nick Lowe wrote:
> Referencing https://www.krackattacks.com/
> 
> Patches can be found at: https://w1.fi/security/2017-1/ and an
> advisory at http://seclists.org/oss-sec/2017/q4/83
> 
> Patches can also be found committed at https://w1.fi/cgit/hostap/log/
> 
> I think we need to get these patches integrated in to LEDE asap, or
> move to the hostapd development branch where there are currently
> committed.
> 
> A "Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2" paper is
> available from: https://papers.mathyvanhoef.com/ccs2017.pdf
I've pushed fixes for this to LEDE master and 17.01

- Felix

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] KRACK (Key Reinstallation Attacks), now patched upstream in hostapd

[Stijn Tintel]

On 16-10-17 13:12, Koen Vandeputte wrote:
>
>
> On 2017-10-16 11:48, Nick Lowe wrote:
>> Referencing https://www.krackattacks.com/
>>
>> Patches can be found at: https://w1.fi/security/2017-1/ and an
>> advisory at http://seclists.org/oss-sec/2017/q4/83
>>
>> Patches can also be found committed at https://w1.fi/cgit/hostap/log/
>>
>> I think we need to get these patches integrated in to LEDE asap, or
>> move to the hostapd development branch where there are currently
>> committed.
> I'm currently updating my patch-in-transit to incorporate these fixes.
> http://patchwork.ozlabs.org/patch/823136/ 
Felix already has the patches in his staging tree [1], and we are
preparing the 17.01 branch for releasing 17.01.4.

Stijn

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] KRACK (Key Reinstallation Attacks), now patched upstream in hostapd

[Koen Vandeputte]

On 2017-10-16 11:48, Nick Lowe wrote:

Referencing https://www.krackattacks.com/

Patches can be found at: https://w1.fi/security/2017-1/ and an
advisory at http://seclists.org/oss-sec/2017/q4/83

Patches can also be found committed at https://w1.fi/cgit/hostap/log/

I think we need to get these patches integrated in to LEDE asap, or
move to the hostapd development branch where there are currently
committed.

I'm currently updating my patch-in-transit to incorporate these fixes.
http://patchwork.ozlabs.org/patch/823136/


A "Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2" paper is
available from: https://papers.mathyvanhoef.com/ccs2017.pdf

Best regards,

Nick

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] SDK Error: Makefile:48: *** DESCRIPTION:= is obsolete

[Jo-Philipp Wich]

Hi,

try using "define Build/Compile" instead of "define
Package/helloworld/compile".

~ Jo

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] KRACK (Key Reinstallation Attacks), now patched upstream in hostapd

[Nick Lowe]

Referencing https://www.krackattacks.com/

Patches can be found at: https://w1.fi/security/2017-1/ and an
advisory at http://seclists.org/oss-sec/2017/q4/83

Patches can also be found committed at https://w1.fi/cgit/hostap/log/

I think we need to get these patches integrated in to LEDE asap, or
move to the hostapd development branch where there are currently
committed.

A "Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2" paper is
available from: https://papers.mathyvanhoef.com/ccs2017.pdf

Best regards,

Nick

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] kernel: bump 4.9 to 4.9.56

[Koen Vandeputte]

Tested-by: Koen Vandeputte 

Targets: cns3xxx, imx6


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH lede-17.01 1/4] x86/generic: use HIGHMEM64G instead of HIGHMEM4G to fix PAE and Xen

[Felix Fietkau]

On 2017-10-16 09:43, Baptiste Jonglez wrote:
> Hi,
> 
> Any chance to get this patch serie merged to the lede-17.01 branch?
> As far as I can tell:
> 
> - Xen support is still broken in 17.01
> - this patch serie still applies cleanly
Done. Sorry for the delay.

- Felix

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [RFC] at91: fix build of legacy target

[Mathias Kresin]

16.10.2017 00:44, Hauke Mehrtens:

Changing the order of the devices fixes the build problem seen by the
build bot. I do not understand why this is making any difference at all,
this is probably only hiding a different bug.

Signed-off-by: Hauke Mehrtens 
---

Without this patch I am getting the following error message:

cat 
/home/hauke/openwrt/lede/build_dir/target-arm_arm926ej-s_musl_eabi/linux-at91_legacy/tmp/lede-at91-legacy-tny_a9260-squashfs-factory.bin.dtb
 >> 
/home/hauke/openwrt/lede/build_dir/target-arm_arm926ej-s_musl_eabi/linux-at91_legacy/tmp/lede-at91-legacy-tny_a9260-squashfs-factory.bin
dd 
if=/home/hauke/openwrt/lede/build_dir/target-arm_arm926ej-s_musl_eabi/linux-at91_legacy/tmp/lede-at91-legacy-tny_a9260-squashfs-factory.bin
 
of=/home/hauke/openwrt/lede/build_dir/target-arm_arm926ej-s_musl_eabi/linux-at91_legacy/tmp/lede-at91-legacy-tny_a9260-squashfs-factory.bin.new
 bs= conv=sync
dd: invalid number: ''
Makefile:74: recipe for target 
'/home/hauke/openwrt/lede/build_dir/target-arm_arm926ej-s_musl_eabi/linux-at91_legacy/tmp/lede-at91-legacy-tny_a9260-squashfs-factory.bin'
 failed
make[5]: *** 
[/home/hauke/openwrt/lede/build_dir/target-arm_arm926ej-s_musl_eabi/linux-at91_legacy/tmp/lede-at91-legacy-tny_a9260-squashfs-factory.bin]
 Error 1
make[5]: Leaving directory '/home/hauke/openwrt/lede/target/linux/at91/image'
Makefile:24: recipe for target 'install' failed


Hey Hauke,

your issue is:

define Device/Default
  DTB_SIZE :=
endef

define Device/production-dtb
  $(Device/production)
  $(Device/dtb)
  DTB_SIZE := 128k
  IMAGE/factory.bin := append-dtb | pad-to (DTB_SIZE) \
  | append-kernel | pad-to (KERNEL_SIZE) | append-ubi
endef

The pad-to (DTB_SIZE) references the DTB_SIZE variable from 
Device/Default instead of Device/production-dtb.


The best would be to move DTB_SIZE := 128k to Device/Default (which is 
safe since we don't have different DTB_SIZE values). Another way to fix 
the issue is to change the pad-to parameter to pad-to $$(DTB_SIZE).


But I've to admit, I fail to see why it works as intended if you change 
the order of the build code and it's most likely the reason why I didn't 
noticed the issue at the time I merged 
c2f052acaeb480e89d3ce39c47f49ad16b3464ac.


Mathias

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] scripts/download.pl: fail loudly if provided hash is unsupported

[Baptiste Jonglez]

On 08-10-17, Stijn Tintel wrote:
> On 25-09-17 18:43, Stijn Tintel wrote:
> > On 25-09-17 00:20, Baptiste Jonglez wrote:
> >> On 24-09-17, Stijn Tintel wrote:
> >>> My bad. When we update a package, we bump the version in the Makefile
> >>> and remove the current hash, then run "make package/foo/dowload; make
> >>> package/foo/check FIXUP=1". This downloads the tarbal for the new
> >>> version, and FIXUP writes its hash to the Makefile. This is what's
> >>> broken since the change.
> >> Ok, I see the issue now.
> >>
> >> As mentioned in the commit message, we definitely should add an explicit
> >> option to download.pl to skip hash verification, and then implement
> >> something like this:
> >>
> >> $ make package/foo/download SKIPHASH=1
> >>
> >> What do you think?
> > We were thinking in that direction on #lede-dev, not sure why we
> > couldn't agree. Let's wait a bit if anybody else chimes in?

> Maybe just send an RFC patch with the suggested change, as nobodoy seems
> to be responding.

Yes, sorry for the delay, I will submit a patch in the coming days/weeks.

Baptiste


signature.asc
Description: PGP signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH lede-17.01 1/4] x86/generic: use HIGHMEM64G instead of HIGHMEM4G to fix PAE and Xen

[Baptiste Jonglez]

Hi,

Any chance to get this patch serie merged to the lede-17.01 branch?
As far as I can tell:

- Xen support is still broken in 17.01
- this patch serie still applies cleanly

Thanks,
Baptiste

On 15-07-17, Baptiste Jonglez wrote:
> From: Baptiste Jonglez 
> 
> This is a backport of 641a65fd062987a456216cc4fa91ff2910528261 in master.
> 
> This change re-enables PAE for the 32-bit x86 subtarget, which is
> interesting in its own right but also necessary for Xen support.
> 
> Commit af1d1ebd ("x86: enable 4G high memory support for generic (32bit)
> subtarget") inadvertently disabled both PAE and Xen support.
> 
> Fixes: FS#908
> 
> Cc: Daniel Golle 
> Cc: Jo-Philipp Wich 
> Signed-off-by: Baptiste Jonglez 
> ---
>  target/linux/x86/generic/config-default | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/target/linux/x86/generic/config-default 
> b/target/linux/x86/generic/config-default
> index 1a14c270bc..c4ca4fd396 100644
> --- a/target/linux/x86/generic/config-default
> +++ b/target/linux/x86/generic/config-default
> @@ -42,6 +42,7 @@ CONFIG_AGP_INTEL=y
>  # CONFIG_AGP_SWORKS is not set
>  # CONFIG_AGP_VIA is not set
>  # CONFIG_APM is not set
> +CONFIG_ARCH_DMA_ADDR_T_64BIT=y
>  CONFIG_ARCH_ENABLE_SPLIT_PMD_PTLOCK=y
>  CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC=y
>  CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
> @@ -165,7 +166,8 @@ CONFIG_HDMI=y
>  CONFIG_HIBERNATE_CALLBACKS=y
>  CONFIG_HID=y
>  CONFIG_HID_BATTERY_STRENGTH=y
> -# CONFIG_HIGHMEM64G is not set
> +# CONFIG_HIGHMEM4G is not set
> +CONFIG_HIGHMEM64G=y
>  CONFIG_HOTPLUG_CPU=y
>  CONFIG_HPET=y
>  CONFIG_HPET_MMAP=y
> @@ -267,6 +269,7 @@ CONFIG_PATA_VIA=y
>  CONFIG_PCIEAER=y
>  CONFIG_PCIEPORTBUS=y
>  CONFIG_PCIE_PME=y
> +CONFIG_PCI_BUS_ADDR_T_64BIT=y
>  CONFIG_PCI_MMCONFIG=y
>  CONFIG_PCI_XEN=y
>  # CONFIG_PCWATCHDOG is not set


signature.asc
Description: PGP signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] ipq806x: add ap.dk01.1 board support

[Mathias Kresin]

15.10.2017 20:32, Roman Yeryomin:

- add partitions
- enable wifi and ethernet
- set max cpu speed to 710MHz
- set memory size to 256MB
- add image generation
- extract pre-cal data from ART partition

Wirespeed NAT can be achieved with spreading rx interrupts over different cores.
Wifi needs love -- too slow. Could be that latest ath10k helps, didn't test yet.

Signed-off-by: Roman Yeryomin 


Hey Roman,

would you please follow https://lede-project.org/submitting-patches and 
include in your commit message a short description of the hardware and 
how to install LEDE on it. Have a look at the recent additions for some 
examples.


Recently it has been once more shown that it's unnecessary hard to fix 
issues/bugs of a particular board if no one knows what kind 
flash/wifi/phy/whatever chip is used on a board.


Furthermore, without these informations a proper review of your patch is 
impossible.


Is this patch for the/a QCA reference board or for an off the shelf 
board based on the reference design?


Mathias

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev