Re: [LEDE-DEV] [PATCH] brcm2708: add squashfs rootfs image

[Christian Lamparter]

On Saturday, May 5, 2018 3:44:15 PM CEST Paul Spooren wrote:
> On Thu, Mar 29, 2018 at 9:22 AM, Daniel Golle <dan...@makrotopia.org> 
> wrote:
> > On Tue, Mar 27, 2018 at 07:42:18PM +0200, Christian Lamparter wrote:
> >>  This patch adds a image with squashfs as the root filesystem.
> >>  A rootfs_data partition will be generated on the first boot
> >>  and placed inside the rootfs partition (just after the squashfs
> >>  image).
> >> [...]
> 
> I tried the patch and the created squashfs works! However, trying a 
> sysupgrade errored saying it's unsupported.
Ok, I can look into this, but I would need more information to
debug it:

Can you please trace from where the message is coming from?
By chance: Does it look it is created by the fwtool check? [0] 
("Device $device is not supported by this image") or was it a
different message?

Also, can you please tell me which sysupgrade method 
(good-old sysupgrade via ssh/serial or the LuCI App) you used?

If you went through ssh, it should look like this: (tested with rpi-b)
|squashfs:
|root@rpi-b:/tmp# sysupgrade -v 
openwrt-brcm2708-bcm2708-rpi-squashfs-sdcard.img.gz 
|Reading partition table from bootdisk...
|Reading partition table from image...
|Saving config files...
|boot/config.txt
|etc/config/attendedsysupgrade
|[...]
|etc/uhttpd.crt
|Commencing upgrade. All shell sessions will be closed now.
|Connection to rpi-b closed by remote host.
|Connection to rpi-b closed.
and for ext4:
|root@rpi-b:/tmp# sysupgrade -v openwrt-brcm2708-bcm2708-rpi-ext4-sdcard.img.gz 
|Reading partition table from bootdisk...
|Reading partition table from image...
|Saving config files...
|boot/config.txt
|etc/config/attendedsysupgrade
|[...]
|etc/uhttpd.crt
|Commencing upgrade. All shell sessions will be closed now.
|Connection to rpi-b closed by remote host.
|Connection to rpi-b closed.

In my testing the LuCI app did work as well, as long as I tested with
the rpi-3 (this is a bit of a problem, since it has a use... unlike the
old rpi-b it replaced). The rpi-b is currently not in the snapshot.yml [2].
(But there's an easy WA: edit /tmp/sysinfo/board_name).

As for adding the various RaspberryPI: There's the issue that the RPI-3(+)
and RPI3-CM can also have the rpi-2 image installed because the user 
specifically wanted the 32-bit ARMv7 environment (over the 64-Bit ARMv8).
And this is a problem, because the database model 'board_rename_table' in
tables.sql [3] does not look like it can handle 1:n mappings required
for this case.

> Is it possible we have to teach the sysupgrade that squashfs is compatible, 
> too?
I switched the brcm2708 target to x86's sysupgrade routines in
"brcm2708: use x86's upgrade scripts for all rpi targets" [1].
This sysupgrade method works by comparing the MBR partition layout
on the sdcard and if the layout is compatible it "dd" the
(extracted) data into the /dev/mmcblk0p[12] partitions. The method
and tools don't really care about whats in the partitions though. 
It should work regardless of what filesystem is being used...
so yeah: o_O?! (I'm really wondering what went wrong?)

> Except from that, it works and runs with no problems on my RPI3, please 
> merge.
> 
> Regarding the doubts of Christian, is there any problem producing the 
> ext4 and squashfs per default?
Maybe CDN? Since two images are now created for every (sub-)target.
That said, x86 is doing the same with combined-ext4.img.gz and 
combined-squash.img.gz ;) . Maybe someone can provide some 
downloadstats on which image is more popular?

Best Regards,
Christian

[0] 
<https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/base-files/files/lib/upgrade/fwtool.sh;h=49f02b7bd9ed735a43a487ea2d7d306a604be6c0;hb=HEAD#l34>

[1] 
<https://github.com/openwrt/openwrt/commit/246916ddf4a1a95fd063e6d7c00d73bb0b5f36a6#diff-6c9507e28c71114ef1e6505ba5fb33b4>

[2] 
<https://github.com/aparcar/attendedsysupgrade-server/blob/dev/distributions/openwrt/snapshot.yml>

[3] 
<https://github.com/aparcar/attendedsysupgrade-server/blob/fe810d27556d60cfeb840b1d7079545ebd62d314/utils/tables.sql#L624>




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

Re: [LEDE-DEV] ipq40xx cpu frequency

[Christian Lamparter]

Hello,

On Friday, May 4, 2018 4:12:16 PM CEST Roman Yeryomin wrote:
> I'm seeing this
> 
> [1.275858] cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 
> 632000 KHz
> [1.276620] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency 
> changed to: 716000 KHz

Sorry, but I'm having this "déjà vu"? I do remember *trying* to talk with
you about this in this thread "ipq806x: add ap.dk01.1 board support" already.

Back then you initially went with 710 MHz and I warned:
|There's a reason to stick with the 666MHz rate though. You should check
|if the device produces messages like:
|[1.399981] cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 666000 
KHz
|[1.400256] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency 
changed to: 71 KHz
|(From what I know, the SBL actually sets it to 666MHz)
|
|But there's more. If you look at qualcomm's page, it's says that the
|CPU Clock Speed is 717 MHz: 
|
|Since you are working for a OEM/ODM. You could please ask what is the
|right MHz table for these devices? Unfortunately, Qualcomm never got
|around to fix this upstream and without an official statement from them
|it's very difficult to push stuff like this upstream.
Have we come full circle now?

> on ap-dk01 board (I suspect others may be affected too, I don't
> have hw to test).
Yes that is true some boards print the same warning (with different
unlisted frequencies). The patch was sent upstream to linux-clk along
with a request on how this should be handled. Sadly no maintainer
has replied, even though the some of the IPQ40XX boards are crashing
without it.

> Looks like related to your commit
> a44d435c1d ipq40xx: fix apss cpu overclocking spam
> 
> While it fixes the original problem described, it would be nice not to 
> misconfigure the clock anyway.
Hmm? I think this is a misunderstanding, or are you jumping to conclusions?
The patch does not misconfigure the clock. The 900-clk-fix.patch
message explains in detail what the patch does and why:
|This patch attempts to fix the issue by modifying
|clk_cpu_div_round_rate(), clk_cpu_div_set_rate(), clk_cpu_div_recalc_rate()
|to use a new qcom_find_freq_close() function, which returns the closest
|matching frequency, instead of the next higher. This way, the SoC in
|the FB4040 (with its max clock speed of 710.4 MHz) will no longer
|try to overclock to 761 MHz.

> Also, since the official highest frequency is 716.8MHz, wouldn't it be 
> more logical to fix it in appropriate board dts (if needed) and not in 
> the common dtsi?
The gcc-ipq4019.c clk driver has a fixed frequency table defining all
the valid frequencies. The reason why this "worked" in the past (i.e 4.9)
was a bug in the gcc-ipq4019.c driver that got fixed with:
"clk: qcom: ipq4019: Add the apss cpu pll divider clock node"
>From what I can tell, back then the clk driver didn't really program
the P_DDRPLLAPSS clock so the device was left running at the
max frequency that u-boot or SBL1 programmed it.

Anyway, I took a peek into the patches that I sent to Mathias and John.
>From what I can tell the 716.8 MHz to 716 MHz didn't happen there. But I
think I know where it comes from: You see "Sricharan R" posted this patch
to linux-msm-arm: . But please
check with Mathias too (CCd).

Thank you and best regards,
Christian



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

[LEDE-DEV] [RFT] musl: 1.1.20 prelease testing in OpenWrt

[Christian Lamparter]

Rich Felker requested field testing of what will become musl 1.1.20:
<http://www.openwall.com/lists/musl/2018/04/18/3>

"The biggest areas that need testing are:

- stdio locking after commits c21f750727515602a9e84f2a190ee8a0a2aeb2a1
  and c1014a812c90bab3c9c989863e4ebb129e987de6.

- reclaim_gaps since commit ce7ae11acfd9db8eb92cc6823c132e1825918d92.
  this could be tested by abusing __malloc_donate as if it were a
  public api.

- malloc interposition -- seeing if replacement allocators actually
  work. (not so important since it wouldn't be a regression if it's
  broken, but would be nice to know it works before announcing)"

200-add_libssp_nonshared.patch was removed since Rich reworked
the logic in c7bb9c41d2e62b7ad1c7858d4d0f2873642e634b
"adjust makefile target-specific CFLAGS rules to be more robust & complete"
and a7c53e0c2cd8fc45eac90c0468e44697019ceda6
"fix out-of-tree build of crt files with stack protector enabled"
so please test.

Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
 toolchain/musl/common.mk  |  4 +-
 .../patches/200-add_libssp_nonshared.patch| 50 ---
 toolchain/musl/patches/300-relative.patch |  2 +-
 ...ribute-to-some-function-declarations.patch |  8 +--
 4 files changed, 7 insertions(+), 57 deletions(-)
 delete mode 100644 toolchain/musl/patches/200-add_libssp_nonshared.patch

diff --git a/toolchain/musl/common.mk b/toolchain/musl/common.mk
index 87424646c3..a8abe8af69 100644
--- a/toolchain/musl/common.mk
+++ b/toolchain/musl/common.mk
@@ -13,8 +13,8 @@ PKG_RELEASE=1
 
 PKG_SOURCE_PROTO:=git
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
-PKG_SOURCE_VERSION:=55df09bfccbfe21fc9dd7d8f94550c0ff25ace04
-PKG_MIRROR_HASH:=eb94e4e7e94221dd8890afd9b29e2562c36cf5585649035349ca1c6c1c354f2b
+PKG_SOURCE_VERSION:=b4b1e10364c8737a632be61582e05a8d3acf5690
+PKG_MIRROR_HASH:=1b0530313811897fee5ab22c6d6c7c8cbb6568736dcf09dea6e4d023350c9ecd
 PKG_SOURCE_URL:=git://git.musl-libc.org/musl
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.xz
 
diff --git a/toolchain/musl/patches/200-add_libssp_nonshared.patch 
b/toolchain/musl/patches/200-add_libssp_nonshared.patch
deleted file mode 100644
index 7a2909461b..00
--- a/toolchain/musl/patches/200-add_libssp_nonshared.patch
+++ /dev/null
@@ -1,50 +0,0 @@
-From 7ec87fbbc3cac99b4173d082dd6195f47c9a32e7 Mon Sep 17 00:00:00 2001
-From: Steven Barth <ste...@midlink.org>
-Date: Mon, 22 Jun 2015 11:01:56 +0200
-Subject: [PATCH] Add libssp_nonshared.a so GCC's is not needed
-
-Signed-off-by: Steven Barth <ste...@midlink.org>

- Makefile  | 10 --
- libssp_nonshared/__stack_chk_fail_local.c |  2 ++
- 2 files changed, 10 insertions(+), 2 deletions(-)
- create mode 100644 libssp_nonshared/__stack_chk_fail_local.c
-
 a/Makefile
-+++ b/Makefile
-@@ -66,7 +66,7 @@ CRT_LIBS = $(addprefix lib/,$(notdir $(C
- STATIC_LIBS = lib/libc.a
- SHARED_LIBS = lib/libc.so
- TOOL_LIBS = lib/musl-gcc.specs
--ALL_LIBS = $(CRT_LIBS) $(STATIC_LIBS) $(SHARED_LIBS) $(EMPTY_LIBS) 
$(TOOL_LIBS)
-+ALL_LIBS = $(CRT_LIBS) $(STATIC_LIBS) $(SHARED_LIBS) $(EMPTY_LIBS) 
$(TOOL_LIBS) lib/libssp_nonshared.a
- ALL_TOOLS = obj/musl-gcc
- 
- WRAPCC_GCC = gcc
-@@ -125,7 +125,8 @@ NOSSP_SRCS = $(wildcard crt/*.c) \
-   src/thread/__set_thread_area.c src/thread/$(ARCH)/__set_thread_area.c \
-   src/string/memset.c src/string/$(ARCH)/memset.c \
-   src/string/memcpy.c src/string/$(ARCH)/memcpy.c \
--  ldso/dlstart.c ldso/dynlink.c
-+  ldso/dlstart.c ldso/dynlink.c \
-+  src/libssp_nonshared/__stack_chk_fail_local.c
- $(NOSSP_SRCS:%.c=obj/%.o) $(NOSSP_SRCS:%.c=obj/%.lo): CFLAGS_ALL += 
$(CFLAGS_NOSSP)
- 
- $(CRT_OBJS): CFLAGS_ALL += -DCRT
-@@ -168,6 +169,11 @@ lib/libc.a: $(AOBJS)
-   $(AR) rc $@ $(AOBJS)
-   $(RANLIB) $@
- 
-+lib/libssp_nonshared.a: obj/src/libssp_nonshared/__stack_chk_fail_local.o
-+  rm -f $@
-+  $(AR) rc $@ $<
-+  $(RANLIB) $@
-+
- $(EMPTY_LIBS):
-   rm -f $@
-   $(AR) rc $@
 /dev/null
-+++ b/src/libssp_nonshared/__stack_chk_fail_local.c
-@@ -0,0 +1,2 @@
-+#include "atomic.h"
-+void __attribute__((visibility ("hidden"))) __stack_chk_fail_local(void) { 
a_crash(); }
diff --git a/toolchain/musl/patches/300-relative.patch 
b/toolchain/musl/patches/300-relative.patch
index 7e1eb7d6bc..e76867bb66 100644
--- a/toolchain/musl/patches/300-relative.patch
+++ b/toolchain/musl/patches/300-relative.patch
@@ -1,6 +1,6 @@
 --- a/Makefile
 +++ b/Makefile
-@@ -217,7 +217,7 @@ $(DESTDIR)$(includedir)/%: $(srcdir)/inc
+@@ -208,7 +208,7 @@ $(DESTDIR)$(includedir)/%: $(srcdir)/inc
$(INSTALL) -D -m 644 $< $@
  
  $(DESTDIR)$(LDSO_PATHNAME): $(DESTDIR)$(libdir)/libc.so
diff --git 
a/toolchain/musl/patches/400-Add-format-attribute-to-some-function-declarations.patch
 
b/toolchain/musl/patches/400-Add-format-attribute-to-some-function-decl

Re: [LEDE-DEV] apm821xx target: kernel gets too big

[Christian Lamparter]

On Sonntag, 18. März 2018 00:24:06 CET Hauke Mehrtens wrote:
> Hi,
> 
> After the upgrade to GCC 7.3 the kernel on the apm821xx target gets too
> big for the meraki_mr24 device and the build in build bot is failing.
> Could you please have a look at this problem:
> http://phase1.builds.lede-project.org/builders/apm821xx%2Fnand
>From what I remember, the limits are set in place to accomodate the
initramfs image. And the initramfs is currently limited by these u-boot
varliables:

meraki_loadaddr=c0
meraki_loadaddr_kernel=c1
meraki_loadaddr_fdt=c00400
meraki_loadaddr_ramdisk=e0

The image (with the meraki header) get loaded to c0.
The FDT is located at 0xc00400 - 0xc0 = 64512 Bytes (DTB_SIZE)
The kernel has to fit into 0xc1 - 0xe0 = 2031616 Bytes 
(1984 KB aka. KERNEL_SIZE) 
And the ram disk is from 0xe0 onward.

The kernel for sysupgrade.tar does not have such a limitation.

Chris do you have any idea?

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

Re: [LEDE-DEV] [PATCH-v2 3/3] ath10k-firmware: Support CT IPQ4019 firmware.

[Christian Lamparter]

On Sunday, January 21, 2018 10:49:19 PM CET Ben Greear wrote:
> 
> On 01/21/2018 07:54 AM, Christian Lamparter wrote:
> > On Saturday, January 20, 2018 1:27:04 AM CET gree...@candelatech.com wrote:
> >> From: Ben Greear <gree...@candelatech.com>
> >>
> >> Initial beta release of the CT IPQ4019 firmware.  Features are
> >> similar to the CT 9984 firmware
> 
> >> +$(eval $(call BuildPackage,ath10k-firmware-qca4019-ct-htt))
> >> +$(eval $(call BuildPackage,ath10k-firmware-qca4019-ct))
> >>  $(eval $(call BuildPackage,ath10k-firmware-qca9888-ct))
> >>
> > ---
> > I applied the full series on top of the r5904 (see attached
> > diffconfig). But I ran into issues when selecting ath10k-ct
> > and ath10k-firmware-qca4019-ct during image creation.
> > So what's the recommended way to install these?
> 
> Are you able to un-select the default firmware? In that case,
> there should be no issue with the board-2.bin?
Try the diffconfig. It a multi-image built that includes all the current
qca4019 targets. From what I can see, neither kmod-ath10k or
ath10k-firmware-qca4019 can be deselected. At best kmod-ath10k
can be compiled as an installable package (=m). However 
ath10k-firmware-qca4019 will always be included (=y)
(due to the ipq-wifi packages' DEPENDS).

kconfig/menuconfig provides some information to why the packages
are being picked:

kmod-ath10k is Selected by: MODULE_DEFAULT_kmod-ath10k [=y] && \
 TARGET_PER_DEVICE_ROOTFS [=y] && m && MODULES [=y]

ath10k-firmware-qca4019 is Selected by:
  MODULE_DEFAULT_ath10k-firmware-qca4019 [=y] && TARGET_PER_DEVICE_ROOTFS [=y] 
\\ 
  && m && MODULES [=y] || PACKAGE_ipq-wifi-avm_fritzbox-4040 [=m] && \
  TARGET_ipq806x [=y] || PACKAGE_ipq-wifi-openmesh_a42 [=y] &&
  TARGET_ipq806x [=y] && (m && MODULES [=y] || 
PACKAGE_ipq-wifi-avm_fritzbox-4040 [=m]!=y)

> I expect the use case is to install exactly one of the firmware targets.
>
> If we take the board-2.bin out of the firmware install target, then users
> would somehow have to know to install some sort of board-2.bin or similar
> file, otherwise the driver still will not load.
>
> Since some boards have their own custom board-2.bin, I'm not sure how to
> automate this properly.  But, if we just assume users will select the
> right thing, then splitting board-2.bin out of the FW install target
> should be OK I guess?
I guess. Separating the board-2.bin files also has an advantage that it
will make it possible for users to update the ath10k-firmware-* package
on a deployed system without needing to reinstall the custom ipq-wifi
for their device each time.

But why not ask the ath10k-firmware package maintainer for input as well?
It could just be that a solution is just hiding in plain sight.

For example a easy solution would be just add a short note to the package
description of ath10k-firmware-qca4019-ct(-htt) like the one that was added
to ath10k-firmware-qca9984-ct: 
"This firmware conflicts with the standard 9984 firmware, so select only
one." [0] (but tailored to qca4019). This will leave it to the user to
either select/deselect the right firmware and driver combo manually.

Another possible way would be to set the "CONFLICTS" variable on the
kmod-ath10k(-ct) and all the ath10k-firmware-* packages. This would have
the advantage that the package/firmware/driver selection would be automatic.

Or maybe there's an elegant solution with "ALTERNATIVES"/"REPLACES"/"PROVIDES"/
"DEPENDS" package variables. With the kmod-ath10k-ct and ath10k-firmware-*-ct
packages at a higher priority, so they'll take precedence if selected.

... etc.

Regards,
Christian

[0] 
<https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/firmware/ath10k-firmware/Makefile;h=94e59537834a67e8b9d469f6a050697e6cf24789;hb=HEAD#l145>


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

Re: [LEDE-DEV] [PATCH 2/4] ipq: Don't force selection of the IPQ4019 firmware.

[Christian Lamparter]

(Readded: Hauke Mehrtens <ha...@hauke-m.de>)
On Saturday, January 20, 2018 5:40:08 PM CET Ben Greear wrote:
> 
> On 01/20/2018 02:15 AM, Christian Lamparter wrote:
> > On Friday, January 19, 2018 10:06:50 PM CET Ben Greear wrote:
> >> On 01/19/2018 01:03 PM, Christian Lamparter wrote:
> >>> On Friday, January 19, 2018 9:12:04 PM CET gree...@candelatech.com wrote:
> >>>> From: Ben Greear <gree...@candelatech.com>
> >>>>
> >>>> This will allow us to select the CT IPQ4019 firmware instead if
> >>>> desired.
> >>>>
> >>>> Signed-off-by: Ben Greear <gree...@candelatech.com>
> >>>> ---
> >>>>  package/firmware/ipq-wifi/Makefile | 2 +-
> >>>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/package/firmware/ipq-wifi/Makefile 
> >>>> b/package/firmware/ipq-wifi/Makefile
> >>>> index 519e8c9..6690248 100644
> >>>> --- a/package/firmware/ipq-wifi/Makefile
> >>>> +++ b/package/firmware/ipq-wifi/Makefile
> >>>> @@ -20,7 +20,7 @@ define Package/ipq-wifi-default
> >>>>SUBMENU:=ath10k IPQ4019 Boarddata
> >>>>SECTION:=firmware
> >>>>CATEGORY:=Firmware
> >>>> -  DEPENDS:=@TARGET_ipq806x +ath10k-firmware-qca4019
> >>>> +  DEPENDS:=@TARGET_ipq806x
> >>>>TITLE:=Custom Board
> >>>>  endef
> >>>>
> >>>
> >>> Wait! I remember talking about this here in the RFC thread:
> >>> <https://www.mail-archive.com/lede-dev@lists.infradead.org/msg09621.html>
> >>> |Hm, this would break the WIFI in the default configuration for the
> >>> |FritzBox 4040 image. Currently it only has a dependency on the
> >>> |ipq-wifi-fritz4040. (So it will end up without a firmware-5.bin)
> >>>
> >>> What gives? Are you trying to break the AVM FRITZ!Box 4040 image on 
> >>> purpose?
> >>
> >> Of course I'm not trying to break anything.  But, I am not sure how to
> >> fix this properly.
> > I remember writing about this too. It's in the reply.
> > <https://www.mail-archive.com/lede-dev@lists.infradead.org/msg09626.html>
> > |I think there's a another way to do this. But it will require to break with
> > |the existing convention of adding the board-2.bin that comes with the
> > |firmware repository to the ath10k-firmware-qca4019 file.
> > |
> > |This way, the custom board-2.bin will stay in place when you switch/update
> > |the firmware-5.bin.
> > |
> > |(The board-2.bin for the reference boards can simply be packaged just like
> > |one of the ipq-wifi board firmwares). And furhtermore, you could provide a
> > |"easy to use/install" custom ipq-wifi.ipk for the board-2.bin you currently
> > |host on your webside.
> > Of course, if you have a better idea let's hear it too. You could look into
> > making virtual packages (Don't know, if that's a thing with opkg, or not.
> > So watch out!) or go a different route. I'm sure there's plenty of ways to
> > do it. If you come up with something, I'll be happy to test it.
> >
> >> Does each platform need to specifically enable a firmware target instead of
> >> depending on a DEPENDS statement to make it work?
> > From what I know, the platform (ipq806x) does not add any firmware packages 
> > to
> > DEFAULT_PACKAGES in the target/linux/ipq806x/Makefile. It's all 
> > "per-device".
> >
> > (That said, you might want to talk to Sven Eckelmann too. As he has added
> > the ath10k-firmware-qca4019 package to the OpenMesh a42's DEVICE_PACKAGES.
> > So, if ath10k-ct is selected on a a42 it will also include the (now useless)
> > ath10k-firmware-qca4019, right?)
> >
> >> Is there some other way I can provide an option for two different firmware
> >> binaries?
> > The firmware binaries (i.e. firmware-X.bin) are not the problem. It's the
> > "board-2.bin" files that are shipped by the ath10k-firmware-qca4019/9984/..
> > packages.
> 
> Maybe you could test the 3 -v2 patches I posted on your 4019 device and see if
> you can select -ct firmware?
> 
> The board.bin issue would be the same with -ct or stock 4019 firmware AFAIK,
> so if that is still an issue, it is a separate one.

Done. It looks like the ath10k-ct & ct-firmware used to work but was broken by:
<https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=021b96d7c5c668fbcb5375c65cee90832bb2854f>
|rootfs: remove unnecessary and potentially harmful force flags from opkg call
|
|Especially --force-overwrite and --force-depends will often lead to broken
|images; it's better to fail the build in such cases than to silently ignore
|the errors.
|
|Instead, ignore errors in the per-device rootfs opkg remove command, so
|the build doesn't break when packages can't be removed because of
|dependencies.
|
|Signed-off-by: Matthias Schiffer <mschif...@universe-factory.net>

Is this correct, if so this should be fixed one way or another.

Regards,
Christian


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

Re: [LEDE-DEV] [PATCH-v2 3/3] ath10k-firmware: Support CT IPQ4019 firmware.

[Christian Lamparter]

On Saturday, January 20, 2018 1:27:04 AM CET gree...@candelatech.com wrote:
> From: Ben Greear 
> 
> Initial beta release of the CT IPQ4019 firmware.  Features are
> similar to the CT 9984 firmware
> 
> Signed-off-by: Ben Greear 
> ---
>  package/firmware/ath10k-firmware/Makefile | 74 
> +--
>  1 file changed, 71 insertions(+), 3 deletions(-)
> 
> diff --git a/package/firmware/ath10k-firmware/Makefile 
> b/package/firmware/ath10k-firmware/Makefile
> index 94e5953..c525d87 100644
> --- a/package/firmware/ath10k-firmware/Makefile
> +++ b/package/firmware/ath10k-firmware/Makefile
> @@ -50,6 +50,7 @@ $(Package/ath10k-firmware-default)
>  endef
>  
>  CT_FIRMWARE_FILE = $(1)-$($(1)_FIRMWARE_FILE_CT)
> +CT_FIRMWARE_FILE_HTT = $(1)-$($(1)_FIRMWARE_FILE_CT_HTT)
>  
>  define Download/ct-firmware
>URL:=https://www.candelatech.com/downloads/$(2)
> @@ -57,6 +58,12 @@ define Download/ct-firmware
>URL_FILE:=$($(1)_FIRMWARE_FILE_CT)
>  endef
>  
> +define Download/ct-firmware-htt
> +  URL:=https://www.candelatech.com/downloads/$(2)
> +  FILE:=$(call CT_FIRMWARE_FILE_HTT,$(1))
> +  URL_FILE:=$($(1)_FIRMWARE_FILE_CT_HTT)
> +endef
> +
>  QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-19.bin.lede
>  define Download/ath10k-firmware-qca988x-ct
>$(call Download/ct-firmware,QCA988X,)
> @@ -85,6 +92,20 @@ define Download/ath10k-firmware-qca9984-ct
>  endef
>  $(eval $(call Download,ath10k-firmware-qca9984-ct))
>  
> +QCA4019_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-10.bin-lede.002
> +define Download/ath10k-firmware-qca4019-ct-htt
> +  $(call Download/ct-firmware-htt,QCA4019,ath10k-4019-10-4)
> +  HASH:=e67bbc8eba56bc72c1aa99a6304ea98345bddc34f4844d5d79a51db1d6d8c425
> +endef
> +$(eval $(call Download,ath10k-firmware-qca4019-ct-htt))
> +
> +QCA4019_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-10.bin-lede.002
> +define Download/ath10k-firmware-qca4019-ct
> +  $(call Download/ct-firmware,QCA4019,ath10k-4019-10-4)
> +  HASH:=f1ebb73903e4e6a6209b8acdc623bc43d355d32cce838ce0448befe9196c7866
> +endef
> +$(eval $(call Download,ath10k-firmware-qca4019-ct))
> +
>  QCA9888_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-9.bin-lede.004
>  define Download/ath10k-firmware-qca9888-ct
>$(call Download/ct-firmware,QCA9888,ath10k-9888-10-4)
> @@ -146,6 +167,18 @@ This firmware conflicts with the standard 9984 firmware, 
> so select only
>  one.
>  endef
>  
> +define Package/ath10k-firmware-qca4019-ct-htt/description
> +Alternative ath10k firmware for IPQ4019 radio from Candela Technologies.
> +Enables IBSS and other features.  Requires ath10k-ct driver to function.
> +See:  http://www.candelatech.com/ath10k-10.4.php
> +endef
> +
> +define Package/ath10k-firmware-qca4019-ct/description
> +Alternative ath10k firmware for IPQ4019 radio from Candela Technologies.
> +Enables IBSS and other features.  Works with standard or ath10k-ct driver.
> +See:  http://www.candelatech.com/ath10k-10.4.php
> +endef
> +
>  define Package/ath10k-firmware-qca9888-ct/description
>  Alternative ath10k firmware for QCA9886 and QCA9888 from Candela 
> Technologies.
>  Enables IBSS and other features.  See:
> @@ -162,21 +195,34 @@ endef
>  
>  define Package/ath10k-firmware-qca99x0-ct
>  $(Package/ath10k-firmware-default)
> -  TITLE:=ath10k CT 10.4.3 firmware for QCA99x0 devices
> +  TITLE:=ath10k CT 10.4 firmware for QCA99x0 devices
>SECTION:=firmware
>CATEGORY:=Firmware
>  endef
>  
>  define Package/ath10k-firmware-qca9984-ct
>  $(Package/ath10k-firmware-default)
> -  TITLE:=ath10k CT 10.4.3 firmware for QCA9984 devices
> +  TITLE:=ath10k CT 10.4 firmware for QCA9984 devices
> +  SECTION:=firmware
> +  CATEGORY:=Firmware
> +endef
> +
> +define Package/ath10k-firmware-qca4019-ct-htt
> +$(Package/ath10k-firmware-default)
> +  TITLE:=ath10k CT 10.4 htt-mgt for QCA4018/9
> +  SECTION:=firmware
> +  CATEGORY:=Firmware
> +endef
> +define Package/ath10k-firmware-qca4019-ct
> +$(Package/ath10k-firmware-default)
> +  TITLE:=ath10k CT 10.4 firmware for QCA4018/9
>SECTION:=firmware
>CATEGORY:=Firmware
>  endef
>  
>  define Package/ath10k-firmware-qca9888-ct
>  $(Package/ath10k-firmware-default)
> -  TITLE:=ath10k CT 10.4.3 firmware for QCA9886 and QCA9888 devices
> +  TITLE:=ath10k CT 10.4 fw for QCA9886/8 devices
>SECTION:=firmware
>CATEGORY:=Firmware
>  endef
> @@ -328,6 +374,26 @@ define Package/ath10k-firmware-qca9984-ct/install
>   $(1)/lib/firmware/ath10k/QCA9984/hw1.0/firmware-5.bin
>  endef
>  
> +define Package/ath10k-firmware-qca4019-ct-htt/install
> + $(INSTALL_DIR) $(1)/lib/firmware/ath10k/QCA4019/hw1.0
> + $(INSTALL_DATA) \
> + $(PKG_BUILD_DIR)/QCA4019/hw1.0/board-2.bin \
> + $(1)/lib/firmware/ath10k/QCA4019/hw1.0/
> + $(INSTALL_DATA) \
> + $(DL_DIR)/$(call CT_FIRMWARE_FILE_HTT,QCA4019) \
> + $(1)/lib/firmware/ath10k/QCA4019/hw1.0/ct-firmware-5.bin
> 

Re: [LEDE-DEV] [PATCH 2/4] ipq: Don't force selection of the IPQ4019 firmware.

[Christian Lamparter]

On Friday, January 19, 2018 10:06:50 PM CET Ben Greear wrote:
> On 01/19/2018 01:03 PM, Christian Lamparter wrote:
> > On Friday, January 19, 2018 9:12:04 PM CET gree...@candelatech.com wrote:
> >> From: Ben Greear <gree...@candelatech.com>
> >>
> >> This will allow us to select the CT IPQ4019 firmware instead if
> >> desired.
> >>
> >> Signed-off-by: Ben Greear <gree...@candelatech.com>
> >> ---
> >>  package/firmware/ipq-wifi/Makefile | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/package/firmware/ipq-wifi/Makefile 
> >> b/package/firmware/ipq-wifi/Makefile
> >> index 519e8c9..6690248 100644
> >> --- a/package/firmware/ipq-wifi/Makefile
> >> +++ b/package/firmware/ipq-wifi/Makefile
> >> @@ -20,7 +20,7 @@ define Package/ipq-wifi-default
> >>SUBMENU:=ath10k IPQ4019 Boarddata
> >>SECTION:=firmware
> >>CATEGORY:=Firmware
> >> -  DEPENDS:=@TARGET_ipq806x +ath10k-firmware-qca4019
> >> +  DEPENDS:=@TARGET_ipq806x
> >>TITLE:=Custom Board
> >>  endef
> >>
> >
> > Wait! I remember talking about this here in the RFC thread:
> > <https://www.mail-archive.com/lede-dev@lists.infradead.org/msg09621.html>
> > |Hm, this would break the WIFI in the default configuration for the
> > |FritzBox 4040 image. Currently it only has a dependency on the
> > |ipq-wifi-fritz4040. (So it will end up without a firmware-5.bin)
> >
> > What gives? Are you trying to break the AVM FRITZ!Box 4040 image on purpose?
> 
> Of course I'm not trying to break anything.  But, I am not sure how to
> fix this properly. 
I remember writing about this too. It's in the reply.
<https://www.mail-archive.com/lede-dev@lists.infradead.org/msg09626.html>
|I think there's a another way to do this. But it will require to break with
|the existing convention of adding the board-2.bin that comes with the
|firmware repository to the ath10k-firmware-qca4019 file.
|
|This way, the custom board-2.bin will stay in place when you switch/update
|the firmware-5.bin. 
|
|(The board-2.bin for the reference boards can simply be packaged just like
|one of the ipq-wifi board firmwares). And furhtermore, you could provide a
|"easy to use/install" custom ipq-wifi.ipk for the board-2.bin you currently
|host on your webside.
Of course, if you have a better idea let's hear it too. You could look into 
making virtual packages (Don't know, if that's a thing with opkg, or not.
So watch out!) or go a different route. I'm sure there's plenty of ways to
do it. If you come up with something, I'll be happy to test it.

> Does each platform need to specifically enable a firmware target instead of
> depending on a DEPENDS statement to make it work?
>From what I know, the platform (ipq806x) does not add any firmware packages to
DEFAULT_PACKAGES in the target/linux/ipq806x/Makefile. It's all "per-device".

(That said, you might want to talk to Sven Eckelmann too. As he has added
the ath10k-firmware-qca4019 package to the OpenMesh a42's DEVICE_PACKAGES.
So, if ath10k-ct is selected on a a42 it will also include the (now useless)
ath10k-firmware-qca4019, right?)

> Is there some other way I can provide an option for two different firmware
> binaries?
The firmware binaries (i.e. firmware-X.bin) are not the problem. It's the
"board-2.bin" files that are shipped by the ath10k-firmware-qca4019/9984/..
packages.

Regards,
Christian

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

Re: [LEDE-DEV] [PATCH 2/4] ipq: Don't force selection of the IPQ4019 firmware.

[Christian Lamparter]

On Friday, January 19, 2018 9:12:04 PM CET gree...@candelatech.com wrote:
> From: Ben Greear 
> 
> This will allow us to select the CT IPQ4019 firmware instead if
> desired.
>
> Signed-off-by: Ben Greear 
> ---
>  package/firmware/ipq-wifi/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/package/firmware/ipq-wifi/Makefile 
> b/package/firmware/ipq-wifi/Makefile
> index 519e8c9..6690248 100644
> --- a/package/firmware/ipq-wifi/Makefile
> +++ b/package/firmware/ipq-wifi/Makefile
> @@ -20,7 +20,7 @@ define Package/ipq-wifi-default
>SUBMENU:=ath10k IPQ4019 Boarddata
>SECTION:=firmware
>CATEGORY:=Firmware
> -  DEPENDS:=@TARGET_ipq806x +ath10k-firmware-qca4019
> +  DEPENDS:=@TARGET_ipq806x
>TITLE:=Custom Board
>  endef
>  

Wait! I remember talking about this here in the RFC thread:

|Hm, this would break the WIFI in the default configuration for the 
|FritzBox 4040 image. Currently it only has a dependency on the 
|ipq-wifi-fritz4040. (So it will end up without a firmware-5.bin)

What gives? Are you trying to break the AVM FRITZ!Box 4040 image on purpose?

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

[LEDE-DEV] [PATCH] ipq806x: remove merged ipq4019 patch

[Christian Lamparter]

The patch 0022-dts-ipq4019-support-ARMv7-PMU.patch
was merged into 4.8-rc1.

Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
 .../0022-dts-ipq4019-support-ARMv7-PMU.patch   | 28 --
 1 file changed, 28 deletions(-)
 delete mode 100644 
target/linux/ipq806x/patches-4.9/0022-dts-ipq4019-support-ARMv7-PMU.patch

diff --git 
a/target/linux/ipq806x/patches-4.9/0022-dts-ipq4019-support-ARMv7-PMU.patch 
b/target/linux/ipq806x/patches-4.9/0022-dts-ipq4019-support-ARMv7-PMU.patch
deleted file mode 100644
index c427d66efd..00
--- a/target/linux/ipq806x/patches-4.9/0022-dts-ipq4019-support-ARMv7-PMU.patch
+++ /dev/null
@@ -1,28 +0,0 @@
-From 47f00399b195e0987c67006b329587bef0692bf4 Mon Sep 17 00:00:00 2001
-From: Thomas Pedersen <t...@codeaurora.org>
-Date: Wed, 4 May 2016 12:25:41 -0700
-Subject: [PATCH 22/69] dts: ipq4019: support ARMv7 PMU
-
-Add support for cortex-a7-pmu present on ipq4019 SoCs.
-
-Signed-off-by: Thomas Pedersen <t...@codeaurora.org>
-Signed-off-by: Matthew McClintock <mmccl...@qca.qualcomm.com>

- arch/arm/boot/dts/qcom-ipq4019.dtsi | 6 ++
- 1 file changed, 6 insertions(+)
-
 a/arch/arm/boot/dts/qcom-ipq4019.dtsi
-+++ b/arch/arm/boot/dts/qcom-ipq4019.dtsi
-@@ -108,6 +108,12 @@
-IRQ_TYPE_LEVEL_HIGH)>;
-   };
- 
-+  pmu {
-+  compatible = "arm,cortex-a7-pmu";
-+  interrupts = ;
-+  };
-+
-   clocks {
-   sleep_clk: sleep_clk {
-   compatible = "fixed-clock";
-- 
2.15.1


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

Re: [LEDE-DEV] Switches between LTS kernels and removal of previous LTSes

[Christian Lamparter]

Hello,

On Tuesday, January 9, 2018 8:07:16 AM CET Stijn Segers wrote:
> I remember there was quite a bit of gnashing of teeth, when targets in 
> master dropped 4.4 support so quickly after 17.01 had been released 
> (which made it very cumbersome to backport 4.4 kernel bumps from master 
> to the stable branch). Wouldn't it be wiser to keep 4.9 kernels around 
> for targets that are being bumped to 4.14?
Sure. This isn't a problem with the existing series.
Just defer/delete patch: "[LEDE-DEV,5/5] apm821xx: remove kernel 4.9 support"
 for now.

In fact, for the 4.4->4.9 bump Felix did it the same way.
He queued the patch that removed 4.4 support from apm821xx in his staging
repository and left it there.

Regards,
Christian

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

[LEDE-DEV] [PATCH 5/5] apm821xx: remove kernel 4.9 support

[Christian Lamparter]

Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
 target/linux/apm821xx/config-4.9   |  326 ---
 .../200-add-meraki-mr24-ikarem-support.patch   |   32 -
 .../201-add-amcc-apollo3g-support.patch|   30 -
 .../202-add-netgear-wndr4700-support.patch |   32 -
 .../203-add-meraki-mx60-buckminster-support.patch  |   32 -
 .../300-fix-atheros-nics-on-apm82181.patch |   51 -
 .../patches-4.9/301-fix-memory-map-wndr4700.patch  |   14 -
 .../701-powerpc_ibm_apm82181_phyclk_fix.patch  |   51 -
 .../702-powerpc_ibm_phy_add_dt_parser.patch|  328 ---
 ...et-emac-fix-reset-timeout-with-AR8035-phy.patch |  112 ---
 ...d-firmware-loader-for-uPD720201-and-uPD72.patch |  545 ---
 .../802-usb-xhci-force-msi-renesas-xhci.patch  |   54 -
 .../804-usb-dwc2-add-amcc-usb-otg-405ex.patch  |   48 -
 ...river-for-Microchip-TC654-TC655-PWM-fan-c.patch | 1027 
 14 files changed, 2682 deletions(-)
 delete mode 100644 target/linux/apm821xx/config-4.9
 delete mode 100644 
target/linux/apm821xx/patches-4.9/200-add-meraki-mr24-ikarem-support.patch
 delete mode 100644 
target/linux/apm821xx/patches-4.9/201-add-amcc-apollo3g-support.patch
 delete mode 100644 
target/linux/apm821xx/patches-4.9/202-add-netgear-wndr4700-support.patch
 delete mode 100644 
target/linux/apm821xx/patches-4.9/203-add-meraki-mx60-buckminster-support.patch
 delete mode 100644 
target/linux/apm821xx/patches-4.9/300-fix-atheros-nics-on-apm82181.patch
 delete mode 100644 
target/linux/apm821xx/patches-4.9/301-fix-memory-map-wndr4700.patch
 delete mode 100644 
target/linux/apm821xx/patches-4.9/701-powerpc_ibm_apm82181_phyclk_fix.patch
 delete mode 100644 
target/linux/apm821xx/patches-4.9/702-powerpc_ibm_phy_add_dt_parser.patch
 delete mode 100644 
target/linux/apm821xx/patches-4.9/703-net-emac-fix-reset-timeout-with-AR8035-phy.patch
 delete mode 100644 
target/linux/apm821xx/patches-4.9/801-usb-xhci-add-firmware-loader-for-uPD720201-and-uPD72.patch
 delete mode 100644 
target/linux/apm821xx/patches-4.9/802-usb-xhci-force-msi-renesas-xhci.patch
 delete mode 100644 
target/linux/apm821xx/patches-4.9/804-usb-dwc2-add-amcc-usb-otg-405ex.patch
 delete mode 100644 
target/linux/apm821xx/patches-4.9/901-hwmon-add-driver-for-Microchip-TC654-TC655-PWM-fan-c.patch

diff --git a/target/linux/apm821xx/config-4.9 b/target/linux/apm821xx/config-4.9
deleted file mode 100644
index c1c47a7bdd..00
--- a/target/linux/apm821xx/config-4.9
+++ /dev/null
@@ -1,326 +0,0 @@
-# CONFIG_40x is not set
-CONFIG_44x=y
-CONFIG_460EX=y
-CONFIG_4xx=y
-CONFIG_4xx_SOC=y
-# CONFIG_ADVANCED_OPTIONS is not set
-CONFIG_APM821xx=y
-CONFIG_APOLLO3G=y
-# CONFIG_ARCHES is not set
-CONFIG_ARCH_DMA_ADDR_T_64BIT=y
-CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
-CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y
-CONFIG_ARCH_HAS_DMA_SET_COHERENT_MASK=y
-CONFIG_ARCH_HAS_ELF_RANDOMIZE=y
-CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y
-CONFIG_ARCH_HAS_ILOG2_U32=y
-CONFIG_ARCH_HAS_SG_CHAIN=y
-CONFIG_ARCH_HAS_WALK_MEMORY=y
-CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y
-CONFIG_ARCH_HIBERNATION_POSSIBLE=y
-CONFIG_ARCH_MAY_HAVE_PC_FDC=y
-CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y
-CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y
-CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
-# CONFIG_ARCH_RANDOM is not set
-CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y
-CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
-CONFIG_ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT=y
-CONFIG_ARCH_SUPPORTS_UPROBES=y
-CONFIG_ARCH_SUSPEND_POSSIBLE=y
-CONFIG_ARCH_USE_BUILTIN_BSWAP=y
-CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
-CONFIG_AUDIT_ARCH=y
-# CONFIG_BAMBOO is not set
-CONFIG_BCH=y
-CONFIG_BLK_MQ_PCI=y
-# CONFIG_BLUESTONE is not set
-CONFIG_BOOKE=y
-CONFIG_BOOKE_WDT=y
-# CONFIG_BOUNCE is not set
-CONFIG_BUCKMINSTER=y
-# CONFIG_CANYONLANDS is not set
-CONFIG_CLONE_BACKWARDS=y
-CONFIG_CMDLINE="rootfstype=squashfs noinitrd"
-CONFIG_CMDLINE_BOOL=y
-CONFIG_CONSISTENT_SIZE=0x0020
-CONFIG_CPU_BIG_ENDIAN=y
-CONFIG_CRC16=y
-CONFIG_CRYPTO_DEFLATE=y
-CONFIG_CRYPTO_DEV_PPC4XX=y
-CONFIG_CRYPTO_HASH=y
-CONFIG_CRYPTO_HASH2=y
-CONFIG_CRYPTO_HW=y
-CONFIG_CRYPTO_LZO=y
-CONFIG_CRYPTO_MD5_PPC=y
-CONFIG_CRYPTO_RNG2=y
-CONFIG_CRYPTO_SHA1_PPC=y
-CONFIG_CRYPTO_WORKQUEUE=y
-CONFIG_DECOMPRESS_GZIP=y
-# CONFIG_DEFAULT_UIMAGE is not set
-CONFIG_DTC=y
-# CONFIG_E200 is not set
-CONFIG_EARLY_PRINTK=y
-# CONFIG_EBONY is not set
-CONFIG_EDAC_ATOMIC_SCRUB=y
-CONFIG_EDAC_SUPPORT=y
-# CONFIG_EIGER is not set
-# CONFIG_EPAPR_BOOT is not set
-CONFIG_EXTRA_TARGETS="uImage"
-CONFIG_FIXED_PHY=y
-CONFIG_FREEZER=y
-# CONFIG_FSL_LBC is not set
-# CONFIG_FSL_ULI1575 is not set
-CONFIG_GENERIC_ATOMIC64=y
-CONFIG_GENERIC_BUG=y
-CONFIG_GENERIC_CLOCKEVENTS=y
-CONFIG_GENERIC_CMOS_UPDATE=y
-CONFIG_GENERIC_CPU_AUTOPROBE=y
-# CONFIG_GENERIC_CSUM is not set
-CONFIG_GENERIC_IO=y
-CONFIG_GENERIC_IRQ_SHOW=y
-CONFIG_GENERIC_IRQ_SHOW_LEVEL=y
-CONFIG_GENERIC_ISA_DMA=y
-CONFIG_GENERIC_MSI_IRQ=y
-CONFIG_GENERIC_NVRAM=y
-CONFIG_GENERIC_PCI_IOMAP=y
-CONFIG

[LEDE-DEV] [PATCH 4/5] apm821xx: switch to 4.14.x kernel

[Christian Lamparter]

Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
 target/linux/apm821xx/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/apm821xx/Makefile b/target/linux/apm821xx/Makefile
index 6d711543c4..c3253322f2 100644
--- a/target/linux/apm821xx/Makefile
+++ b/target/linux/apm821xx/Makefile
@@ -13,7 +13,7 @@ MAINTAINER:=Chris Blake <chrisrblak...@gmail.com>, \
    Christian Lamparter <chunk...@gmail.com>
 SUBTARGETS:=nand sata
 
-KERNEL_PATCHVER:=4.9
+KERNEL_PATCHVER:=4.14
 
 define Target/Description
Build images for AppliedMicro APM821xx based boards.
-- 
2.15.1


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

[LEDE-DEV] [PATCH 2/5] apm821xx: convert MR24 to use DT PHY defintion

[Christian Lamparter]

Convert the MR24 to use the DT phy probing and at803x PHY driver.

Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
 target/linux/apm821xx/dts/meraki-mr24.dts  |  12 +
 target/linux/apm821xx/nand/config-default  |   1 +
 ...c-replace-custom-rgmii_mode_name-with-phy.patch |  51 +
 ...-ibm-emac-replace-custom-PHY_MODE_-macros.patch | 246 +
 ...t-ibm-emac-support-RGMII-RX-TX-ID-phymode.patch |  59 +
 5 files changed, 369 insertions(+)
 create mode 100644 
target/linux/apm821xx/patches-4.14/030-0001-net-ibm-emac-replace-custom-rgmii_mode_name-with-phy.patch
 create mode 100644 
target/linux/apm821xx/patches-4.14/030-0002-net-ibm-emac-replace-custom-PHY_MODE_-macros.patch
 create mode 100644 
target/linux/apm821xx/patches-4.14/030-0003-net-ibm-emac-support-RGMII-RX-TX-ID-phymode.patch

diff --git a/target/linux/apm821xx/dts/meraki-mr24.dts 
b/target/linux/apm821xx/dts/meraki-mr24.dts
index 2c2f8d281b..e06d37cbbd 100644
--- a/target/linux/apm821xx/dts/meraki-mr24.dts
+++ b/target/linux/apm821xx/dts/meraki-mr24.dts
@@ -89,6 +89,18 @@
 
  {
status = "okay";
+
+   phy-mode = "rgmii-id";
+   phy-map = <0x2>;
+   phy-address = <0x1>;
+   phy-handle = <>;
+
+   mdio {
+   phy: phy@1 {
+   compatible = "ethernet-phy-ieee802.3-c22";
+   reg = <1>;
+   };
+   };
 };
 
  {
diff --git a/target/linux/apm821xx/nand/config-default 
b/target/linux/apm821xx/nand/config-default
index 783305a850..ca6af461c7 100644
--- a/target/linux/apm821xx/nand/config-default
+++ b/target/linux/apm821xx/nand/config-default
@@ -1,3 +1,4 @@
+CONFIG_AT803X_PHY=y
 CONFIG_AR8216_PHY=y
 CONFIG_DMADEVICES=y
 CONFIG_DMA_ENGINE=y
diff --git 
a/target/linux/apm821xx/patches-4.14/030-0001-net-ibm-emac-replace-custom-rgmii_mode_name-with-phy.patch
 
b/target/linux/apm821xx/patches-4.14/030-0001-net-ibm-emac-replace-custom-rgmii_mode_name-with-phy.patch
new file mode 100644
index 00..28969a7b4a
--- /dev/null
+++ 
b/target/linux/apm821xx/patches-4.14/030-0001-net-ibm-emac-replace-custom-rgmii_mode_name-with-phy.patch
@@ -0,0 +1,51 @@
+From 54e1b3004eb85f9317f6c4ceff2e097231c7f52a Mon Sep 17 00:00:00 2001
+From: Christian Lamparter <chunk...@gmail.com>
+Date: Wed, 20 Dec 2017 22:11:22 +0100
+Subject: [PATCH 1/3] net: ibm: emac: replace custom rgmii_mode_name with
+ phy_modes
+
+The common phylib defines the same names (in lower-case).
+Since rgmii_mode_name() is used only in one place and
+for a "notice-level" printk, I think it can be replaced.
+
+Signed-off-by: Christian Lamparter <chunk...@gmail.com>
+---
+ drivers/net/ethernet/ibm/emac/rgmii.c | 20 +---
+ 1 file changed, 1 insertion(+), 19 deletions(-)
+
+--- a/drivers/net/ethernet/ibm/emac/rgmii.c
 b/drivers/net/ethernet/ibm/emac/rgmii.c
+@@ -59,24 +59,6 @@ static inline int rgmii_valid_mode(int p
+   phy_mode == PHY_MODE_RTBI;
+ }
+ 
+-static inline const char *rgmii_mode_name(int mode)
+-{
+-  switch (mode) {
+-  case PHY_MODE_RGMII:
+-  return "RGMII";
+-  case PHY_MODE_TBI:
+-  return "TBI";
+-  case PHY_MODE_GMII:
+-  return "GMII";
+-  case PHY_MODE_MII:
+-  return "MII";
+-  case PHY_MODE_RTBI:
+-  return "RTBI";
+-  default:
+-  BUG();
+-  }
+-}
+-
+ static inline u32 rgmii_mode_mask(int mode, int input)
+ {
+   switch (mode) {
+@@ -115,7 +97,7 @@ int rgmii_attach(struct platform_device
+   out_be32(>fer, in_be32(>fer) | rgmii_mode_mask(mode, input));
+ 
+   printk(KERN_NOTICE "%pOF: input %d in %s mode\n",
+- ofdev->dev.of_node, input, rgmii_mode_name(mode));
++ ofdev->dev.of_node, input, phy_modes(mode));
+ 
+   ++dev->users;
+ 
diff --git 
a/target/linux/apm821xx/patches-4.14/030-0002-net-ibm-emac-replace-custom-PHY_MODE_-macros.patch
 
b/target/linux/apm821xx/patches-4.14/030-0002-net-ibm-emac-replace-custom-PHY_MODE_-macros.patch
new file mode 100644
index 00..e4a722646e
--- /dev/null
+++ 
b/target/linux/apm821xx/patches-4.14/030-0002-net-ibm-emac-replace-custom-PHY_MODE_-macros.patch
@@ -0,0 +1,246 @@
+From 1477bea9e6931f6be96f45b9d277690a26d0cd97 Mon Sep 17 00:00:00 2001
+From: Christian Lamparter <chunk...@gmail.com>
+Date: Wed, 20 Dec 2017 22:19:24 +0100
+Subject: [PATCH 2/3] net: ibm: emac: replace custom PHY_MODE_* macros
+
+The ibm_emac driver predates the shared PHY_INTERFACE_MODE_
+enums provided by include/linux/phy.h by a few years.
+
+And while the driver has been retrofitted to use the PHYLIB,
+the old definitions have stuck around to this day.
+
+Signed-off-by: Christian Lamparter <chunk...@gmail.com>
+---
+ drivers/net/ethernet/ibm/emac/core.c  | 20 ++-

[LEDE-DEV] [PATCH 5/6] firmware: ath10k-firmware: update QCA9887 firmware to 10.2.4-1.0-00033

[Christian Lamparter]

This patch updates ath10k-firmware to use the
firmware-5.bin_10.2.4-1.0-00033 firmware for the QCA9887.

Cc: Hauke Mehrtens <ha...@hauke-m.de>
Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
Can anyone test it?
---
 package/firmware/ath10k-firmware/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/firmware/ath10k-firmware/Makefile 
b/package/firmware/ath10k-firmware/Makefile
index 456db5e07f..87bce77403 100644
--- a/package/firmware/ath10k-firmware/Makefile
+++ b/package/firmware/ath10k-firmware/Makefile
@@ -230,7 +230,7 @@ endef
 define Package/ath10k-firmware-qca9887/install
$(INSTALL_DIR) $(1)/lib/firmware/ath10k/QCA9887/hw1.0
$(INSTALL_DATA) \
-   
$(PKG_BUILD_DIR)/QCA9887/hw1.0/10.2.4-1.0/firmware-5.bin_10.2.4-1.0-00029 \
+   
$(PKG_BUILD_DIR)/QCA9887/hw1.0/10.2.4-1.0/firmware-5.bin_10.2.4-1.0-00033 \
$(1)/lib/firmware/ath10k/QCA9887/hw1.0/firmware-5.bin
$(INSTALL_DATA) \
$(PKG_BUILD_DIR)/QCA9887/hw1.0/board.bin \
-- 
2.15.1


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

[LEDE-DEV] [PATCH 6/6] firmware: ath10k-firmware: update QCA988x firmware to 10.2.4-1.0-00033

[Christian Lamparter]

This patch updates ath10k-firmware to use the
firmware-5.bin_10.2.4-1.0-00033 firmware for the QCA988x.

Cc: Hauke Mehrtens <ha...@hauke-m.de>
Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
 package/firmware/ath10k-firmware/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/firmware/ath10k-firmware/Makefile 
b/package/firmware/ath10k-firmware/Makefile
index 87bce77403..5f2c3f014c 100644
--- a/package/firmware/ath10k-firmware/Makefile
+++ b/package/firmware/ath10k-firmware/Makefile
@@ -253,7 +253,7 @@ define Package/ath10k-firmware-qca988x/install
$(PKG_BUILD_DIR)/QCA988X/hw2.0/board.bin \
$(1)/lib/firmware/ath10k/QCA988X/hw2.0/
$(INSTALL_DATA) \
-   
$(PKG_BUILD_DIR)/QCA988X/hw2.0/10.2.4-1.0/firmware-5.bin_10.2.4-1.0-00029 \
+   
$(PKG_BUILD_DIR)/QCA988X/hw2.0/10.2.4-1.0/firmware-5.bin_10.2.4-1.0-00033 \
$(1)/lib/firmware/ath10k/QCA988X/hw2.0/firmware-5.bin
 endef
 
-- 
2.15.1


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

[LEDE-DEV] [PATCH 4/6] firmware: ath10k-firmware: update QCA9888 firmware to 10.4-3.4-00104

[Christian Lamparter]

This patch updates ath10k-firmware to use the
firmware-5.bin_10.4-3.4-00104 firmware for the QCA9888.

Cc: Henryk Heisig <hy...@o2.pl>
Cc: Hauke Mehrtens <ha...@hauke-m.de>
Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
Can anyone test it?
---
 package/firmware/ath10k-firmware/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/firmware/ath10k-firmware/Makefile 
b/package/firmware/ath10k-firmware/Makefile
index 0497538920..456db5e07f 100644
--- a/package/firmware/ath10k-firmware/Makefile
+++ b/package/firmware/ath10k-firmware/Makefile
@@ -243,7 +243,7 @@ define Package/ath10k-firmware-qca9888/install
$(PKG_BUILD_DIR)/QCA9888/hw2.0/board-2.bin \
$(1)/lib/firmware/ath10k/QCA9888/hw2.0/board-2.bin
$(INSTALL_DATA) \
-   $(PKG_BUILD_DIR)/QCA9888/hw2.0/firmware-5.bin_10.4-3.2-00072 \
+   
$(PKG_BUILD_DIR)/QCA9888/hw2.0/3.4/firmware-5.bin_10.4-3.4-00104 \
$(1)/lib/firmware/ath10k/QCA9888/hw2.0/firmware-5.bin
 endef
 
-- 
2.15.1


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

[LEDE-DEV] [PATCH 3/6] firmware: ath10k-firmware: update QCA9984 firmware to 10.4-3.4-00104

[Christian Lamparter]

This patch updates ath10k-firmware to use the
firmware-5.bin_10.4-3.4-00104 firmware for the QCA9984.

Cc: Ansuel Smith <ansuels...@gmail.com>
Cc: Hauke Mehrtens <ha...@hauke-m.de>
Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
 package/firmware/ath10k-firmware/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/firmware/ath10k-firmware/Makefile 
b/package/firmware/ath10k-firmware/Makefile
index b5c8fe3f5f..0497538920 100644
--- a/package/firmware/ath10k-firmware/Makefile
+++ b/package/firmware/ath10k-firmware/Makefile
@@ -314,7 +314,7 @@ define Package/ath10k-firmware-qca9984/install
$(PKG_BUILD_DIR)/QCA9984/hw1.0/board-2.bin \
$(1)/lib/firmware/ath10k/QCA9984/hw1.0/board-2.bin
$(INSTALL_DATA) \
-   
$(PKG_BUILD_DIR)/QCA9984/hw1.0/3.4/firmware-5.bin_10.4-3.4-00082 \
+   
$(PKG_BUILD_DIR)/QCA9984/hw1.0/3.4/firmware-5.bin_10.4-3.4-00104 \
$(1)/lib/firmware/ath10k/QCA9984/hw1.0/firmware-5.bin
 endef
 
-- 
2.15.1


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

[LEDE-DEV] [PATCH 1/6] firmware: ath10k-firmware: update to 2017-12-20

[Christian Lamparter]

This update automatically includes a new firmware for the QCA6174:
firmware-6.bin_WLAN.RM.4.4.1-00079-QCARMSWPZ-1

Cc: Ansuel Smith <ansuels...@gmail.com>
Cc: Hauke Mehrtens <ha...@hauke-m.de>
Cc: Henryk Heisig <hy...@o2.pl>
Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
@Ansuel Smith
Can you test if the new QCA9984 firmware fixes the problem you
reported in:
<https://www.mail-archive.com/ath10k@lists.infradead.org/msg07592.html>?
---
 package/firmware/ath10k-firmware/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/firmware/ath10k-firmware/Makefile 
b/package/firmware/ath10k-firmware/Makefile
index 1c6f4dfb7f..5a7fa1ac95 100644
--- a/package/firmware/ath10k-firmware/Makefile
+++ b/package/firmware/ath10k-firmware/Makefile
@@ -8,9 +8,9 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=ath10k-firmware
-PKG_SOURCE_DATE:=2017-10-30
-PKG_SOURCE_VERSION:=476a2850b1e8582d51187799d7de209daf1a57b2
-PKG_MIRROR_HASH:=77ba59f75c5897c842c5c525945de019fd23f1e2d8bea6239924857e500bf73a
+PKG_SOURCE_DATE:=2017-12-20
+PKG_SOURCE_VERSION:=35d8642f452827b955470de4ac997ffe906a6f17
+PKG_MIRROR_HASH:=594133cea1b49672d0a47ca55fdd9390af83b514b37e864e3674d7ab5d7dd72a
 PKG_RELEASE:=1

 PKG_SOURCE_PROTO:=git
-- 
2.15.1


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

[LEDE-DEV] [PATCH 2/6] firmware: ath10k-firmware: update QCA4019 firmware to 10.4-3.4-00104

[Christian Lamparter]

This patch updates ath10k-firmware to use the
firmware-5.bin_10.4-3.4-00104 firmware for the QCA4019.

Cc: Hauke Mehrtens <ha...@hauke-m.de>
Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
 package/firmware/ath10k-firmware/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/firmware/ath10k-firmware/Makefile 
b/package/firmware/ath10k-firmware/Makefile
index 5a7fa1ac95..b5c8fe3f5f 100644
--- a/package/firmware/ath10k-firmware/Makefile
+++ b/package/firmware/ath10k-firmware/Makefile
@@ -223,7 +223,7 @@ define Package/ath10k-firmware-qca4019/install
$(PKG_BUILD_DIR)/QCA4019/hw1.0/board-2.bin \
$(1)/lib/firmware/ath10k/QCA4019/hw1.0/
$(INSTALL_DATA) \
-   
$(PKG_BUILD_DIR)/QCA4019/hw1.0/3.2.1/firmware-5.bin_10.4-3.2.1-00058 \
+   
$(PKG_BUILD_DIR)/QCA4019/hw1.0/3.4/firmware-5.bin_10.4-3.4-00104 \
$(1)/lib/firmware/ath10k/QCA4019/hw1.0/firmware-5.bin
 endef
 
-- 
2.15.1


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

[LEDE-DEV] [PATCH 4/4] brcm2708: use x86's upgrade scripts for all rpi targets

[Christian Lamparter]

Advantages:
 - preserves existing partition layout on the sd-card.
   Only the boot and rootfs partition will be overwritten.

Please note that sysupgrade will refuse to upgrade, if the existing
installation  has an incompatible partition layout. Future changes
to the bootfs and/or rootfs partition size will likely cause breakage
to the sysupgrade procedure. In these cases, the ext4-sdcard.img.gz
will have to be written to the sdcard manually.
Please don't forget to backup your configuration in this case.

Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
 .../brcm2708/base-files/lib/upgrade/platform.sh| 102 +++--
 1 file changed, 93 insertions(+), 9 deletions(-)

diff --git a/target/linux/brcm2708/base-files/lib/upgrade/platform.sh 
b/target/linux/brcm2708/base-files/lib/upgrade/platform.sh
index 5b8e1e15b3..b9cd8d282f 100644
--- a/target/linux/brcm2708/base-files/lib/upgrade/platform.sh
+++ b/target/linux/brcm2708/base-files/lib/upgrade/platform.sh
@@ -1,20 +1,104 @@
+. /lib/functions.sh
+
 REQUIRE_IMAGE_METADATA=1
 
+# copied from x86's platform.sh
+
 platform_check_image() {
-   return 0
+   local diskdev partdev diff
+
+   [ "$#" -gt 1 ] && return 1
+
+   export_bootdevice && export_partdevice diskdev -2 || {
+   echo "Unable to determine upgrade device"
+   return 1
+   }
+
+   get_partitions "/dev/$diskdev" bootdisk
+
+   #extract the boot sector from the image
+   get_image "$@" | dd of=/tmp/image.bs count=1 bs=512b 2>/dev/null
+
+   get_partitions /tmp/image.bs image
+
+   #compare tables
+   diff="$(grep -F -x -v -f /tmp/partmap.bootdisk /tmp/partmap.image)"
+
+   rm -f /tmp/image.bs /tmp/partmap.bootdisk /tmp/partmap.image
+
+   if [ -n "$diff" ]; then
+   echo "Partition layout has changed. Full image will be written."
+   ask_bool 0 "Abort" && exit 1
+   return 0
+   fi
+
+   return 0;
 }
 
 platform_do_upgrade() {
+   local diskdev partdev diff
+
+   export_bootdevice && export_partdevice diskdev -2 || {
+   echo "Unable to determine upgrade device"
+   return 1
+   }
+
sync
-   get_image "$1" | dd of=/dev/mmcblk0 bs=2M conv=fsync
-   sleep 1
+
+   if [ "$SAVE_PARTITIONS" = "1" ]; then
+   get_partitions "/dev/$diskdev" bootdisk
+
+   #extract the boot sector from the image
+   get_image "$@" | dd of=/tmp/image.bs count=1 bs=512b
+
+   get_partitions /tmp/image.bs image
+
+   #compare tables
+   diff="$(grep -F -x -v -f /tmp/partmap.bootdisk 
/tmp/partmap.image)"
+   else
+   diff=1
+   fi
+
+   if [ -n "$diff" ]; then
+   get_image "$@" | dd of="/dev/$diskdev" bs=2M conv=fsync
+
+   # Separate removal and addtion is necessary; otherwise, 
partition 1
+   # will be missing if it overlaps with the old partition 2
+   partx -d - "/dev/$diskdev"
+   partx -a - "/dev/$diskdev"
+
+   return 0
+   fi
+
+   #iterate over each partition from the image and write it to the boot 
disk
+   while read part start size; do
+   # root is /dev/sd[a|b]2 and not /dev/sd[a|b] this causes some 
problem
+   # one of which is this offset, I'm not sure what's the best 
fix, so
+   # here's a WA.
+   let part=$((part - 2))
+   if export_partdevice partdev $part; then
+   echo "Writing image to /dev/$partdev..."
+   get_image "$@" | dd of="/dev/$partdev" ibs="512" obs=1M 
skip="$start" count="$size" conv=fsync
+   else
+   echo "Unable to find partition $part device, skipped."
+   fi
+   done < /tmp/partmap.image
+
+   #copy partition uuid
+   echo "Writing new UUID to /dev/$diskdev..."
+   get_image "$@" | dd of="/dev/$diskdev" bs=1 skip=440 count=4 seek=440 
conv=fsync
 }
 
 platform_copy_config() {
-   mkdir -p /boot
-   [ -f /boot/kernel.img ] || mount -t vfat -o rw,noatime /dev/mmcblk0p1 
/boot
-   cp -af "$CONF_TAR" /boot/
-   tar --directory / -xvf "$CONF_TAR" boot/config.txt
-   sync
-   umount /boot
+   local partdev
+
+   # Same as above /dev/sd[a|b]2 is root, so /boot is -1
+   if export_partdevice partdev -1; then
+   mkdir -p /boot
+   [ -f /boot/kernel.img ] || mount -t vfat -o rw,noatime 
"/dev/$partdev" /boot
+   cp -af "$CONF_TAR" /boot/
+   tar --directory / -xvf "$CONF_TAR" boot/config.txt
+   sync
+   unmount /boot
+   fi
 }
-- 
2.15.1


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

[LEDE-DEV] [PATCH 2/4] brcm2708: add compatible strings

[Christian Lamparter]

This patch adds the compatible string for the various RPIs from
4.14 upstream.

Note: The 4.14 upstream does not include the compute modules.
If the CM* would just house the SoC, it could in theory use the
"raw" chip compatible string. However, these CM boards also come
with RAM and eMMC. So they have to have a proper comaptible.

For now, "raspberrypi,compute-module-{1|3}" will be good enough.

Note2: The original CM was renamed to CM1 when CM3 was released.

Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
 .../960-add-rasbperrypi-compatible.patch   | 70 ++
 1 file changed, 70 insertions(+)
 create mode 100644 
target/linux/brcm2708/patches-4.9/960-add-rasbperrypi-compatible.patch

diff --git 
a/target/linux/brcm2708/patches-4.9/960-add-rasbperrypi-compatible.patch 
b/target/linux/brcm2708/patches-4.9/960-add-rasbperrypi-compatible.patch
new file mode 100644
index 00..db2f6c9b80
--- /dev/null
+++ b/target/linux/brcm2708/patches-4.9/960-add-rasbperrypi-compatible.patch
@@ -0,0 +1,70 @@
+--- a/arch/arm/boot/dts/bcm2708-rpi-0-w.dts2017-12-01 00:09:35.165577128 
+0100
 b/arch/arm/boot/dts/bcm2708-rpi-0-w.dts2017-12-01 00:10:02.418981698 
+0100
+@@ -4,6 +4,7 @@
+ #include "bcm283x-rpi-smsc9512.dtsi"
+ 
+ / {
++  compatible = "raspberrypi,model-zero-w", "brcm,bcm2835";
+   model = "Raspberry Pi Zero W";
+ };
+ 
+--- a/arch/arm/boot/dts/bcm2710-rpi-3-b.dts2017-12-01 00:23:43.869682792 
+0100
 b/arch/arm/boot/dts/bcm2710-rpi-3-b.dts2017-12-01 00:25:07.686338314 
+0100
+@@ -8,6 +8,7 @@
+ #include "bcm283x-rpi-smsc9514.dtsi"
+ 
+ / {
++  compatible = "raspberrypi,3-model-b", "brcm,bcm2837", "brcm,bcm2836";
+   model = "Raspberry Pi 3 Model B";
+ };
+ 
+--- a/arch/arm/boot/dts/bcm2709-rpi-2-b.dts2017-12-01 00:24:16.899675426 
+0100
 b/arch/arm/boot/dts/bcm2709-rpi-2-b.dts2017-12-01 00:24:53.973005148 
+0100
+@@ -4,6 +4,7 @@
+ #include "bcm283x-rpi-smsc9514.dtsi"
+ 
+ / {
++  compatible = "raspberrypi,2-model-b", "brcm,bcm2836";
+   model = "Raspberry Pi 2 Model B";
+ };
+ 
+--- a/arch/arm/boot/dts/bcm2708-rpi-b.dts  2017-12-01 00:32:37.426847451 
+0100
 b/arch/arm/boot/dts/bcm2708-rpi-b.dts  2017-12-01 00:33:22.656955034 
+0100
+@@ -4,6 +4,7 @@
+ #include "bcm283x-rpi-smsc9512.dtsi"
+ 
+ / {
++  compatible = "raspberrypi,model-b", "brcm,bcm2835";
+   model = "Raspberry Pi Model B";
+ };
+ 
+--- a/arch/arm/boot/dts/bcm2708-rpi-b-plus.dts 2017-12-01 00:34:04.227056139 
+0100
 b/arch/arm/boot/dts/bcm2708-rpi-b-plus.dts 2017-12-01 00:33:48.953685419 
+0100
+@@ -4,6 +4,7 @@
+ #include "bcm283x-rpi-smsc9514.dtsi"
+ 
+ / {
++  compatible = "raspberrypi,model-b-plus", "brcm,bcm2835";
+   model = "Raspberry Pi Model B+";
+ };
+ 
+--- a/arch/arm/boot/dts/bcm2708-rpi-cm.dts 2017-12-01 00:21:41.226415322 
+0100
 b/arch/arm/boot/dts/bcm2708-rpi-cm.dts 2017-12-01 00:21:08.206444802 
+0100
+@@ -3,6 +3,7 @@
+ #include "bcm2708-rpi-cm.dtsi"
+ 
+ / {
++  compatible = "raspberrypi,compute-module-1", "brcm,bcm2835";
+   model = "Raspberry Pi Compute Module";
+ };
+ 
+--- a/arch/arm/boot/dts/bcm2710-rpi-cm3.dts2017-12-01 00:40:17.454702202 
+0100
 b/arch/arm/boot/dts/bcm2710-rpi-cm3.dts2017-12-01 00:40:10.521349773 
+0100
+@@ -3,6 +3,7 @@
+ #include "bcm2710.dtsi"
+ 
+ / {
++  compatible = "raspberrypi,compute-module-3", "brcm,bcm2837", 
"brcm,bcm2836";
+   model = "Raspberry Pi Compute Module 3";
+ };
+ 
-- 
2.15.1


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

[LEDE-DEV] [PATCH 1/4] brcm2708: convert to metadata

[Christian Lamparter]

This patch converts all the raspberrypi images to utilize
the common metadata-based image verification.

Note: the CM1 and CM3 currently use the same "rpi-cm"
boardname.

Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
 .../linux/brcm2708/base-files/lib/upgrade/platform.sh   | 17 ++---
 target/linux/brcm2708/image/Makefile|  7 +--
 2 files changed, 7 insertions(+), 17 deletions(-)

diff --git a/target/linux/brcm2708/base-files/lib/upgrade/platform.sh 
b/target/linux/brcm2708/base-files/lib/upgrade/platform.sh
index b7613b446d..5b8e1e15b3 100644
--- a/target/linux/brcm2708/base-files/lib/upgrade/platform.sh
+++ b/target/linux/brcm2708/base-files/lib/upgrade/platform.sh
@@ -1,20 +1,7 @@
-get_magic_at() {
-   local file="$1"
-   local pos="$2"
-   get_image "$file" | dd bs=1 count=2 skip="$pos" 2>/dev/null | hexdump 
-v -n 2 -e '1/1 "%02x"'
-}
+REQUIRE_IMAGE_METADATA=1
 
 platform_check_image() {
-   local file="$1"
-   local magic
-
-   magic=$(get_magic_at "$file" 510)
-   [ "$magic" != "55aa" ] && {
-   echo "Failed to verify MBR boot signature."
-   return 1
-   }
-
-   return 0;
+   return 0
 }
 
 platform_do_upgrade() {
diff --git a/target/linux/brcm2708/image/Makefile 
b/target/linux/brcm2708/image/Makefile
index 7909c6d814..41730b6803 100644
--- a/target/linux/brcm2708/image/Makefile
+++ b/target/linux/brcm2708/image/Makefile
@@ -50,13 +50,14 @@ define Device/Default
   FILESYSTEMS := ext4
   KERNEL := kernel-bin | kernel-img
   KERNEL_IMG := kernel.img
-  IMAGES := sdcard.img
-  IMAGE/sdcard.img := boot-img | sdcard-img
+  IMAGES := sdcard.img.gz
+  IMAGE/sdcard.img.gz := boot-img | sdcard-img | gzip | append-metadata
 endef
 
 define Device/rpi
   DEVICE_TITLE := Raspberry Pi B/B+/CM/Zero/ZeroW
   DEVICE_DTS := bcm2708-rpi-b bcm2708-rpi-b-plus bcm2708-rpi-cm bcm2708-rpi-0-w
+  SUPPORTED_DEVICES := rpi-b rpi-b-plus rpi-cm rpi-zero-w
 endef
 ifeq ($(SUBTARGET),bcm2708)
   TARGET_DEVICES += rpi
@@ -65,6 +66,7 @@ endif
 define Device/rpi-2
   DEVICE_TITLE := Raspberry Pi 2B/3B/3CM
   DEVICE_DTS := bcm2709-rpi-2-b bcm2710-rpi-3-b bcm2710-rpi-cm3
+  SUPPORTED_DEVICES := rpi-2-b rpi-3-b rpi-cm
 endef
 ifeq ($(SUBTARGET),bcm2709)
   TARGET_DEVICES += rpi-2
@@ -74,6 +76,7 @@ define Device/rpi-3
   KERNEL_IMG := kernel8.img
   DEVICE_TITLE := Raspberry Pi 3B (64 bit)
   DEVICE_DTS := broadcom/bcm2710-rpi-3-b
+  SUPPORTED_DEVICES := rpi-3-b
 endef
 ifeq ($(SUBTARGET),bcm2710)
   TARGET_DEVICES += rpi-3
-- 
2.15.1


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

[LEDE-DEV] [PATCH 3/4] brcm2708: convert to dt-based board-detection

[Christian Lamparter]

Use the values populated by the generic board detect function. The
first compatible from the device tree source file will be the board
name in userspace. The model property from the device tree source file
will be the model name.

Change the board name where used in the userspace and drop the target
specific board detect, to use the generic one.

Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
 .../brcm2708/base-files/etc/board.d/02_network | 12 +++---
 target/linux/brcm2708/base-files/etc/diag.sh   | 11 +++---
 target/linux/brcm2708/base-files/lib/brcm2708.sh   | 43 --
 .../lib/preinit/01_preinit_do_brcm2708.sh  | 10 -
 .../lib/preinit/05_set_preinit_iface_brcm2708  |  9 +++--
 target/linux/brcm2708/image/Makefile   |  6 +--
 6 files changed, 20 insertions(+), 71 deletions(-)
 delete mode 100644 target/linux/brcm2708/base-files/lib/brcm2708.sh
 delete mode 100644 
target/linux/brcm2708/base-files/lib/preinit/01_preinit_do_brcm2708.sh

diff --git a/target/linux/brcm2708/base-files/etc/board.d/02_network 
b/target/linux/brcm2708/base-files/etc/board.d/02_network
index 29bcf33e33..a9c947b65a 100755
--- a/target/linux/brcm2708/base-files/etc/board.d/02_network
+++ b/target/linux/brcm2708/base-files/etc/board.d/02_network
@@ -11,13 +11,15 @@ board_config_update
 board=$(board_name)
 
 case "$board" in
-rpi-2-b |\
-rpi-3-b |\
-rpi-b |\
-rpi-b-plus)
+raspberrypi,model-b |\
+raspberrypi,model-b-plus |\
+raspberrypi,model-b-rev2 |\
+raspberrypi,2-model-b |\
+raspberrypi,3-model-b)
ucidef_set_interface_lan "eth0"
;;
-rpi-zero-w)
+
+raspberrypi,model-zero-w)
ucidef_set_interface_lan "wlan0"
;;
 esac
diff --git a/target/linux/brcm2708/base-files/etc/diag.sh 
b/target/linux/brcm2708/base-files/etc/diag.sh
index 6f5810ed58..ce0f591517 100644
--- a/target/linux/brcm2708/base-files/etc/diag.sh
+++ b/target/linux/brcm2708/base-files/etc/diag.sh
@@ -7,14 +7,13 @@
 
 set_state() {
case "$(board_name)" in
-   rpi-2-b |\
-   rpi-b-plus)
+   raspberrypi,2-model-b |\
+   raspberrypi,model-b-plus)
status_led="led1"
;;
-   rpi-b |\
-   rpi-cm |\
-   rpi-zero |\
-   rpi-zero-w)
+   raspberrypi,model-b |\
+   raspberrypi,model-zero |\
+   raspberrypi,model-zero-w)
status_led="led0"
;;
esac
diff --git a/target/linux/brcm2708/base-files/lib/brcm2708.sh 
b/target/linux/brcm2708/base-files/lib/brcm2708.sh
deleted file mode 100644
index 76e678ff97..00
--- a/target/linux/brcm2708/base-files/lib/brcm2708.sh
+++ /dev/null
@@ -1,43 +0,0 @@
-#!/bin/sh
-# Copyright (C) 2015-2016 OpenWrt.org
-# Copyright (C) 2017 LEDE project
-
-ifname=""
-
-brcm2708_detect() {
-   local board_name model
-
-   model=$(cat /proc/device-tree/model)
-   case "$model" in
-   "Raspberry Pi 2 Model B Rev"*)
-   board_name="rpi-2-b"
-   ;;
-   "Raspberry Pi 3 Model B Rev"*)
-   board_name="rpi-3-b"
-   ;;
-   "Raspberry Pi Compute Module Rev"*)
-   board_name="rpi-cm"
-   ;;
-   "Raspberry Pi Model B Plus Rev"* |\
-   "Raspberry Pi Model B+ Rev"*)
-   board_name="rpi-b-plus"
-   ;;
-   "Raspberry Pi Model B Rev"*)
-   board_name="rpi-b"
-   ;;
-   "Raspberry Pi Zero Rev"*)
-   board_name="rpi-zero"
-   ;;
-   "Raspberry Pi Zero W Rev"*)
-   board_name="rpi-zero-w"
-   ;;
-   *)
-   board_name="unknown"
-   ;;
-   esac
-
-   [ -e "/tmp/sysinfo" ] || mkdir -p "/tmp/sysinfo"
-
-   echo "$board_name" > /tmp/sysinfo/board_name
-   echo "$model" > /tmp/sysinfo/model
-}
diff --git 
a/target/linux/brcm2708/base-files/lib/preinit/01_preinit_do_brcm2708.sh 
b/target/linux/brcm2708/base-files/lib/preinit/01_preinit_do_brcm2708.sh
deleted file mode 100644
index 294364848d..00
--- a/target/linux/brcm2708/base-files/lib/preinit/01_preinit_do_brcm2708.sh
+++ /dev/null
@@ -1,10 +0,0 @@
-#!/bin/sh
-# Copyright (C) 2015 OpenWrt.org
-
-do_brcm2708() {
-   . /lib/brcm2708.sh
-
-   brcm2708_detect
-}
-
-boot_hook_add preinit_main do_brcm2708
diff --git 
a/target/linux/brcm2708/base-files/lib/preinit/05_set_preinit_iface_brcm2708 
b/target/linux/brcm2708/base-files/lib/preinit/05_set_preinit_iface_brcm2708
index 95497cc586..76eb5905e8 100644
--- a/target/linux/brcm2708/base-files/lib/preinit/05_set_preinit_iface_brcm2708
+++ b/target/linux/brcm2708/base-files/lib/preinit/05_set_preinit_iface_brcm2708
@

[LEDE-DEV] [PATCH 8/9] apm821xx: enable metadata for packaging

[Christian Lamparter]

This patch enables metadata-supported image verification
for all apm821xx supported devices. Since this method comes
with a built-in image verification tool (fwtool), the previous
image checks can be removed.

Signed-off-by: Mathias Kresin <d...@kresin.me>
Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
 .../apm821xx/base-files/lib/upgrade/merakinand.sh  | 68 --
 .../apm821xx/base-files/lib/upgrade/platform.sh| 15 ++---
 target/linux/apm821xx/image/Makefile   |  9 +--
 3 files changed, 9 insertions(+), 83 deletions(-)
 delete mode 100755 target/linux/apm821xx/base-files/lib/upgrade/merakinand.sh

diff --git a/target/linux/apm821xx/base-files/lib/upgrade/merakinand.sh 
b/target/linux/apm821xx/base-files/lib/upgrade/merakinand.sh
deleted file mode 100755
index fb961b8945..00
--- a/target/linux/apm821xx/base-files/lib/upgrade/merakinand.sh
+++ /dev/null
@@ -1,68 +0,0 @@
-#!/bin/sh
-#
-# Copyright (C) 2016 Chris Blake <chrisrblak...@gmail.com>
-#
-# Custom upgrade script for Meraki NAND devices (ex. MR24)
-# Based on merakinand.sh from the ar71xx target
-#
-. /lib/apm821xx.sh
-. /lib/functions.sh
-
-merakinand_do_kernel_check() {
-   local board_name="$1"
-   local tar_file="$2"
-   local image_magic_word=`(tar xf $tar_file sysupgrade-$board_name/kernel 
-O 2>/dev/null | dd bs=1 count=4 skip=0 2>/dev/null | hexdump -v -n 4 -e '1/1 
"%02x"')`
-
-   # What is our kernel magic string?
-   case "$board_name" in
-   "mr24"|\
-   "mx60")
-   [ "$image_magic_word" == "8e73ed8a" ] && {
-   echo "pass" && return 0
-   }
-   ;;
-   esac
-
-   exit 1
-}
-
-merakinand_do_platform_check() {
-   local board_name="$1"
-   local tar_file="$2"
-   local control_length=`(tar xf $tar_file sysupgrade-$board_name/CONTROL 
-O | wc -c) 2> /dev/null`
-   local file_type="$(identify_tar $2 sysupgrade-$board_name/root)"
-   local kernel_magic="$(merakinand_do_kernel_check $1 $2)"
-
-   case "$board_name" in
-   "mr24"|\
-   "mx60")
-   [ "$control_length" = 0 -o "$file_type" != "squashfs" -o 
"$kernel_magic" != "pass" ] && {
-   echo "Invalid sysupgrade file for $board_name"
-   return 1
-   }
-   ;;
-   *)
-   echo "Unsupported device $board_name";
-   return 1
-   ;;
-   esac
-
-   return 0
-}
-
-merakinand_do_upgrade() {
-   local tar_file="$1"
-   local board_name="$(board_name)"
-
-   # Do we need to do any platform tweaks?
-   case "$board_name" in
-   "mr24"|\
-   "mx60")
-   nand_do_upgrade $1
-   ;;
-   *)
-   echo "Unsupported device $board_name";
-   exit 1
-   ;;
-   esac
-}
diff --git a/target/linux/apm821xx/base-files/lib/upgrade/platform.sh 
b/target/linux/apm821xx/base-files/lib/upgrade/platform.sh
index 8c716bf44e..ecfd70b9ee 100755
--- a/target/linux/apm821xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/apm821xx/base-files/lib/upgrade/platform.sh
@@ -1,6 +1,7 @@
 #!/bin/sh
 
 PART_NAME=firmware
+REQUIRE_IMAGE_METADATA=1
 
 platform_check_image() {
local board=$(board_name)
@@ -14,14 +15,9 @@ platform_check_image() {
;;
 
mr24|\
-   mx60)
-   merakinand_do_platform_check $board "$1"
-   return $?;
-   ;;
-
+   mx60|\
wndr4700)
-   nand_do_platform_check $board "$1"
-   return $?;
+   return 0;
;;
 
*)
@@ -37,10 +33,7 @@ platform_pre_upgrade() {
 
case "$board" in
mr24|\
-   mx60)
-   merakinand_do_upgrade "$1"
-   ;;
-
+   mx60|\
wndr4700)
nand_do_upgrade "$1"
;;
diff --git a/target/linux/apm821xx/image/Makefile 
b/target/linux/apm821xx/image/Makefile
index bff3947039..251ef5f359 100644
--- a/target/linux/apm821xx/image/Makefile
+++ b/target/linux/apm821xx/image/Makefile
@@ -14,6 +14,7 @@ define Device/Default
   KERNEL_ENTRY := 0x
   KERNEL_LOADADDR := 0x
   DEVICE_DTS_DIR := ../dts
+  SUPPORTED_DEVICES = $$(BOARD_NAME)
 endef
 
 define Build/dtb
@@ -81,7 +82,7 @@ define Device/meraki_mr24
  check-size $$(KERNEL_SIZE) | \
  MerakiAdd-dtb | pad-to 2047k | MerakiAdd-initramfs | \
  MerakiNAND
-  IMAGE/sysupgrade.tar := sysup

[LEDE-DEV] [PATCH 9/9] apm821xx: convert to device-tree board detection

[Christian Lamparter]

This patch converts all apm821xx devices to the device-tree
board-detection method. All instances of the legacy
boardnames (mbl,mr24,...) are converted to "vendor,device"
identifier.

The custom board-detection code in apm821xx.sh is removed as
it no longer serves any purpose.

Signed-off-by: Mathias Kresin <d...@kresin.me>
Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
 .../linux/apm821xx/base-files/etc/board.d/01_leds  |  9 +++--
 .../apm821xx/base-files/etc/board.d/02_network |  9 +++--
 .../etc/hotplug.d/firmware/10-ath9k-eeprom |  4 +-
 target/linux/apm821xx/base-files/lib/apm821xx.sh   | 43 --
 .../lib/preinit/01_preinit_do_apm821xx.sh  |  9 -
 .../lib/preinit/05_set_iface_mac_apm821xx  |  4 +-
 .../lib/preinit/05_set_preinit_iface_apm821xx  |  2 -
 .../apm821xx/base-files/lib/preinit/79_move_config | 18 ++---
 .../apm821xx/base-files/lib/upgrade/platform.sh| 21 ++-
 target/linux/apm821xx/image/Makefile   |  2 +-
 10 files changed, 39 insertions(+), 82 deletions(-)
 delete mode 100755 target/linux/apm821xx/base-files/lib/apm821xx.sh
 delete mode 100644 
target/linux/apm821xx/base-files/lib/preinit/01_preinit_do_apm821xx.sh

diff --git a/target/linux/apm821xx/base-files/etc/board.d/01_leds 
b/target/linux/apm821xx/base-files/etc/board.d/01_leds
index 3b5fb721ae..c218efa49b 100755
--- a/target/linux/apm821xx/base-files/etc/board.d/01_leds
+++ b/target/linux/apm821xx/base-files/etc/board.d/01_leds
@@ -7,7 +7,7 @@ board_config_update
 board=$(board_name)
 
 case "$board" in
-mr24)
+meraki,mr24)
ucidef_set_led_netdev "wan" "WAN" "mr24:green:wan" "eth0"
ucidef_set_led_wlan "wlan1" "WLAN1" "mr24:green:wifi1" "phy0assoc"
ucidef_set_led_wlan "wlan2" "WLAN2" "mr24:green:wifi2" "phy0assoc"
@@ -15,7 +15,7 @@ mr24)
ucidef_set_led_wlan "wlan4" "WLAN4" "mr24:green:wifi4" "phy0tpt"
;;
 
-mx60)
+meraki,mx60)
ucidef_set_led_switch "wan" "WAN" "mx60:green:wan" "switch0" "0x20"
ucidef_set_led_switch "lan1" "LAN1" "mx60:green:lan1" "switch0" "0x10"
ucidef_set_led_switch "lan2" "LAN2" "mx60:green:lan2" "switch0" "0x08"
@@ -23,11 +23,12 @@ mx60)
ucidef_set_led_switch "lan4" "LAN4" "mx60:green:lan4" "switch0" "0x02"
;;
 
-mbl)
+wd,mybooklive|\
+wd,mybooklive-duo)
ucidef_set_led_ide "sata" "SATA" "mbl:blue:power"
;;
 
-wndr4700)
+netgear,wndr4700)
ucidef_set_led_ide "sata" "SATA" "wndr4700:green:hd"
ucidef_set_led_switch "wan_green" "WAN (green)" "wndr4700:green:wan" 
"switch0" "0x20"
ucidef_set_led_netdev "wan_yellow" "WAN (yellow)" "wndr4700:yellow:wan" 
"eth0.2" "tx rx"
diff --git a/target/linux/apm821xx/base-files/etc/board.d/02_network 
b/target/linux/apm821xx/base-files/etc/board.d/02_network
index 03df7cb49f..6f4456e8a1 100755
--- a/target/linux/apm821xx/base-files/etc/board.d/02_network
+++ b/target/linux/apm821xx/base-files/etc/board.d/02_network
@@ -8,13 +8,14 @@ board_config_update
 board=$(board_name)
 
 case "$board" in
-mbl|\
-mr24)
+meraki,mr24|\
+wd,mybooklive|\
+wd,mybooklive-duo)
ucidef_set_interface_lan "eth0"
;;
 
-mx60|\
-wndr4700)
+meraki,mx60|\
+netgear,wndr4700)
ucidef_add_switch "switch0" \
"0@eth0" "4:lan" "3:lan" "2:lan" "1:lan" "5:wan"
;;
diff --git 
a/target/linux/apm821xx/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom 
b/target/linux/apm821xx/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
index 4a7e1c0b19..7a13a0afa8 100644
--- a/target/linux/apm821xx/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
+++ b/target/linux/apm821xx/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
@@ -52,7 +52,7 @@ board=$(board_name)
 case "$FIRMWARE" in
 "pci_wmac0.eeprom")
case $board in
-   wndr4700)
+   netgear,wndr4700)
. /lib/upgrade/nand.sh
 
if [ -n "$(nand_find_volume ubi0 caldata)" ]; then
@@ -70,7 +70,7 @@ case "$FIRMWARE" in
 
 "pci_wmac1.eeprom")
case $board in
-   wndr4700)
+   netgear,wndr4700)
. /lib/upgrade/nand.sh
 
if [ -n "$(nand_find_volume ubi0 caldata)" ]; then
diff --git a/target/linux/apm821xx/base-files/lib/apm821xx.sh 
b/target/linux/apm

[LEDE-DEV] [PATCH 5/9] apm821xx: add product names to the dt compatible for Meraki

[Christian Lamparter]

Meraki choose to use their product's codename as the main
compatible string. Mathias Kresin commented that this is
a poor choice as this will confuse the users and devs once
the device-tree compatible is used for board-detection and
possible the image name.

Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
 target/linux/apm821xx/dts/MR24.dts | 2 +-
 target/linux/apm821xx/dts/MX60.dts | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/target/linux/apm821xx/dts/MR24.dts 
b/target/linux/apm821xx/dts/MR24.dts
index 8b58ce1991..2c2f8d281b 100644
--- a/target/linux/apm821xx/dts/MR24.dts
+++ b/target/linux/apm821xx/dts/MR24.dts
@@ -16,7 +16,7 @@
 
 / {
model = "Meraki MR24 Access Point";
-   compatible = "meraki,ikarem", "apm,bluestone";
+   compatible = "meraki,mr24", "meraki,ikarem", "apm,bluestone";
 
aliases {
serial0 = 
diff --git a/target/linux/apm821xx/dts/MX60.dts 
b/target/linux/apm821xx/dts/MX60.dts
index 64c8540d4d..32e5c859e8 100644
--- a/target/linux/apm821xx/dts/MX60.dts
+++ b/target/linux/apm821xx/dts/MX60.dts
@@ -16,7 +16,7 @@
 
 / {
model = "Meraki MX60/MX60W Security Appliance";
-   compatible = "meraki,buckminster", "apm,bluestone";
+   compatible = "meraki,mx60", "meraki,buckminster", "apm,bluestone";
 
aliases {
serial0 = 
-- 
2.15.1


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

[LEDE-DEV] [PATCH 3/9] apm821xx: replace DEVICE_{PROFILE|NAME} with BOARD_NAME

[Christian Lamparter]

This patch sets the BOARD_NAME variable on each affected
apm821xx device. The existing DEVICE_PROFILE and
DEVICE_NAME assignments are deprecated as they no longer
serve any purpose.

The BOARD_NAME variable is used by the sysupgrade-tar
method to specifiy a directory overwrite for the
sysupgrade-$dir directory in the generated tar file.
Keeping the original boardname in this context will be
necessary for targets that utilize the sysupgrade-tar
method. Otherwise, sysupgrade on an previous installation
will not recognize the newly generated images.

This step is necessary since an upcoming patch realigns
the existing shortname for a device with a proper
"manufacturer_device" identifier.

Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
 target/linux/apm821xx/image/Makefile | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/target/linux/apm821xx/image/Makefile 
b/target/linux/apm821xx/image/Makefile
index ebc6a051cc..217bff2c59 100644
--- a/target/linux/apm821xx/image/Makefile
+++ b/target/linux/apm821xx/image/Makefile
@@ -5,12 +5,11 @@
 include $(TOPDIR)/rules.mk
 include $(INCLUDE_DIR)/image.mk
 
-DEVICE_VARS += DEVICE_PROFILE IMAGE_SIZE DTB_SIZE
+DEVICE_VARS += IMAGE_SIZE DTB_SIZE
 
 define Device/Default
   PROFILES := Default
   KERNEL_DEPENDS = $$(wildcard ../dts/$$(DEVICE_DTS).dts)
-  DEVICE_PROFILE :=
   DEVICE_DTS :=
   KERNEL_ENTRY := 0x
   KERNEL_LOADADDR := 0x
@@ -61,7 +60,7 @@ endef
 
 define Build/MerakiNAND
-$(STAGING_DIR_HOST)/bin/mkmerakifw \
-   -B $(DEVICE_PROFILE) -s \
+   -B $(BOARD_NAME) -s \
-i $@ \
-o $@.new
@cp $@.new $@
@@ -70,7 +69,7 @@ endef
 define Device/mr24
   DEVICE_TITLE := Cisco Meraki MR24
   DEVICE_PACKAGES := kmod-spi-gpio
-  DEVICE_PROFILE := MR24
+  BOARD_NAME := mr24
   DEVICE_DTS := MR24
   BLOCKSIZE := 63k
   IMAGES := sysupgrade.tar
@@ -91,7 +90,7 @@ define Device/mx60
   DEVICE_TITLE := Cisco Meraki MX60/MX60W
   DEVICE_PACKAGES := kmod-spi-gpio kmod-usb-ledtrig-usbport kmod-usb-dwc2 \
   kmod-usb-storage block-mount
-  DEVICE_PROFILE := MX60
+  BOARD_NAME := mx60
   DEVICE_DTS := MX60
   BLOCKSIZE := 63k
   IMAGES := sysupgrade.tar
@@ -145,7 +144,7 @@ define Build/wndr4700-specialImage
 
-$(STAGING_DIR_HOST)/bin/mkimage -A $(LINUX_KARCH) -O linux -T multi \
-C $(1) -a $(KERNEL_LOADADDR) -e $(KERNEL_ENTRY) \
-   -n '$(DEVICE_PROFILE) initramfs' -d $@:$@.fakerd:$@.dtb $@.new
+   -n '$(BOARD_NAME) initramfs' -d $@:$@.fakerd:$@.dtb $@.new
mv $@.new $@
rm -rf $@.fakerd
 endef
@@ -157,8 +156,7 @@ define Device/WNDR4700
kmod-md-mod kmod-nls-cp437 kmod-nls-iso8859-1 kmod-nls-iso8859-15 \
kmod-nls-utf8 kmod-usb3 kmod-usb-dwc2 kmod-usb-storage \
partx-utils
-  DEVICE_NAME := wndr4700
-  DEVICE_PROFILE := wndr4700
+  BOARD_NAME := wndr4700
   DEVICE_DTS := wndr4700
   PAGESIZE := 2048
   SUBPAGESIZE := 512
@@ -228,7 +226,6 @@ define Device/MyBookLiveSingle
 $(Device/MyBookLiveDefault)
   DEVICE_TITLE := Western Digital My Book Live
   DEVICE_DTS := apollo3g
-  DEVICE_PROFILE := apollo3g
 endef
 
 TARGET_DEVICES += MyBookLiveSingle
@@ -238,7 +235,6 @@ $(Device/MyBookLiveDefault)
   DEVICE_TITLE := Western Digital My Book Live Duo
   DEVICE_PACKAGES := kmod-usb-dwc2 kmod-usb-ledtrig-usbport kmod-usb-storage 
kmod-fs-vfat wpad-mini
   DEVICE_DTS := apollo3g-duo
-  DEVICE_PROFILE := ap2nc
 endef
 
 TARGET_DEVICES += MyBookLiveDuo
-- 
2.15.1


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

[LEDE-DEV] [PATCH 4/9] apm821xx: dts: append SoC compatible to DTS

[Christian Lamparter]

This patch appends the "apm,bluestone" or "amcc,apollo3g"
machine compatible string to the current device tree source.

Please note that unlike other archs the PPC DT code does
not regard the machine's compatible string as a priority
list. This is explained in the kernel's usage-model.txt as follows:
"PowerPC uses a slightly different scheme where it calls the .probe()
hook from each machine_desc, and the first one returning TRUE is used.
However, this approach does not take into account the priority of the
compatible list, and probably should be avoided for new architecture
support."

For this reason, the "apm,bluestone" compatible string can't be
added to the WNDR4700. As otherwise the target specific pci
fix-up code will get ignored and this causes the ath9k WIFI
to not get initialized.

Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
 target/linux/apm821xx/dts/MR24.dts | 2 +-
 target/linux/apm821xx/dts/MX60.dts | 2 +-
 target/linux/apm821xx/dts/apollo3g-duo.dts | 1 +
 target/linux/apm821xx/dts/apollo3g.dts | 1 +
 4 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/target/linux/apm821xx/dts/MR24.dts 
b/target/linux/apm821xx/dts/MR24.dts
index 75bb32255c..8b58ce1991 100644
--- a/target/linux/apm821xx/dts/MR24.dts
+++ b/target/linux/apm821xx/dts/MR24.dts
@@ -16,7 +16,7 @@
 
 / {
model = "Meraki MR24 Access Point";
-   compatible = "meraki,ikarem";
+   compatible = "meraki,ikarem", "apm,bluestone";
 
aliases {
serial0 = 
diff --git a/target/linux/apm821xx/dts/MX60.dts 
b/target/linux/apm821xx/dts/MX60.dts
index 6c753639b2..64c8540d4d 100644
--- a/target/linux/apm821xx/dts/MX60.dts
+++ b/target/linux/apm821xx/dts/MX60.dts
@@ -16,7 +16,7 @@
 
 / {
model = "Meraki MX60/MX60W Security Appliance";
-   compatible = "meraki,buckminster";
+   compatible = "meraki,buckminster", "apm,bluestone";
 
aliases {
serial0 = 
diff --git a/target/linux/apm821xx/dts/apollo3g-duo.dts 
b/target/linux/apm821xx/dts/apollo3g-duo.dts
index 53459b0cc0..4f6cc506f5 100644
--- a/target/linux/apm821xx/dts/apollo3g-duo.dts
+++ b/target/linux/apm821xx/dts/apollo3g-duo.dts
@@ -14,6 +14,7 @@
 #include "apollo3g.dtsi"
 
 / {
+   compatible = "wd,mybooklive-duo", "amcc,apollo3g";
model = "MyBook Live Duo";
 };
 
diff --git a/target/linux/apm821xx/dts/apollo3g.dts 
b/target/linux/apm821xx/dts/apollo3g.dts
index 4d31edae4a..d841352292 100644
--- a/target/linux/apm821xx/dts/apollo3g.dts
+++ b/target/linux/apm821xx/dts/apollo3g.dts
@@ -12,5 +12,6 @@
 #include "apollo3g.dtsi"
 
 / {
+   compatible = "wd,mybooklive", "amcc,apollo3g";
model = "MyBook Live";
 };
-- 
2.15.1


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

[LEDE-DEV] [PATCH 7/9] apm821xx: align device names with vendor_device format

[Christian Lamparter]

Currently, the device name handle does not include the
manufacturer. This can make it hard do differentiate
between products from different vendors that have the
same product name. As the handle is used to derive
the image name.

Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
 target/linux/apm821xx/image/Makefile | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/target/linux/apm821xx/image/Makefile 
b/target/linux/apm821xx/image/Makefile
index 6efd3886d2..bff3947039 100644
--- a/target/linux/apm821xx/image/Makefile
+++ b/target/linux/apm821xx/image/Makefile
@@ -66,7 +66,7 @@ define Build/MerakiNAND
@cp $@.new $@
 endef
 
-define Device/mr24
+define Device/meraki_mr24
   DEVICE_TITLE := Cisco Meraki MR24
   DEVICE_PACKAGES := kmod-spi-gpio
   BOARD_NAME := mr24
@@ -84,9 +84,9 @@ define Device/mr24
   IMAGE/sysupgrade.tar := sysupgrade-tar
   UBINIZE_OPTS := -E 5
 endef
-TARGET_DEVICES += mr24
+TARGET_DEVICES += meraki_mr24
 
-define Device/mx60
+define Device/meraki_mx60
   DEVICE_TITLE := Cisco Meraki MX60/MX60W
   DEVICE_PACKAGES := kmod-spi-gpio kmod-usb-ledtrig-usbport kmod-usb-dwc2 \
   kmod-usb-storage block-mount
@@ -109,7 +109,7 @@ define Device/mx60
   IMAGE/sysupgrade.tar := sysupgrade-tar
   UBINIZE_OPTS := -E 5
 endef
-TARGET_DEVICES += mx60
+TARGET_DEVICES += meraki_mx60
 
 define Build/create-uImage-dtb
# flat_dt target expect FIT image - which WNDR4700's uboot doesn't 
support
@@ -149,7 +149,7 @@ define Build/wndr4700-specialImage
rm -rf $@.fakerd
 endef
 
-define Device/WNDR4700
+define Device/netgear_wndr4700
   DEVICE_TITLE := Netgear Centria N900 WNDR4700/WNDR4720
   DEVICE_PACKAGES := badblocks block-mount e2fsprogs \
kmod-dm kmod-fs-ext4 kmod-fs-vfat kmod-usb-ledtrig-usbport \
@@ -176,7 +176,7 @@ define Device/WNDR4700
   NETGEAR_HW_ID := 29763875+128+256
   UBINIZE_OPTS := -E 5
 endef
-TARGET_DEVICES += WNDR4700
+TARGET_DEVICES += netgear_wndr4700
 
 endif
 
@@ -222,22 +222,22 @@ define Device/MyBookLiveDefault
   IMAGE/rootfs.img.gz := boot-script | boot-img | hdd-img | gzip
 endef
 
-define Device/MyBookLiveSingle
+define Device/wd_mybooklive
 $(Device/MyBookLiveDefault)
   DEVICE_TITLE := Western Digital My Book Live
   DEVICE_DTS := wd-mybooklive
 endef
 
-TARGET_DEVICES += MyBookLiveSingle
+TARGET_DEVICES += wd_mybooklive
 
-define Device/MyBookLiveDuo
+define Device/wd_mybooklive_duo
 $(Device/MyBookLiveDefault)
   DEVICE_TITLE := Western Digital My Book Live Duo
   DEVICE_PACKAGES := kmod-usb-dwc2 kmod-usb-ledtrig-usbport kmod-usb-storage 
kmod-fs-vfat wpad-mini
   DEVICE_DTS := wd-mybooklive-duo
 endef
 
-TARGET_DEVICES += MyBookLiveDuo
+TARGET_DEVICES += wd_mybooklive_duo
 
 endif
 
-- 
2.15.1


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

[LEDE-DEV] [PATCH 2/9] apm821xx: replace whitespace with tabs

[Christian Lamparter]

Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
 target/linux/apm821xx/base-files/etc/diag.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/apm821xx/base-files/etc/diag.sh 
b/target/linux/apm821xx/base-files/etc/diag.sh
index e45f2a8522..26c035c6f3 100755
--- a/target/linux/apm821xx/base-files/etc/diag.sh
+++ b/target/linux/apm821xx/base-files/etc/diag.sh
@@ -32,7 +32,7 @@ set_state() {
status_led="$upgrade"
status_led_blink_preinit_regular
}
-;;
+   ;;
done)
status_led_off
[ -n "$running" ] && {
-- 
2.15.1


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

[LEDE-DEV] [PATCH 6/9] apm821xx: dts: rename devices dts files to include the manufacturer

[Christian Lamparter]

This patch rename all the DT source files in order to
match upstream's "manufacturer-device.dts" format.

Please note that the DEVICE_DTB isn't changed. This is
because the u-boot of the MyBook Live defines the
fdt_file variable to be "apollo3g/apollo3g.dtb".

Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
 target/linux/apm821xx/dts/{MR24.dts => meraki-mr24.dts}|  0
 target/linux/apm821xx/dts/{MX60.dts => meraki-mx60.dts}|  0
 .../linux/apm821xx/dts/{wndr4700.dts => netgear-wndr4700.dts}  |  0
 .../apm821xx/dts/{apollo3g-duo.dts => wd-mybooklive-duo.dts}   |  0
 target/linux/apm821xx/dts/{apollo3g.dts => wd-mybooklive.dts}  |  0
 target/linux/apm821xx/image/Makefile   | 10 +-
 6 files changed, 5 insertions(+), 5 deletions(-)
 rename target/linux/apm821xx/dts/{MR24.dts => meraki-mr24.dts} (100%)
 rename target/linux/apm821xx/dts/{MX60.dts => meraki-mx60.dts} (100%)
 rename target/linux/apm821xx/dts/{wndr4700.dts => netgear-wndr4700.dts} (100%)
 rename target/linux/apm821xx/dts/{apollo3g-duo.dts => wd-mybooklive-duo.dts} 
(100%)
 rename target/linux/apm821xx/dts/{apollo3g.dts => wd-mybooklive.dts} (100%)

diff --git a/target/linux/apm821xx/dts/MR24.dts 
b/target/linux/apm821xx/dts/meraki-mr24.dts
similarity index 100%
rename from target/linux/apm821xx/dts/MR24.dts
rename to target/linux/apm821xx/dts/meraki-mr24.dts
diff --git a/target/linux/apm821xx/dts/MX60.dts 
b/target/linux/apm821xx/dts/meraki-mx60.dts
similarity index 100%
rename from target/linux/apm821xx/dts/MX60.dts
rename to target/linux/apm821xx/dts/meraki-mx60.dts
diff --git a/target/linux/apm821xx/dts/wndr4700.dts 
b/target/linux/apm821xx/dts/netgear-wndr4700.dts
similarity index 100%
rename from target/linux/apm821xx/dts/wndr4700.dts
rename to target/linux/apm821xx/dts/netgear-wndr4700.dts
diff --git a/target/linux/apm821xx/dts/apollo3g-duo.dts 
b/target/linux/apm821xx/dts/wd-mybooklive-duo.dts
similarity index 100%
rename from target/linux/apm821xx/dts/apollo3g-duo.dts
rename to target/linux/apm821xx/dts/wd-mybooklive-duo.dts
diff --git a/target/linux/apm821xx/dts/apollo3g.dts 
b/target/linux/apm821xx/dts/wd-mybooklive.dts
similarity index 100%
rename from target/linux/apm821xx/dts/apollo3g.dts
rename to target/linux/apm821xx/dts/wd-mybooklive.dts
diff --git a/target/linux/apm821xx/image/Makefile 
b/target/linux/apm821xx/image/Makefile
index 217bff2c59..6efd3886d2 100644
--- a/target/linux/apm821xx/image/Makefile
+++ b/target/linux/apm821xx/image/Makefile
@@ -70,7 +70,7 @@ define Device/mr24
   DEVICE_TITLE := Cisco Meraki MR24
   DEVICE_PACKAGES := kmod-spi-gpio
   BOARD_NAME := mr24
-  DEVICE_DTS := MR24
+  DEVICE_DTS := meraki-mr24
   BLOCKSIZE := 63k
   IMAGES := sysupgrade.tar
   DTB_SIZE := 64512
@@ -91,7 +91,7 @@ define Device/mx60
   DEVICE_PACKAGES := kmod-spi-gpio kmod-usb-ledtrig-usbport kmod-usb-dwc2 \
   kmod-usb-storage block-mount
   BOARD_NAME := mx60
-  DEVICE_DTS := MX60
+  DEVICE_DTS := meraki-mx60
   BLOCKSIZE := 63k
   IMAGES := sysupgrade.tar
   DTB_SIZE := 64512
@@ -157,7 +157,7 @@ define Device/WNDR4700
kmod-nls-utf8 kmod-usb3 kmod-usb-dwc2 kmod-usb-storage \
partx-utils
   BOARD_NAME := wndr4700
-  DEVICE_DTS := wndr4700
+  DEVICE_DTS := netgear-wndr4700
   PAGESIZE := 2048
   SUBPAGESIZE := 512
   BLOCKSIZE := 128k
@@ -225,7 +225,7 @@ endef
 define Device/MyBookLiveSingle
 $(Device/MyBookLiveDefault)
   DEVICE_TITLE := Western Digital My Book Live
-  DEVICE_DTS := apollo3g
+  DEVICE_DTS := wd-mybooklive
 endef
 
 TARGET_DEVICES += MyBookLiveSingle
@@ -234,7 +234,7 @@ define Device/MyBookLiveDuo
 $(Device/MyBookLiveDefault)
   DEVICE_TITLE := Western Digital My Book Live Duo
   DEVICE_PACKAGES := kmod-usb-dwc2 kmod-usb-ledtrig-usbport kmod-usb-storage 
kmod-fs-vfat wpad-mini
-  DEVICE_DTS := apollo3g-duo
+  DEVICE_DTS := wd-mybooklive-duo
 endef
 
 TARGET_DEVICES += MyBookLiveDuo
-- 
2.15.1


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

[LEDE-DEV] [PATCH 1/9] apm821xx: explicitly build the rootfs.img.gz target

[Christian Lamparter]

The commit 87b668765e1
("image: when using the new image build code, gzip ext4 images by default")

forced that all targets that select the ext4 as the root filesystem
to always compress the generated rootfs. This is fine, but this method
doesn't not allow to append the metadata on a per-target base.

Therefore this patch changes the rootfs image production rule to generate
the gzip step manually. This way the metadata can be appended at a later
date.

Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
 target/linux/apm821xx/image/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/target/linux/apm821xx/image/Makefile 
b/target/linux/apm821xx/image/Makefile
index ee85292d57..ebc6a051cc 100644
--- a/target/linux/apm821xx/image/Makefile
+++ b/target/linux/apm821xx/image/Makefile
@@ -217,11 +217,11 @@ define Device/MyBookLiveDefault
   KERNEL := kernel-bin | dtb | gzip | uImage gzip
   KERNEL_INITRAMFS := kernel-bin | dtb | gzip | uImage gzip
   BOOT_SIZE := 8
-  IMAGES := rootfs.img kernel.dtb
+  IMAGES := rootfs.img.gz kernel.dtb
   DEVICE_DTB := apollo3g.dtb
   FILESYSTEMS := ext4
   IMAGE/kernel.dtb := export-dtb
-  IMAGE/rootfs.img := boot-script | boot-img | hdd-img
+  IMAGE/rootfs.img.gz := boot-script | boot-img | hdd-img | gzip
 endef
 
 define Device/MyBookLiveSingle
-- 
2.15.1


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

Re: [LEDE-DEV] [RESEND][PATCH] ar71xx: fix invalid pointer dereference in c60_nand_scan_fixup()

[Christian Lamparter]

On Wednesday, December 13, 2017 8:31:50 PM CET Gabor Juhos wrote:
> Since Linux 4.6, mtd->priv no longer points to the NAND specific
> structure. Under 4.9 it contains NULL, thus using it to access
> the fields of the nand_chip structure causes an invalid pointer
> dereference.
> 
> Update the code to use the mtd_to_nand() helper under 4.9 to obtain
> the address of the chip specific data.
> 
> Compile tested only.
> 
> Fixes: 7bbf4117c6fe ("ar71xx: Add kernel 4.9 support")
> Signed-off-by: Gabor Juhos <juh...@freemail.hu>
Tested-by: Christian Lamparter <chunk...@gmail.com>

Yep, it boots on my unit.

Kernel is: Linux c-60 4.9.67 
"OpenWrt SNAPSHOT, r5518+1-bfa42ef8f5"


Thanks

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

[LEDE-DEV] [PATCH v2] apm821xx: use x86's upgrade scripts for MyBook Live

[Christian Lamparter]

Advantages:
 - preserves existing partition layout. On the hard-drive.
   Only the boot and rootfs partition will be overwritten.

Disadvantages:
 - The upgrade process takes much longer to run.
   from 2-3 seconds to 15-25 seconds.

Please note that sysupgrade will refuse to upgrade, if the existing
installation has an incompatible partition layout. Future changes
to the bootfs and/or rootfs partition size will likely cause breakage
to the sysupgrade procedure. In these cases, the ext4-rootfs.img.gz
has to be written manually onto the disk. Please don't forget to backup
your configuration in this cases.

Note2: This patch requires
"base-files: upgrade: make get_partitions() endian agnostic"

Note3: If your current installation does not host the two
changes, sysupgrading will wipe the existing partition
layout. Don't forget to backup your data!

Signed-off-by: Christian Lamparter <chunk...@gmail.com>

---

v2:
   - delete dead get_magic_at function
   - fixed mbl_do_platform_check() complaining about
 "Invalid partition table on image"
---
 .../apm821xx/base-files/lib/upgrade/platform.sh|  2 +-
 .../apm821xx/base-files/lib/upgrade/wdbook.sh  | 99 ++
 2 files changed, 82 insertions(+), 19 deletions(-)

diff --git a/target/linux/apm821xx/base-files/lib/upgrade/platform.sh 
b/target/linux/apm821xx/base-files/lib/upgrade/platform.sh
index 55f8ffa75d..8c716bf44e 100755
--- a/target/linux/apm821xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/apm821xx/base-files/lib/upgrade/platform.sh
@@ -9,7 +9,7 @@ platform_check_image() {
 
case "$board" in
mbl)
-   mbl_do_platform_check $board "$1"
+   mbl_do_platform_check "$1"
return $?;
;;
 
diff --git a/target/linux/apm821xx/base-files/lib/upgrade/wdbook.sh 
b/target/linux/apm821xx/base-files/lib/upgrade/wdbook.sh
index d7347516cb..2287e0619d 100644
--- a/target/linux/apm821xx/base-files/lib/upgrade/wdbook.sh
+++ b/target/linux/apm821xx/base-files/lib/upgrade/wdbook.sh
@@ -1,36 +1,99 @@
 . /lib/functions.sh
 
-get_magic_at() {
-   local file="$1"
-   local pos="$2"
-   get_image "$file" | dd bs=1 count=2 skip="$pos" 2>/dev/null | hexdump 
-v -n 2 -e '1/1 "%02x"'
-}
+# copied from x86's platform.sh
 
 mbl_do_platform_check() {
-   local board="$1"
-   local file="$2"
-   local magic
+   local diskdev partdev diff
 
-   magic=$(get_magic_at "$file" 510)
+   [ "$#" -gt 1 ] && return 1
 
-   [ "$magic" != "55aa" ] && {
-   echo "Failed to verify MBR boot signature."
+   export_bootdevice && export_partdevice diskdev -2 || {
+   echo "Unable to determine upgrade device"
return 1
}
 
+   get_partitions "/dev/$diskdev" bootdisk
+
+   #extract the boot sector from the image
+   get_image "$@" | dd of=/tmp/image.bs count=1 bs=512b 2>/dev/null
+
+   get_partitions /tmp/image.bs image
+
+   #compare tables
+   diff="$(grep -F -x -v -f /tmp/partmap.bootdisk /tmp/partmap.image)"
+
+   rm -f /tmp/image.bs /tmp/partmap.bootdisk /tmp/partmap.image
+
+   if [ -n "$diff" ]; then
+   echo "Partition layout has changed. Full image will be written."
+   ask_bool 0 "Abort" && exit 1
+   return 0
+   fi
+
return 0;
 }
 
 mbl_do_upgrade() {
+   local diskdev partdev diff
+
+   export_bootdevice && export_partdevice diskdev -2 || {
+   echo "Unable to determine upgrade device"
+   return 1
+   }
+
sync
-   get_image "$1" | dd of=/dev/sda bs=2M conv=fsync
-   sleep 1
+
+   if [ "$SAVE_PARTITIONS" = "1" ]; then
+   get_partitions "/dev/$diskdev" bootdisk
+
+   #extract the boot sector from the image
+   get_image "$@" | dd of=/tmp/image.bs count=1 bs=512b
+
+   get_partitions /tmp/image.bs image
+
+   #compare tables
+   diff="$(grep -F -x -v -f /tmp/partmap.bootdisk 
/tmp/partmap.image)"
+   else
+   diff=1
+   fi
+
+   if [ -n "$diff" ]; then
+   get_image "$@" | dd of="/dev/$diskdev" bs=4096 conv=fsync
+
+   # Separate removal and addtion is necessary; otherwise, 
partition 1
+   # will be missing if it overlaps with the old partition 2
+   partx -d - "/dev/$diskdev"
+   partx -a - "/dev/$diskdev"
+
+   return 0
+   fi
+
+   #iterate over each partition from the image and writ

Re: [LEDE-DEV] [PATCH 1/5] build: append metadata for supported images.gz

[Christian Lamparter]

On Tuesday, November 28, 2017 11:20:23 PM CET Christian Lamparter wrote:
> On Tuesday, November 28, 2017 11:07:54 PM CET Matthias Schiffer wrote:
> > On 11/28/2017 10:51 PM, Christian Lamparter wrote:
> > > Targets that either directly or indirectly set
> > > CONFIG_TARGET_IMAGES_GZIP currently have no way
> > > to append the metadata at the end of new image
> > > creation process. And this is going to be
> > > necessary in order to convert the targets to use
> > > the new fwtool assisted platform check.
> > > 
> > > These will include for example x86(_64), RPI, and
> > > MyBook Live images.
> > > 
> > > Note: append-metadata does internally check if
> > > SUPPORTED_DEVICES is set, before adding the
> > > metadata. Hence, it will not interfere with
> > > existing targets that have not been converted.
> > > 
> > > Cc: Felix Fietkau <n...@nbd.name>
> > > Signed-off-by: Christian Lamparter <chunk...@gmail.com>
> > > ---
> > 
> > It should not matter if the images are gzipped or not; the metadata should
> > be appended before gzipping. All image checks are done after zcat; if this
> > is not the case for the fwtool checks, IMO the checks need to be adjusted,
> > not the image generation.
> 
> Hm, why is then the raw metadata appended to the sysupgrade.tar files
> in the first place? Shouldn't it be a inside a file in the .tar as well?
> Or what's your solution supposed to look like otherwise? Add gzip handling
> to the fwtool?
> 
Mathias Kresin had a great idea and it solved the problem in a better way.
This patch is therefore obsolete. \o/

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

Re: [LEDE-DEV] [PATCH 1/5] build: append metadata for supported images.gz

[Christian Lamparter]

On Tuesday, November 28, 2017 11:07:54 PM CET Matthias Schiffer wrote:
> On 11/28/2017 10:51 PM, Christian Lamparter wrote:
> > Targets that either directly or indirectly set
> > CONFIG_TARGET_IMAGES_GZIP currently have no way
> > to append the metadata at the end of new image
> > creation process. And this is going to be
> > necessary in order to convert the targets to use
> > the new fwtool assisted platform check.
> > 
> > These will include for example x86(_64), RPI, and
> > MyBook Live images.
> > 
> > Note: append-metadata does internally check if
> > SUPPORTED_DEVICES is set, before adding the
> > metadata. Hence, it will not interfere with
> > existing targets that have not been converted.
> > 
> > Cc: Felix Fietkau <n...@nbd.name>
> > Signed-off-by: Christian Lamparter <chunk...@gmail.com>
> > ---
> 
> It should not matter if the images are gzipped or not; the metadata should
> be appended before gzipping. All image checks are done after zcat; if this
> is not the case for the fwtool checks, IMO the checks need to be adjusted,
> not the image generation.

Hm, why is then the raw metadata appended to the sysupgrade.tar files
in the first place? Shouldn't it be a inside a file in the .tar as well?
Or what's your solution supposed to look like otherwise? Add gzip handling
to the fwtool?

Christian
 
> >  include/image.mk | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/include/image.mk b/include/image.mk
> > index f4d0a157cd..a7342c9d53 100644
> > --- a/include/image.mk
> > +++ b/include/image.mk
> > @@ -494,6 +494,7 @@ define Device/Build/image
> >  
> >$(BIN_DIR)/$(call IMAGE_NAME,$(1),$(2)).gz: $(KDIR)/tmp/$(call 
> > IMAGE_NAME,$(1),$(2))
> > gzip -c -9n $$^ > $$@
> > +   $$(call Build/append-metadata)
> >  
> >$(BIN_DIR)/$(call IMAGE_NAME,$(1),$(2)): $(KDIR)/tmp/$(call 
> > IMAGE_NAME,$(1),$(2))
> > cp $$^ $$@
> > 
> 
> 
> 



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

[LEDE-DEV] [PATCH 2/5] base-files: unify get_dt_led helper function

[Christian Lamparter]

Lantiq and IPQ806X (which includes IPQ40XX) both define the
same custom function {ipq806x|lantiq}_get_dt_led.

This patch moves the function into the base-file package at
lib/functions/leds.sh to make it more accessible for other
targets as well.

Cc: Mathias Kresin <d...@kresin.me>
Cc: John Crispin <j...@phrozen.org>
Cc: Hannu Nyman <hannu.ny...@iki.fi>
Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
 package/base-files/files/lib/functions/leds.sh | 12 
 target/linux/ipq806x/base-files/etc/diag.sh|  9 -
 target/linux/ipq806x/base-files/lib/ipq806x.sh | 12 
 target/linux/lantiq/base-files/etc/board.d/01_leds | 12 ++--
 target/linux/lantiq/base-files/etc/diag.sh |  9 -
 target/linux/lantiq/base-files/lib/functions/lantiq.sh | 12 
 6 files changed, 26 insertions(+), 40 deletions(-)

diff --git a/package/base-files/files/lib/functions/leds.sh 
b/package/base-files/files/lib/functions/leds.sh
index 857e7e5392..83e775fada 100644
--- a/package/base-files/files/lib/functions/leds.sh
+++ b/package/base-files/files/lib/functions/leds.sh
@@ -1,6 +1,18 @@
 #!/bin/sh
 # Copyright (C) 2013 OpenWrt.org
 
+get_dt_led() {
+   local label
+   local ledpath
+   local basepath="/proc/device-tree"
+   local nodepath="$basepath/aliases/led-$1"
+
+   [ -f "$nodepath" ] && ledpath=$(cat "$nodepath")
+   [ -n "$ledpath" ] && label=$(cat "$basepath$ledpath/label")
+
+   echo "$label"
+}
+
 led_set_attr() {
[ -f "/sys/class/leds/$1/$2" ] && echo "$3" > "/sys/class/leds/$1/$2"
 }
diff --git a/target/linux/ipq806x/base-files/etc/diag.sh 
b/target/linux/ipq806x/base-files/etc/diag.sh
index 7c9a9d082c..df4afd936c 100755
--- a/target/linux/ipq806x/base-files/etc/diag.sh
+++ b/target/linux/ipq806x/base-files/etc/diag.sh
@@ -2,12 +2,11 @@
 # Copyright (C) 2016 Henryk Heisig hy...@o2.pl
 
 . /lib/functions/leds.sh
-. /lib/ipq806x.sh
 
-boot="$(ipq806x_get_dt_led boot)"
-failsafe="$(ipq806x_get_dt_led failsafe)"
-running="$(ipq806x_get_dt_led running)"
-upgrade="$(ipq806x_get_dt_led upgrade)"
+boot="$(get_dt_led boot)"
+failsafe="$(get_dt_led failsafe)"
+running="$(get_dt_led running)"
+upgrade="$(get_dt_led upgrade)"
 
 set_state() {
status_led="$boot"
diff --git a/target/linux/ipq806x/base-files/lib/ipq806x.sh 
b/target/linux/ipq806x/base-files/lib/ipq806x.sh
index 940c7ef204..c4d2c8f258 100644
--- a/target/linux/ipq806x/base-files/lib/ipq806x.sh
+++ b/target/linux/ipq806x/base-files/lib/ipq806x.sh
@@ -62,15 +62,3 @@ ipq806x_board_detect() {
echo "$IPQ806X_BOARD_NAME" > /tmp/sysinfo/board_name
echo "$IPQ806X_MODEL" > /tmp/sysinfo/model
 }
-
-ipq806x_get_dt_led() {
-   local label
-   local ledpath
-   local basepath="/proc/device-tree"
-   local nodepath="$basepath/aliases/led-$1"
-
-   [ -f "$nodepath" ] && ledpath=$(cat "$nodepath")
-   [ -n "$ledpath" ] && label=$(cat "$basepath$ledpath/label")
-
-   echo "$label"
-}
diff --git a/target/linux/lantiq/base-files/etc/board.d/01_leds 
b/target/linux/lantiq/base-files/etc/board.d/01_leds
index 2c7a402dfb..187ae68a13 100755
--- a/target/linux/lantiq/base-files/etc/board.d/01_leds
+++ b/target/linux/lantiq/base-files/etc/board.d/01_leds
@@ -4,23 +4,23 @@
 # based on ar71xx
 #
 
+. /lib/functions/leds.sh
 . /lib/functions/uci-defaults.sh
-. /lib/functions/lantiq.sh
 
 board_config_update
 
-led_wifi="$(lantiq_get_dt_led wifi)"
+led_wifi="$(get_dt_led wifi)"
 [ -n "$led_wifi" ] && ucidef_set_led_wlan "wifi" "wifi" "$led_wifi" "phy0tpt"
 
-led_usb="$(lantiq_get_dt_led usb)"
+led_usb="$(get_dt_led usb)"
 [ -n "$led_usb" ] && ucidef_set_led_usbdev "usb" "usb" "$led_usb" "1-1"
 
-led_usb2="$(lantiq_get_dt_led usb2)"
+led_usb2="$(get_dt_led usb2)"
 [ -n "$led_usb2" ] && ucidef_set_led_usbdev "usb2" "usb2" "$led_usb2" "2-1"
 
-led_dsl="$(lantiq_get_dt_led dsl)"
+led_dsl="$(get_dt_led dsl)"
 [ -n "$led_dsl" ] && {
-   led_internet="$(lantiq_get_dt_led internet)"
+   led_internet="$(get_dt_led internet)"
if [ -n "$led_internet" ]; then
ucidef_set_led_default "dsl" "dsl" "$led_dsl" "0"
ucidef_set_led_netdev "internet" "internet" "$led_internet&q

[LEDE-DEV] [PATCH 3/5] apm821xx: convert to dt based diag LED script

[Christian Lamparter]

Please note that users with a Netgear WNDR4700
will need to update the device-tree partition
manually.

For instructions, please refere to commit 49856a4bb581
("apm821xx: make it possible to update the dtb partition on the WNDR4700")

Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
 target/linux/apm821xx/base-files/etc/diag.sh | 48 +++-
 target/linux/apm821xx/dts/MR24.dts   |  8 +++--
 target/linux/apm821xx/dts/MX60.dts   |  8 +++--
 target/linux/apm821xx/dts/apollo3g.dtsi  |  8 +++--
 target/linux/apm821xx/dts/wndr4700.dts   |  8 +++--
 5 files changed, 49 insertions(+), 31 deletions(-)

diff --git a/target/linux/apm821xx/base-files/etc/diag.sh 
b/target/linux/apm821xx/base-files/etc/diag.sh
index eb9b04b525..e45f2a8522 100755
--- a/target/linux/apm821xx/base-files/etc/diag.sh
+++ b/target/linux/apm821xx/base-files/etc/diag.sh
@@ -3,40 +3,42 @@
 . /lib/functions.sh
 . /lib/functions/leds.sh
 
-get_status_led() {
-   local board=$(board_name)
-
-   case $board in
-   mbl|\
-   mr24|\
-   mx60|\
-   wndr4700)
-   status_led="$board:green:power"
-   ;;
-
-   *)
-   ;;
-   esac
-}
+boot="$(get_dt_led boot)"
+failsafe="$(get_dt_led failsafe)"
+running="$(get_dt_led running)"
+upgrade="$(get_dt_led upgrade)"
 
 set_state() {
-   get_status_led
+   status_led="$boot"
 
case "$1" in
+   preinit_regular)
+   status_led_blink_preinit_regular
+   ;;
preinit)
status_led_blink_preinit
;;
-
failsafe)
+   status_led_off
+   [ -n "$running" ] && {
+   status_led="$running"
+   status_led_off
+   }
+   status_led="$failsafe"
status_led_blink_failsafe
;;
-
-   preinit_regular)
-   status_led_blink_preinit_regular
-   ;;
-
+   upgrade)
+   [ -n "$running" ] && {
+   status_led="$upgrade"
+   status_led_blink_preinit_regular
+   }
+;;
done)
-   status_led_on
+   status_led_off
+   [ -n "$running" ] && {
+   status_led="$running"
+   status_led_on
+   }
;;
esac
 }
diff --git a/target/linux/apm821xx/dts/MR24.dts 
b/target/linux/apm821xx/dts/MR24.dts
index 8d20872c3f..75bb32255c 100644
--- a/target/linux/apm821xx/dts/MR24.dts
+++ b/target/linux/apm821xx/dts/MR24.dts
@@ -20,6 +20,10 @@
 
aliases {
serial0 = 
+   led-boot = 
+   led-failsafe = 
+   led-running = 
+   led-upgrade = 
};
 
chosen {
@@ -91,12 +95,12 @@
gpio-leds {
compatible = "gpio-leds";
 
-   power-green {
+   status: power-green {
label = "mr24:green:power";
gpios = < 18 GPIO_ACTIVE_LOW>;
};
 
-   power-orange {
+   failsafe: power-orange {
label = "mr24:orange:power";
gpios = < 19 GPIO_ACTIVE_LOW>;
};
diff --git a/target/linux/apm821xx/dts/MX60.dts 
b/target/linux/apm821xx/dts/MX60.dts
index 4ec0043f32..6c753639b2 100644
--- a/target/linux/apm821xx/dts/MX60.dts
+++ b/target/linux/apm821xx/dts/MX60.dts
@@ -20,6 +20,10 @@
 
aliases {
serial0 = 
+   led-boot = 
+   led-failsafe = 
+   led-running = 
+   led-upgrade = 
};
 
chosen {
@@ -120,12 +124,12 @@
gpio-leds {
compatible = "gpio-leds";
 
-   power-green {
+   status: power-green {
label = "mx60:green:power";
gpios = < 18 GPIO_ACTIVE_LOW>;
};
 
-   power-orange {
+   failsafe: power-orange {
label = "mx60:orange:power";
gpios = < 19 GPIO_ACTIVE_LOW>;
};
diff --git a/target/linux/apm821xx/dts/apollo3g.dtsi 
b/target/linux/apm821xx/dts/apollo3g.dtsi
index 783348a678..09a8b8518c 100644
--- a/target/linux/apm821xx/dts/apollo3g.dtsi
+++ b/target/linux/apm821xx/dts/apollo3g.dtsi
@@ -14,6 +14,10 @@
 
aliases {
serial0 = 
+   led-boot = 
+   led-failsafe = 
+   led-running = 
+   led-upgrade = 
};
 };
 
@@ -113,13 +117,13 @@
gpio-leds {

[LEDE-DEV] [PATCH 5/5] apm821xx: MyBook Live convert to DT PHY

[Christian Lamparter]

Changes MyBook Live to use DT PHY probing and the broadcom phy driver.

Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
 target/linux/apm821xx/dts/apollo3g.dtsi   | 11 +++
 target/linux/apm821xx/sata/config-default |  1 +
 2 files changed, 12 insertions(+)

diff --git a/target/linux/apm821xx/dts/apollo3g.dtsi 
b/target/linux/apm821xx/dts/apollo3g.dtsi
index 09a8b8518c..e88973f8d2 100644
--- a/target/linux/apm821xx/dts/apollo3g.dtsi
+++ b/target/linux/apm821xx/dts/apollo3g.dtsi
@@ -171,6 +171,17 @@
 
  {
status = "okay";
+
+   phy-map = <0x2>;
+   phy-address = <0x1>;
+   phy-handle = <>;
+
+   mdio {
+   phy: phy@1 {
+   compatible = "ethernet-phy-ieee802.3-c22";
+   reg = <1>;
+   };
+   };
 };
 
  {
diff --git a/target/linux/apm821xx/sata/config-default 
b/target/linux/apm821xx/sata/config-default
index b8342de049..7ca6bd4d3d 100644
--- a/target/linux/apm821xx/sata/config-default
+++ b/target/linux/apm821xx/sata/config-default
@@ -1,5 +1,6 @@
 # CONFIG_IKAREM is not set
 CONFIG_APOLLO3G=y
+CONFIG_BROADCOM_PHY=y
 CONFIG_EXT4_FS=y
 CONFIG_DMADEVICES=y
 CONFIG_DMA_ENGINE=y
-- 
2.15.0


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

[LEDE-DEV] [PATCH 4/5] apm821xx: use x86's upgrade scripts for MyBook Live

[Christian Lamparter]

Advantages:
 - preserves existing partition layout. On the hard-drive.
   Only the boot and rootfs partition will be overwritten.

Disadvantages:
 - The upgrade process takes much longer to run.
   from 2-3 seconds to 15-25 seconds.

Please note that sysupgrade will refuse to upgrade, if the existing
installation  has an incompatible partition layout. Future changes
to the bootfs and/or rootfs partition size will likely cause breakage
to the sysupgrade procedure. In these cases, the ext4-rootfs.img.gz
install procedure will have to be used. Please don't forget to backup
your configuration in this case.

Note2: This patch requires
"base-files: upgrade: make get_partitions() endian agnostic"

Note3: If your current installation does not host the two
changes, sysupgradeing will then wipe the existing partition
layout. Don't forget to backup your data!

Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
 .../apm821xx/base-files/lib/upgrade/platform.sh|  2 +-
 .../apm821xx/base-files/lib/upgrade/wdbook.sh  | 95 +++---
 2 files changed, 83 insertions(+), 14 deletions(-)

diff --git a/target/linux/apm821xx/base-files/lib/upgrade/platform.sh 
b/target/linux/apm821xx/base-files/lib/upgrade/platform.sh
index 55f8ffa75d..8c716bf44e 100755
--- a/target/linux/apm821xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/apm821xx/base-files/lib/upgrade/platform.sh
@@ -9,7 +9,7 @@ platform_check_image() {
 
case "$board" in
mbl)
-   mbl_do_platform_check $board "$1"
+   mbl_do_platform_check "$1"
return $?;
;;
 
diff --git a/target/linux/apm821xx/base-files/lib/upgrade/wdbook.sh 
b/target/linux/apm821xx/base-files/lib/upgrade/wdbook.sh
index d7347516cb..b84f80f326 100644
--- a/target/linux/apm821xx/base-files/lib/upgrade/wdbook.sh
+++ b/target/linux/apm821xx/base-files/lib/upgrade/wdbook.sh
@@ -1,5 +1,7 @@
 . /lib/functions.sh
 
+# copied from x86's platform.sh
+
 get_magic_at() {
local file="$1"
local pos="$2"
@@ -7,30 +9,97 @@ get_magic_at() {
 }
 
 mbl_do_platform_check() {
-   local board="$1"
-   local file="$2"
-   local magic
+   local diskdev partdev diff
 
-   magic=$(get_magic_at "$file" 510)
+   [ "$#" -gt 1 ] && return 1
 
-   [ "$magic" != "55aa" ] && {
-   echo "Failed to verify MBR boot signature."
+   export_bootdevice && export_partdevice diskdev -2 || {
+   echo "Unable to determine upgrade device"
return 1
}
 
+   get_partitions "/dev/$diskdev" bootdisk
+
+   #extract the boot sector from the image
+   get_image "$file" | dd of=/tmp/image.bs count=1 bs=512b 2>/dev/null
+
+   get_partitions /tmp/image.bs image
+
+   #compare tables
+   diff="$(grep -F -x -v -f /tmp/partmap.bootdisk /tmp/partmap.image)"
+
+   rm -f /tmp/image.bs /tmp/partmap.bootdisk /tmp/partmap.image
+
+   if [ -n "$diff" ]; then
+   echo "Partition layout has changed. Full image will be written."
+   ask_bool 0 "Abort" && exit 1
+   return 0
+   fi
+
return 0;
 }
 
 mbl_do_upgrade() {
+   local diskdev partdev diff
+
+   export_bootdevice && export_partdevice diskdev -2 || {
+   echo "Unable to determine upgrade device"
+   return 1
+   }
+
sync
-   get_image "$1" | dd of=/dev/sda bs=2M conv=fsync
-   sleep 1
+
+   if [ "$SAVE_PARTITIONS" = "1" ]; then
+   get_partitions "/dev/$diskdev" bootdisk
+
+   #extract the boot sector from the image
+   get_image "$@" | dd of=/tmp/image.bs count=1 bs=512b
+
+   get_partitions /tmp/image.bs image
+
+   #compare tables
+   diff="$(grep -F -x -v -f /tmp/partmap.bootdisk 
/tmp/partmap.image)"
+   else
+   diff=1
+   fi
+
+   if [ -n "$diff" ]; then
+   get_image "$@" | dd of="/dev/$diskdev" bs=4096 conv=fsync
+
+   # Separate removal and addtion is necessary; otherwise, 
partition 1
+   # will be missing if it overlaps with the old partition 2
+   partx -d - "/dev/$diskdev"
+   partx -a - "/dev/$diskdev"
+
+   return 0
+   fi
+
+   #iterate over each partition from the image and write it to the boot 
disk
+   while read part start size; do
+   # root is /dev/sd[a|b]2 and not /dev/sd[a|b] this causes some 
problem
+   # one of which is this offset, I'm not sure what's the best 
fix, so
+   # 

[LEDE-DEV] [PATCH 1/5] build: append metadata for supported images.gz

[Christian Lamparter]

Targets that either directly or indirectly set
CONFIG_TARGET_IMAGES_GZIP currently have no way
to append the metadata at the end of new image
creation process. And this is going to be
necessary in order to convert the targets to use
the new fwtool assisted platform check.

These will include for example x86(_64), RPI, and
MyBook Live images.

Note: append-metadata does internally check if
SUPPORTED_DEVICES is set, before adding the
metadata. Hence, it will not interfere with
existing targets that have not been converted.

Cc: Felix Fietkau <n...@nbd.name>
Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
 include/image.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/image.mk b/include/image.mk
index f4d0a157cd..a7342c9d53 100644
--- a/include/image.mk
+++ b/include/image.mk
@@ -494,6 +494,7 @@ define Device/Build/image
 
   $(BIN_DIR)/$(call IMAGE_NAME,$(1),$(2)).gz: $(KDIR)/tmp/$(call 
IMAGE_NAME,$(1),$(2))
gzip -c -9n $$^ > $$@
+   $$(call Build/append-metadata)
 
   $(BIN_DIR)/$(call IMAGE_NAME,$(1),$(2)): $(KDIR)/tmp/$(call 
IMAGE_NAME,$(1),$(2))
cp $$^ $$@
-- 
2.15.0


___
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.64

[Christian Lamparter]

On Thursday, November 23, 2017 4:14:42 PM CET Koen Vandeputte wrote:
> Refreshed all patches
> 
> Compile-tested: cns3xxx, imx6
> Runtime-tested: cns3xxx, imx6

runs on the MyBook Live (apm821xx) w/o a hitch.

Tested-by: Christian Lamparter <chunk...@gmail.com>

> Signed-off-by: Koen Vandeputte <koen.vandepu...@ncentric.com>
> ---


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

Re: [LEDE-DEV] [PATCH 4/4] toolchain: musl: update to current HEAD

[Christian Lamparter]

On Wednesday, November 22, 2017 9:55:39 AM CET Koen Vandeputte wrote:
> >> Yes,
> >>
> >> Main reason in that specific case was mainly for these 2 fixes:
> >>
> >> /9e01be6 fix signal masking race in pthread_create with priority (I use
> >> lots of threading & thread priority in my app) //51bdcdc fix OOB reads in 
> >> Xbyte_memmem (used by memmem() ) /
> >>
> > Hm? Are you now talking about something else? I remember seeing these
> > commits listed in your musl update to 1.1.16+.
> > <http://lists.infradead.org/pipermail/lede-dev/2017-October/009234.html>
> >
> > But Felix did the update musl to 1.1.18 on the 5th (I noticed that he had
> > a patch queued). This update included the changes you listed, right?
> >
> I was indeed referring to that one, as a mere example where I proposed 
> to bump to head, just like you propose now. (got superseded)
> http://patchwork.ozlabs.org/patch/823135/
Ah ok, I misread this at first and got confused. Thank you for taking the
time to explain what was going on here.

In any case it seems like the commits entered Felix's staging tree.
<https://git.lede-project.org/?p=lede/nbd/staging.git>

> > Maybe a balanced solution would be to wait for 1 .. 2  tested-by's
> > before pushing these to master?
> > Great that you bring this up. So, did you test >this patch< already too?
> > And if so, what's your verdict? Does it perform as expected on your cns3xxx?
> > Can you please post a "tested-by" tag then?
> I've added it to my daily build yesterday, and it's running on my stress 
> setup currently. (9 boards: 6x cns3xxx & 3x imx6, all meshed up)
> If all goes well, I'm more that happy to drop a tested-by within the 
> next few hours (like I sometimes do for other people's patches too)
Yes, I saw Kevin and your mail too. Thank you both! :)

> Feel free to do the same for mine ;)
Yes, of course. Please do include me in the "CC:", this way it will
hit my inbox, instead of being delivered to just the Mailinglist folder.

The linux kernel ships with a rather useful perl script called:
get_maintainer.pl. (Yes, it can be a blessing but it can also be a curse)

Long ago, this script required a project maintain a special MAINTAINERS file.
However nowadays, the tool has the ability to extract this information from 
git by looking at the previous commits (Emails from Signed-off-by: Reviewed-by:
and Acked-by: tags). And for the most part, this is compatible with LEDE's 
patch guidelines. <https://lede-project.org/submitting-patches>

For example, for this patch it will generate the following output:

$ get_maintainer.pl 0004-toolchain-musl-update-to-current-HEAD.patch 
Felix Fietkau <n...@nbd.name> 
(authored:3/7=43%,added_lines:5/17=29%,removed_lines:5/14=36%,authored:1/2=50%,added_lines:3/54=6%,removed_lines:3/22=14%)
Christian Lamparter <chunk...@gmail.com> 
(authored:2/7=29%,added_lines:8/17=47%,removed_lines:5/14=36%,authored:1/2=50%,added_lines:51/54=94%,removed_lines:19/22=86%)
Koen Vandeputte <koen.vandepu...@ncentric.com> 
(authored:2/7=29%,added_lines:4/17=24%,removed_lines:4/14=29%)

So, this tool has picked you as a reviewer! ;)

If you (or anyone else) want to check it out, I've uploaded this slightly
modified version github gist [removed "linux kernel" references in help texts
and changed top_of_kernel_tree() func to work for the LEDE's root directory.]
<https://gist.github.com/chunkeey/59c4b814243e384c05d89cdef2ced916>
(To download, press "Raw" button)

Is there any interest for this?

Regards,
Christian

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

Re: [LEDE-DEV] [PATCH 4/4] toolchain: musl: update to current HEAD

[Christian Lamparter]

On Tuesday, November 21, 2017 9:56:12 AM CET Koen Vandeputte wrote:
> > This is all documented on the musl ML.
> >
> > musl 1.1.17 was rushed due to this CVE:
> > 
> >
> > However, the 1.1.17 release had accumulated like 11 months of patches since
> > the previous 1.1.16 release. There have been several regressions that went
> > unnoticed. But this only really came to light after 1.1.17 was already
> > released. Because the different projects and people actually started to test
> > it now.
> >
> > In fact, Syrone Wong actually discovered the regression earlier.
> > 
> > (Koen issued an patch to update to the latest 1.1.16 git head and part of
> > the later discussion was also CC'd to the musl ML.)
> > But this wasn't fixed in time for 1.1.17.
> >
> > However, this regression and two other problems then let to the 1.1.18 
> > release
> > shortly thereafter. 
> Yes,
> 
> Main reason in that specific case was mainly for these 2 fixes:
> 
> /9e01be6 fix signal masking race in pthread_create with priority (I use 
> lots of threading & thread priority in my app) //51bdcdc fix OOB reads in 
> Xbyte_memmem (used by memmem() ) /
>
Hm? Are you now talking about something else? I remember seeing these
commits listed in your musl update to 1.1.16+. 


But Felix did the update musl to 1.1.18 on the 5th (I noticed that he had
a patch queued). This update included the changes you listed, right?

> fwiw, my 2 cents:
>
> I try to carefully judge whether there's a good reason to bump head or 
> not, and I mostly wait for min 48 hrs to let the latest commits soak a bit.
"waiting" around doesn't help in regression cases. I think this
glob-regression is another case in point. The issue was discovered
more than a week before 1.1.17 was released:

and when I posted the request to move to 1.1.17 (again).
But it only received the attention, once people started testing the new 
1.1.17 and did bisections.

> One could argue for backporting only importing changes (which I've done
> in the past), [1]
> but it was argued that it's better sometimes to just bump the git head
> instead
> as it can take months before a new release is done containing critical
> fixes, which is the reason for the switch to git download [2]
> 
> Maybe a balanced solution would be to wait for 1 .. 2  tested-by's 
> before pushing these to master?
Great that you bring this up. So, did you test >this patch< already too?
And if so, what's your verdict? Does it perform as expected on your cns3xxx?
Can you please post a "tested-by" tag then?

As for pushing to master: From most past experience, a patch usually sits
in the patchwork queue for some time (a few days to months). Then one of
the commiter adds it to his/her public staging tree and if all went well, 
the patch moves to master eventually.
 
Regards,
Christian

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

Re: [LEDE-DEV] [PATCH 4/4] toolchain: musl: update to current HEAD

[Christian Lamparter]

On Monday, November 20, 2017 7:34:31 PM CET Karl Palsson wrote:
> Christian Lamparter <chunk...@gmail.com> wrote:
> > On Monday, November 20, 2017 8:17:05 AM CET Syrone Wong wrote:
> > > Any specific reason to introduce these changes?
> > Actually yes. The LEDE Website prides itself with
> > "LEDE is actively updated [...]"
> > <https://lede-project.org/reasons_to_use_lede#security>
> 
> Actively updated is one, "we're going to be standing on the
> bleeding edge at all times, you're gonna get cut" is another.
> Musl is also making releases quite regularly, it's not even 20
> days since 17, and only 30 since 16.

This is all documented on the musl ML.

musl 1.1.17 was rushed due to this CVE:
<http://www.cvedetails.com/cve/CVE-2017-15650/>

However, the 1.1.17 release had accumulated like 11 months of patches since
the previous 1.1.16 release. There have been several regressions that went 
unnoticed. But this only really came to light after 1.1.17 was already 
released. Because the different projects and people actually started to test
it now. 

In fact, Syrone Wong actually discovered the regression earlier.
<http://lists.infradead.org/pipermail/lede-dev/2017-October/009237.html>
(Koen issued an patch to update to the latest 1.1.16 git head and part of
the later discussion was also CC'd to the musl ML.)
But this wasn't fixed in time for 1.1.17.

However, this regression and two other problems then let to the 1.1.18 release
shortly thereafter. <https://marc.info/?l=musl=150860332132027=2>

(I think you meant the 1.1.17 and 1.1.18 release, right?
Because the 1.1.16 release is according to:
<http://git.musl-libc.org/cgit/musl> now 11 months old.

> Surely musl would be considering a release too for these issues?
It's not just issues and regressions. It's also UAPI updates and
updates to the LEDE specific iconv patch that was broken due to
Rich reworking the iconv. All these changes already start to pile-up.

Regards,
Christian

> > a71b46cf fix malloc state corruption when ldso rejects loading
> > a second libc The Thread on the MUSL ML is "[musl] diffutils
> > crash in malloc". Judging from the descussion, it can cause
> > programs to misbehave starting with 1.1.17 and 1.1.18.
> > 
> > And there's more:
> > 72656157 fix fgetwc when decoding a character that crosses
> > buffer boundary c21051e9 prevent fork's errno from being
> > clobbered by atfork handlers
> > ...
> > 
> > + some UAPI updates, which will be nice to have for 4.14 development.
> > 
> > And Also, Rich made big changes to iconv and it broke the
> > 900-iconv_size_hack.patch.
> > 
> > Regards,
> > Christian


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

Re: [LEDE-DEV] [PATCH 1/4] firmware: ath10k-firmware: update QCA4019 firmware to 10.4-3.2.1-00058

[Christian Lamparter]

On Monday, November 20, 2017 11:23:18 AM CET Matthew McClintock wrote:
> On Mon, Nov 20, 2017 at 10:53 AM, Christian Lamparter
> <chunk...@gmail.com> wrote:
> > On Monday, November 20, 2017 9:45:28 AM CET Matthew McClintock wrote:
> >> Did you get ath10k working on ipq4019?
> >
> > Yes, I managed to upstream the wifi dts changes some time ago and they
> > all have been accepted. In fact the new 4.14 does ships with those.
> >
> > https://patchwork.kernel.org/patch/9858197/
> >
> > How is your upstreaming progess going?
> >
> >> I'm having issues with the board data files? I've never messed with this.
> >
> > What do you want to know?
> >
> > I'm assuming that you are looking for a way to package the two board.bin
> > (2GHz and 5GHz) into a board-2.bin. You can just use the ath10k-bdencoder
> > tool from the <https://github.com/qca/qca-swiss-army-knife>
> >
> > Note: ath10k-bdencoder can also unpack existing board-2.bin that are
> > currently shipped with any of the the ipq-wifi packages. So the fastest way
> > would be to unpack a existing board-2.bin (this will create a .json file and
> > the individual .bins). Then you just have to replace the two board.bin files
> > and repack it (the repack process will need the created .json file again.)
> >
> > If this isn't what you are looking for, you might find it in the
> > "firmware: add custom IPQ wifi board definitions" commit message.
> >
> 
> Caveat: I'm using an older version of ath10k at the moment, but
This is can be a big caveat. Depending on how "old" the ath10k /
compat-wireless / backports really is. On OpenWRT/older LEDE versions
QCA4019 was broken by a patch: 936-ath10k_skip_otp_check.patch.

You should definitely go for a recent version.
 
> I think it's complaining that it can't find the right board info from
> the board-2.bin file which is just multiple board files wrapped up
> together?
> 
> [  233.761660] ath10k_ahb a00.wifi: failed to fetch board data for
> bus=ahb,vendor=,device=,subsystem-vendor=,subsystem-device=
> from ath10k/QCA4019/hw1.0/board-2.bin
The device identifcation doesn't work.

The driver is thinking it has a non-sensical "ahb pci(e)" device.
Just look at the fact that the driver is looking for "bus=ahb" but also 
"vendor=0,device=0...,subsystem...=...,..."(which is used to identify
pcie devices). If it was looking for a bmi device, the board search string
would look something like "bus=ahb,bmi-chip-id=0,bmi-board-id=16"

I can only guess what's really going on, since this is such a short extract.

But there at least two likely scenarios:
1. 936-ath10k_skip_otp_check.patch is present / ath10k is too old

2. the pre-cal-ahb-a80.wifi.bin and pre-cal-ahb-a00.wifi.bin
   don't get loaded or the pre-cal* data is shifted/trimmed/mangled/bad.

For 2. you should check if the firmware hotplug 11-ath10k-caldata script
is correctly extracting the pre-cal from the "ART" Partition of your device
to /lib/firmware/ath10k. I posted one of the RT-AC58U's pre-cal files on the
linux-wireless / ath10k-devel mailing-list.
If you need something to compare to, look for the cal-file attachment:
<https://www.mail-archive.com/ath10k@lists.infradead.org/msg05911.html>

(Note: Netgear used to ship the source from which these .bin files are
created by the calibration utility in thier GPL source of the R7800 / D7800)

> This is the first pass, it moves onto board.bin but still fails (the
> file is not present).
> 
> Where is a description of the which board.bin files to use for which
> radios? Where does this info come from? Somewhere in the radio or OTP?
I don't think this was actually documented anywhere officially by
Qualcomm Atheros. The best resource I currently know of, is this write-up
from Sven Eckelmann:
<http://lists.infradead.org/pipermail/ath10k/2017-January/009025.html>

followed by the response from Adrian Chadd (he used to work for QCA, but
no longer does):
<http://lists.infradead.org/pipermail/ath10k/2017-January/009104.html>

If you have further questions, your best bet is to write to the
linux-wireless and ath10k-devel ML.
 
> Interestingly, PCI is complaining too:
> 
> [  236.712965] ath10k_pci :01:00.0: failed to fetch board data for
> bus=pci,bmi-chip-id=0,bmi-board-id=19 from
> ath10k/QCA9888/hw2.0/board-2.bin
> 
> Is my board just not setup right? Missing OTP id? I guess I can force
> a working radio with a board.bin file?
This "board-id=19" is currently not available in the ath10k-firmware.git:

According to the latest QCA9888 patch, it just supports
<https://github.com/kvalo/ath10k-firmware/commit/3cfabec862d4969a64ac6ddf2bfe69deb72107ac#diff-d5

Re: [LEDE-DEV] [PATCH 4/4] toolchain: musl: update to current HEAD

[Christian Lamparter]

Hello,

On Monday, November 20, 2017 8:17:05 AM CET Syrone Wong wrote:
> Hi,
> 
> Any specific reason to introduce these changes?
Actually yes. The LEDE Website prides itself with
"LEDE is actively updated [...]"


a71b46cf fix malloc state corruption when ldso rejects loading a second libc
The Thread on the MUSL ML is "[musl] diffutils crash in malloc".
Judging from the descussion, it can cause programs to misbehave starting with
1.1.17 and 1.1.18.

And there's more:
72656157 fix fgetwc when decoding a character that crosses buffer boundary
c21051e9 prevent fork's errno from being clobbered by atfork handlers
...

+ some UAPI updates, which will be nice to have for 4.14 development.

And Also, Rich made big changes to iconv and it broke the
900-iconv_size_hack.patch.

Regards,
Christian

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

Re: [LEDE-DEV] [PATCH 1/4] firmware: ath10k-firmware: update QCA4019 firmware to 10.4-3.2.1-00058

[Christian Lamparter]

On Monday, November 20, 2017 9:45:28 AM CET Matthew McClintock wrote:
> Did you get ath10k working on ipq4019?

Yes, I managed to upstream the wifi dts changes some time ago and they
all have been accepted. In fact the new 4.14 does ships with those.

https://patchwork.kernel.org/patch/9858197/

How is your upstreaming progess going?

> I'm having issues with the board data files? I've never messed with this.

What do you want to know?

I'm assuming that you are looking for a way to package the two board.bin
(2GHz and 5GHz) into a board-2.bin. You can just use the ath10k-bdencoder
tool from the <https://github.com/qca/qca-swiss-army-knife>

Note: ath10k-bdencoder can also unpack existing board-2.bin that are
currently shipped with any of the the ipq-wifi packages. So the fastest way
would be to unpack a existing board-2.bin (this will create a .json file and
the individual .bins). Then you just have to replace the two board.bin files
and repack it (the repack process will need the created .json file again.)

If this isn't what you are looking for, you might find it in the 
"firmware: add custom IPQ wifi board definitions" commit message.

Regards,
Christian

> On Sun, Nov 19, 2017 at 10:19 AM, Christian Lamparter
> <chunk...@gmail.com> wrote:
> > This patch updates ath10k-firmware to use the
> > firmware-5.bin_10.4-3.2.1-00058 firmware for the QCA4019.
> >
> > Cc: Hauke Mehrtens <ha...@hauke-m.de>
> > Signed-off-by: Christian Lamparter <chunk...@gmail.com>
> > ---
> >  package/firmware/ath10k-firmware/Makefile | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/package/firmware/ath10k-firmware/Makefile 
> > b/package/firmware/ath10k-firmware/Makefile
> > index 9a34ac3155..1c6f4dfb7f 100644
> > --- a/package/firmware/ath10k-firmware/Makefile
> > +++ b/package/firmware/ath10k-firmware/Makefile
> > @@ -8,9 +8,9 @@
> >  include $(TOPDIR)/rules.mk
> >
> >  PKG_NAME:=ath10k-firmware
> > -PKG_SOURCE_DATE:=2017-03-29
> > -PKG_SOURCE_VERSION:=956e2609b7e42c8c710bba10ef925a5be1be5137
> > -PKG_MIRROR_HASH:=25f724ff38c830281b3efba4a4ddffaae0c4bd8fea0f4c1061591229ff05535b
> > +PKG_SOURCE_DATE:=2017-10-30
> > +PKG_SOURCE_VERSION:=476a2850b1e8582d51187799d7de209daf1a57b2
> > +PKG_MIRROR_HASH:=77ba59f75c5897c842c5c525945de019fd23f1e2d8bea6239924857e500bf73a
> >  PKG_RELEASE:=1
> >
> >  PKG_SOURCE_PROTO:=git
> > @@ -223,7 +223,7 @@ define Package/ath10k-firmware-qca4019/install
> > $(PKG_BUILD_DIR)/QCA4019/hw1.0/board-2.bin \
> > $(1)/lib/firmware/ath10k/QCA4019/hw1.0/
> > $(INSTALL_DATA) \
> > -   
> > $(PKG_BUILD_DIR)/QCA4019/hw1.0/3.2.1/firmware-5.bin_10.4-3.2.1-00053 \
> > +   
> > $(PKG_BUILD_DIR)/QCA4019/hw1.0/3.2.1/firmware-5.bin_10.4-3.2.1-00058 \
> > $(1)/lib/firmware/ath10k/QCA4019/hw1.0/firmware-5.bin
> >  endef
> >
> > --
> > 2.15.0
> >
> >
> > ___
> > 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

[LEDE-DEV] [PATCH 1/4] firmware: ath10k-firmware: update QCA4019 firmware to 10.4-3.2.1-00058

[Christian Lamparter]

This patch updates ath10k-firmware to use the
firmware-5.bin_10.4-3.2.1-00058 firmware for the QCA4019.

Cc: Hauke Mehrtens <ha...@hauke-m.de>
Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
 package/firmware/ath10k-firmware/Makefile | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/package/firmware/ath10k-firmware/Makefile 
b/package/firmware/ath10k-firmware/Makefile
index 9a34ac3155..1c6f4dfb7f 100644
--- a/package/firmware/ath10k-firmware/Makefile
+++ b/package/firmware/ath10k-firmware/Makefile
@@ -8,9 +8,9 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=ath10k-firmware
-PKG_SOURCE_DATE:=2017-03-29
-PKG_SOURCE_VERSION:=956e2609b7e42c8c710bba10ef925a5be1be5137
-PKG_MIRROR_HASH:=25f724ff38c830281b3efba4a4ddffaae0c4bd8fea0f4c1061591229ff05535b
+PKG_SOURCE_DATE:=2017-10-30
+PKG_SOURCE_VERSION:=476a2850b1e8582d51187799d7de209daf1a57b2
+PKG_MIRROR_HASH:=77ba59f75c5897c842c5c525945de019fd23f1e2d8bea6239924857e500bf73a
 PKG_RELEASE:=1
 
 PKG_SOURCE_PROTO:=git
@@ -223,7 +223,7 @@ define Package/ath10k-firmware-qca4019/install
$(PKG_BUILD_DIR)/QCA4019/hw1.0/board-2.bin \
$(1)/lib/firmware/ath10k/QCA4019/hw1.0/
$(INSTALL_DATA) \
-   
$(PKG_BUILD_DIR)/QCA4019/hw1.0/3.2.1/firmware-5.bin_10.4-3.2.1-00053 \
+   
$(PKG_BUILD_DIR)/QCA4019/hw1.0/3.2.1/firmware-5.bin_10.4-3.2.1-00058 \
$(1)/lib/firmware/ath10k/QCA4019/hw1.0/firmware-5.bin
 endef
 
-- 
2.15.0


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

[LEDE-DEV] [PATCH 4/4] toolchain: musl: update to current HEAD

[Christian Lamparter]

Changes:

72656157 fix fgetwc when decoding a character that crosses buffer boundary
a223dbd2 add reverse iconv mappings for JIS-based encodings
105eff9d generalize iconv framework for 8-bit codepages
a71b46cf fix malloc state corruption when ldso rejects loading a second libc
d060edf6 reformat cjk iconv tables to be diff-friendly, match tool output
c21051e9 prevent fork's errno from being clobbered by atfork handlers
a39f20bf add iso-2022-jp support (decoding only) to iconv
5b546faa add iconv framework for decoding stateful encodings
0df5b39a simplify/optimize iconv utf-8 case
9eb6dd51 handle ascii range individually in each iconv case
bff59d13 move iconv_close to its own translation unit
79f49eff refactor iconv conversion descriptor encoding/decoding
30fdda6c fix getaddrinfo error code for non-numeric service with AI_NUMERICSERV
67b29947 fix mismatched type of __pthread_tsd_run_dtors weak definition
13935337 s390x: use generic ioctl.h
4dc44ce8 microblaze: add statx syscall from linux v4.13
ffd048a0 aarch64: add extra_context struct from linux v4.13
6651ef1f add new tcp.h socket options from linux v4.13
14ced228 add new fcntl.h macros from linux v4.13
754f66af ioctl TIOCGPTPEER from linux v4.13
c35a8bf4 add SO_ getsockopt options from linux v4.13
5daaed6a s390x: add syscall number for s390_guarded_storage from linux v4.12
2dc6760f i386: add arch_prctl syscall number from linux v4.12
840d45be aarch64: add new HWCAP_* flags from linux v4.12
4c811227 add ARPHDR_VSOCKMON from linux v4.12
54f04d99 add new SO_ socket options from linux v4.12
9864f60e add statx syscall numbers from linux v4.11
c519658c add TCP_NLA_* enums from linux v4.11
ee3ae782 add TCP_FASTOPEN_CONNECT tcp socket option from linux v4.11
3eb82f73 add ETH_P_IBOE from linux v4.11
bd1560f6 update aarch64 hwcap.h for linux v4.11
cee73f0c add kexec_file_load syscall number on powerpc from linux v4.10
8f569557 add microblaze syscall numbers from linux v4.10
d8004030 add TFD_TIMER_CANCEL_ON_SET that timerfd.h was missing
f5638c22 add ETH_MIN_MTU and ETH_MAX_MTU from linux v4.10
01369691 add IP_RECVFRAGSIZE and IPV6_RECVFRAGSIZE from linux v4.10
5c596ed8 add SCM_TIMESTAMPING_OPT_STATS and related TCP_ enums from linux v4.10
6fc6ca1a adjust posix_spawn dup2 action behavior to match future requirements

Cc: Syrone Wong <wong.syr...@gmail.com>
Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
 toolchain/musl/common.mk |  4 +-
 toolchain/musl/patches/900-iconv_size_hack.patch | 70 +---
 2 files changed, 53 insertions(+), 21 deletions(-)

diff --git a/toolchain/musl/common.mk b/toolchain/musl/common.mk
index 2a61516372..a94a475571 100644
--- a/toolchain/musl/common.mk
+++ b/toolchain/musl/common.mk
@@ -13,8 +13,8 @@ PKG_RELEASE=1
 
 PKG_SOURCE_PROTO:=git
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
-PKG_SOURCE_VERSION:=eb03bde2f24582874cb72b56c7811bf51da0c817
-PKG_MIRROR_HASH:=150808458007eeb0b977059f36f88127d1a1e80ddb6ad1837b5a63efd2958e34
+PKG_SOURCE_VERSION:=72656157f54c47277b01ec85a6ba7c4084fea6c8
+PKG_MIRROR_HASH:=a3d857c23c94aa96a4ad5f442aaf236e5a189a717273c4e4faf425988d98cd32
 PKG_SOURCE_URL:=git://git.musl-libc.org/musl
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.xz
 
diff --git a/toolchain/musl/patches/900-iconv_size_hack.patch 
b/toolchain/musl/patches/900-iconv_size_hack.patch
index db18fceb17..41cff5b033 100644
--- a/toolchain/musl/patches/900-iconv_size_hack.patch
+++ b/toolchain/musl/patches/900-iconv_size_hack.patch
@@ -1,14 +1,14 @@
 --- a/src/locale/iconv.c
 +++ b/src/locale/iconv.c
-@@ -39,6 +39,7 @@ static const unsigned char charmaps[] =
+@@ -42,6 +42,7 @@ static const unsigned char charmaps[] =
  "ucs4\0ucs4be\0utf32\0utf32be\0\0\300"
  "ucs4le\0utf32le\0\0\303"
  "ascii\0usascii\0iso646\0iso646us\0\0\307"
 +#ifdef FULL_ICONV
  "eucjp\0\0\320"
  "shiftjis\0sjis\0\0\321"
- "gb18030\0\0\330"
-@@ -46,6 +47,7 @@ static const unsigned char charmaps[] =
+ "iso2022jp\0\0\322"
+@@ -50,6 +51,7 @@ static const unsigned char charmaps[] =
  "gb2312\0\0\332"
  "big5\0bigfive\0cp950\0big5hkscs\0\0\340"
  "euckr\0ksc5601\0ksx1001\0cp949\0\0\350"
@@ -16,7 +16,7 @@
  #include "codepages.h"
  ;
  
-@@ -53,6 +55,7 @@ static const unsigned short legacy_chars
+@@ -60,6 +62,7 @@ static const unsigned short legacy_chars
  #include "legacychars.h"
  };
  
@@ -24,45 +24,77 @@
  static const unsigned short jis0208[84][94] = {
  #include "jis0208.h"
  };
-@@ -72,6 +75,7 @@ static const unsigned short hkscs[] = {
+@@ -79,6 +82,7 @@ static const unsigned short hkscs[] = {
  static const unsigned short ksc[93][94] = {
  #include "ksc.h"
  };
 +#endif
  
- static int fuzzycmp(const unsigned char *a, const unsigned char *b)
+ static const unsigned short rev_jis[] = {
+ #include "revjis.h"
+@@ -196,6 +200,7 @@ static unsigned legac

[LEDE-DEV] [PATCH 3/4] wireless-regdb: fix PKG_MIRROR_HASH

[Christian Lamparter]

make check complains about PKG_MIRROR_HASH of the wireless-regdb package:

WARNING: PKG_MIRROR_HASH does not match 
wireless-regdb-2017-10-20-4343d359.tar.xz
hash 5f5b669f32ae36cb65b1d99efbbbfd42c2983cda32f6448346e3e54ffaba3889

Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
 package/firmware/wireless-regdb/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/firmware/wireless-regdb/Makefile 
b/package/firmware/wireless-regdb/Makefile
index fa732b2d38..d06da2c708 100644
--- a/package/firmware/wireless-regdb/Makefile
+++ b/package/firmware/wireless-regdb/Makefile
@@ -6,7 +6,7 @@ PKG_SOURCE_PROTO:=git
 
PKG_SOURCE_URL:=https://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git
 PKG_SOURCE_DATE:=2017-10-20
 PKG_SOURCE_VERSION:=4343d359ed5e7404de8803a74df186457b26ab79
-PKG_MIRROR_HASH:=b827bf760de57b907df159c8d38d7c3fb5b4a691781114c47739e20bffb3a312
+PKG_MIRROR_HASH:=5f5b669f32ae36cb65b1d99efbbbfd42c2983cda32f6448346e3e54ffaba3889
 
 PKG_MAINTAINER:=Felix Fietkau <n...@nbd.name>
 
-- 
2.15.0


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

[LEDE-DEV] [PATCH 2/4] base-files: upgrade: make get_partitions() endian agnostic

[Christian Lamparter]

This patch fixes two issues with the current get_partitions()
function.

First: "Invalid partition table on $disk" will pop up on
legitimate images on big endian system.

This is because the little-endian representation of "55 AA" is
assumed in the context of little-endian architectures. On these
comparing it to the 16-bit word 0xAA55 does work as intented.
Whereas on big-endian systems, this would have to be 0x55AA.

This patch fixes the issue by replacing the integer conversion
and value match check with just a string comparision.

Second: The extraction of the type, start LBA and LBA num from
the partition table has the same endianness issue. This has been
fixed by using the new hex_le32_to_cpu() function. This function
will translate the stored little-endian data to the correct
byte-order if necessary.

Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
 package/base-files/files/lib/upgrade/common.sh | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/package/base-files/files/lib/upgrade/common.sh 
b/package/base-files/files/lib/upgrade/common.sh
index 428ec735d6..71cffc8587 100644
--- a/package/base-files/files/lib/upgrade/common.sh
+++ b/package/base-files/files/lib/upgrade/common.sh
@@ -160,6 +160,14 @@ export_partdevice() {
return 1
 }
 
+hex_le32_to_cpu() {
+   [ "$(echo 01 | hexdump -v -n 2 -e '/2 "%x"')" == "3031" ] && {
+   echo "${1:0:2}${1:8:2}${1:6:2}${1:4:2}${1:2:2}"
+   return
+   }
+   echo "$@"
+}
+
 get_partitions() { #  
local disk="$1"
local filename="$2"
@@ -167,8 +175,8 @@ get_partitions() { #  
if [ -b "$disk" -o -f "$disk" ]; then
v "Reading partition table from $filename..."
 
-   local magic="$(hexdump -v -n 2 -s 0x1FE -e '1/2 "0x%04X"' 
"$disk")"
-   if [ "$magic" != 0xAA55 ]; then
+   local magic=$(dd if="$disk" bs=2 count=1 skip=255 2>/dev/null)
+   if [ "$magic" != $'\x55\xAA' ]; then
v "Invalid partition table on $disk"
exit
fi
@@ -179,9 +187,9 @@ get_partitions() { #  
for part in 1 2 3 4; do
set -- $(hexdump -v -n 12 -s "$((0x1B2 + $part * 16))" 
-e '3/4 "0x%08X "' "$disk")
 
-   local type="$(($1 % 256))"
-   local lba="$(($2))"
-   local num="$(($3))"
+   local type="$(( $(hex_le32_to_cpu $1) % 256))"
+   local lba="$(( $(hex_le32_to_cpu $2) ))"
+   local num="$(( $(hex_le32_to_cpu $3) ))"
 
[ $type -gt 0 ] || continue
 
-- 
2.15.0


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

Re: [LEDE-DEV] [PATCH] musl: update to 1.1.17

[Christian Lamparter]

On Monday, November 6, 2017 2:48:56 PM CET Felix Fietkau wrote:
> On 2017-11-06 14:46, John Crispin wrote:
> > Hi,
> > 
> > 1.1.18 is out, we we go directly to that version please ?
> I've already queued a commit that updates to 1.1.18 in my staging tree.
> 
Yeah, go for it.


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

Re: [LEDE-DEV] [RFC 2/3] ipq: Don't force selection of the IPQ4019 firmware.

[Christian Lamparter]

On Friday, November 3, 2017 8:15:00 PM CET Ben Greear wrote:
> 
> On 11/03/2017 05:58 PM, Christian Lamparter wrote:
> > On Friday, November 3, 2017 5:05:39 PM CET gree...@candelatech.com wrote:
> >> From: Ben Greear <gree...@candelatech.com>
> >>
> >> This will allow us to select the CT IPQ4019 firmware instead if
> >> desired.
> >>
> >> Signed-off-by: Ben Greear <gree...@candelatech.com>
> >> ---
> >>  package/firmware/ipq-wifi/Makefile | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/package/firmware/ipq-wifi/Makefile 
> >> b/package/firmware/ipq-wifi/Makefile
> >> index aec8bf2..31d0fbf 100644
> >> --- a/package/firmware/ipq-wifi/Makefile
> >> +++ b/package/firmware/ipq-wifi/Makefile
> >> @@ -20,7 +20,7 @@ define Package/ipq-wifi-default
> >>SUBMENU:=ath10k IPQ4019 Boarddata
> >>SECTION:=firmware
> >>CATEGORY:=Firmware
> >> -  DEPENDS:=@TARGET_ipq806x +ath10k-firmware-qca4019
> >> +  DEPENDS:=@TARGET_ipq806x
> > Hm, this would break the WIFI in the default configuration for the
> > FritzBox 4040 image. Currently it only has a dependency on the
> > ipq-wifi-fritz4040. (So it will end up without a firmware-5.bin)
> >
> > Please also note that the ipq-wifi boards need to overwrite the
> > board-2.bin provided by the ath10k-firmware-qca4019(-ct) packages.
> > So switching (or up-/downgrading) these wifi-firmwares will always
> > require the (manual) reinstallation of the ipq-wifi board
> > (if available).
> 
> Maybe have the custom board.data file named slightly differently
> and then have an early fixup script to copy it into the proper place
> on first boot?  And, we could hack the driver to look for a custom
> board-2.bin first and just install both board-x.bin images.
Depends, can you convince the ath10k upstream to do that?
> 
> And, can we have the IPQ boards select the stock 4019 firmware by default
> but still allow it to be de-selected so CT firmware can be selected?
>
> Or if not, then I can call my firmware something different, and have my
> driver look for it before the firmware-5.bin.

I think there's a another way to do this. But it will require to break with
the existing convention of adding the board-2.bin that comes with the
firmware repository to the ath10k-firmware-qca4019 file.

This way, the custom board-2.bin will stay in place when you switch/update
the firmware-5.bin. 

(The board-2.bin for the reference boards can simply be packaged just like
one of the ipq-wifi board firmwares). And furhtermore, you could provide a
"easy to use/install" custom ipq-wifi.ipk for the board-2.bin you currently
host on your webside.

Regards,
Christian


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

Re: [LEDE-DEV] [RFC 2/3] ipq: Don't force selection of the IPQ4019 firmware.

[Christian Lamparter]

On Friday, November 3, 2017 5:05:39 PM CET gree...@candelatech.com wrote:
> From: Ben Greear 
> 
> This will allow us to select the CT IPQ4019 firmware instead if
> desired.
> 
> Signed-off-by: Ben Greear 
> ---
>  package/firmware/ipq-wifi/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/package/firmware/ipq-wifi/Makefile 
> b/package/firmware/ipq-wifi/Makefile
> index aec8bf2..31d0fbf 100644
> --- a/package/firmware/ipq-wifi/Makefile
> +++ b/package/firmware/ipq-wifi/Makefile
> @@ -20,7 +20,7 @@ define Package/ipq-wifi-default
>SUBMENU:=ath10k IPQ4019 Boarddata
>SECTION:=firmware
>CATEGORY:=Firmware
> -  DEPENDS:=@TARGET_ipq806x +ath10k-firmware-qca4019
> +  DEPENDS:=@TARGET_ipq806x
Hm, this would break the WIFI in the default configuration for the 
FritzBox 4040 image. Currently it only has a dependency on the 
ipq-wifi-fritz4040. (So it will end up without a firmware-5.bin)

Please also note that the ipq-wifi boards need to overwrite the 
board-2.bin provided by the ath10k-firmware-qca4019(-ct) packages.
So switching (or up-/downgrading) these wifi-firmwares will always
require the (manual) reinstallation of the ipq-wifi board
(if available).

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

Re: [LEDE-DEV] [PATCH] ath10k-firmware: update QCA9888 and QCA4019 firmware

[Christian Lamparter]

On Monday, October 16, 2017 12:19:10 AM CET Hauke Mehrtens wrote:
> On 10/14/2017 05:35 PM, Christian Lamparter wrote:
> > On Saturday, October 14, 2017 11:24:24 AM CEST Hauke Mehrtens wrote:
> >> This updates the firmware files for the QCA9888 and QCA4019
> >> chips to a more recent version which is also used in the linux-firmware
> >> repository.
> >>
> >> Signed-off-by: Hauke Mehrtens <ha...@hauke-m.de>
> >> ---
> >>
> >> Could someone with a QCA4019 or QCA9888 device please test this.
> >> I do not have these deceives to test this myself.
> >>
> >>  package/firmware/ath10k-firmware/Makefile | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/package/firmware/ath10k-firmware/Makefile 
> >> b/package/firmware/ath10k-firmware/Makefile
> >> index 84889d9d29..5e0f41ea52 100644
> >> --- a/package/firmware/ath10k-firmware/Makefile
> >> +++ b/package/firmware/ath10k-firmware/Makefile
> >> @@ -223,7 +223,7 @@ define Package/ath10k-firmware-qca4019/install
> >>$(PKG_BUILD_DIR)/QCA4019/hw1.0/board-2.bin \
> >>$(1)/lib/firmware/ath10k/QCA4019/hw1.0/
> >>$(INSTALL_DATA) \
> >> -  
> >> $(PKG_BUILD_DIR)/QCA4019/hw1.0/3.2.1/firmware-5.bin_10.4-3.2.1-00053 \
> >> +  
> >> $(PKG_BUILD_DIR)/QCA4019/hw1.0/3.4/firmware-5.bin_10.4-3.4-00082 \
> >>$(1)/lib/firmware/ath10k/QCA4019/hw1.0/firmware-5.bin
> >>  endef
> > The new IPQ4019 firmware isn't as stable as the old one. I do see hangs
> > from time to time (rx ring became corrupted). Whenever this is due to a
> > bug in the firmware or the firmware is pushing harder, I don't know.
> > <https://forum.lede-project.org/t/how-to-build-ipq4018-firmware/4513/16>
> 
> Thank you for the information, so I will not upgrade the IPQ4019 firmware.
> 
> I also wanted to upgrade the QCA988X firmware first, but it was crashing
> directly after being loaded and now linux-firmeware ships the old one again:
> http://lists.infradead.org/pipermail/ath10k/2017-September/010138.html
> 

FYI: There's a new firmware now for the IPQ4019:

firmware-5.bin_10.4-3.2.1-00058

https://github.com/kvalo/ath10k-firmware/commit/476a2850b1e8582d51187799d7de209daf1a57b2

Regards,
Christian

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

Re: [LEDE-DEV] [PATCH] musl: update to 1.1.17

[Christian Lamparter]

On Sunday, October 22, 2017 12:02:07 AM CEST Hannu Nyman wrote:
> Hauke Mehrtens wrote on Sat Oct 21 12:26:04 PDT 2017:
>  > I think your problem is fixed in ec04d122f1182aeb91f39b0e80ae40c68e4d9605
>  > fix regression in glob with literal . or .. path component
> 
> Based on musl mailing list, there will likely be a new musl release rather 
> soon:
> 
> Rich Felker wrote in http://www.openwall.com/lists/musl/2017/10/21/3
>  > > This was wrong and introduced a regression: literal . and .. in paths 
> passed into glob result in no results.
>  > > ...
>  > > Due to this and a couple small other bugs/regressions, I think it will 
> make sense to make another release right away, to have a solid "works out of 
> the box without patching" one as the latest. Please let me know if you spot 
> other regressions so fixes can be included.

Ok, so wait for the next release then, or should I just respin the patch
based on the current tree?

Regards,
Christian

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

[LEDE-DEV] [PATCH] musl: update to 1.1.17

[Christian Lamparter]

This patch updates musl to the latest 1.1.17 release.

Rick Felker stated in his release note: "
This release fixes numerous bugs affecting visible behavior and
safety/internal consistency, including a stack-based buffer overflow
in dns parsing and multiple sources of invalid memory accesses that
may lead to crashes. See the release notes in WHATSNEW for details.

Many new features have also been added, including deferred symbol
binding in the dynamic linker (RTLD_LAZY emulation), an option to
overrid argv[0] when running ldso to execute a program, support for
starting new sessions via posix_spawn (POSIX_SPAWN_SETSID, accepted
for standardization), and ability to query the active thread-local
locale (via _NL_LOCALE_NAME extension). Improvements in compatibility
with applications, build tools, and platforms have also been made.
" <http://www.openwall.com/lists/musl/2017/10/19/1>

The stack-based buffer overflow in dns parsing can be mitigated by:
"running a caching nameserver on localhost and pointing resolv.conf
to 127.0.0.1." <http://www.openwall.com/lists/musl/2017/10/19/2>
Which is the case on the default LEDE installation (dnsmasq).

Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
 toolchain/musl/common.mk | 6 +++---
 toolchain/musl/patches/900-iconv_size_hack.patch | 4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/toolchain/musl/common.mk b/toolchain/musl/common.mk
index 0a45828f79..4c4e5b47ae 100644
--- a/toolchain/musl/common.mk
+++ b/toolchain/musl/common.mk
@@ -8,13 +8,13 @@ include $(TOPDIR)/rules.mk
 include $(INCLUDE_DIR)/target.mk
 
 PKG_NAME:=musl
-PKG_VERSION:=1.1.16
+PKG_VERSION:=1.1.17
 PKG_RELEASE=1
 
 PKG_SOURCE_PROTO:=git
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
-PKG_SOURCE_VERSION:=5f7efb87a28a311ad377dd26adf53715dedb096d
-PKG_MIRROR_HASH:=da18ef24f270e5cae6bc4c440479da17bec1949ae5a1bc990352ca04f24c4378
+PKG_SOURCE_VERSION:=2cd663fb2d576d590a08c1e40386c07b378d5ad6
+PKG_MIRROR_HASH:=e3140faaa9aff51c4f56f36c15d677265a5bed39aa6d9ab5d252f1c49b7c13ca
 PKG_SOURCE_URL:=git://git.musl-libc.org/musl
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.xz
 
diff --git a/toolchain/musl/patches/900-iconv_size_hack.patch 
b/toolchain/musl/patches/900-iconv_size_hack.patch
index 343915fb06..cfbb7ee5f7 100644
--- a/toolchain/musl/patches/900-iconv_size_hack.patch
+++ b/toolchain/musl/patches/900-iconv_size_hack.patch
@@ -32,7 +32,7 @@
  
  static int fuzzycmp(const unsigned char *a, const unsigned char *b)
  {
-@@ -216,6 +220,7 @@ size_t iconv(iconv_t cd0, char **restric
+@@ -224,6 +228,7 @@ size_t iconv(iconv_t cd0, char **restric
c = ((c-0xd7c0)<<10) + (d-0xdc00);
}
break;
@@ -47,7 +47,7 @@
 +#endif
default:
if (c < 128+type) break;
-   c -= 128+type;
+   c = legacy_map(map, c);
 --- a/src/locale/codepages.h
 +++ b/src/locale/codepages.h
 @@ -118,6 +118,7 @@
-- 
2.15.0.rc1


___
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:
> > <http://lists.infradead.org/pipermail/ath10k/2016-November/008763.html>
> > 
> > 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
> > <https://www.kernel.org/doc/Documentation/devicetree/usage-model.txt>
> 
> 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/bo

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 

Re: [LEDE-DEV] [PATCH] ath10k-firmware: update QCA9888 and QCA4019 firmware

[Christian Lamparter]

On Saturday, October 14, 2017 11:24:24 AM CEST Hauke Mehrtens wrote:
> This updates the firmware files for the QCA9888 and QCA4019
> chips to a more recent version which is also used in the linux-firmware
> repository.
> 
> Signed-off-by: Hauke Mehrtens 
> ---
> 
> Could someone with a QCA4019 or QCA9888 device please test this.
> I do not have these deceives to test this myself.
> 
>  package/firmware/ath10k-firmware/Makefile | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/package/firmware/ath10k-firmware/Makefile 
> b/package/firmware/ath10k-firmware/Makefile
> index 84889d9d29..5e0f41ea52 100644
> --- a/package/firmware/ath10k-firmware/Makefile
> +++ b/package/firmware/ath10k-firmware/Makefile
> @@ -223,7 +223,7 @@ define Package/ath10k-firmware-qca4019/install
>   $(PKG_BUILD_DIR)/QCA4019/hw1.0/board-2.bin \
>   $(1)/lib/firmware/ath10k/QCA4019/hw1.0/
>   $(INSTALL_DATA) \
> - 
> $(PKG_BUILD_DIR)/QCA4019/hw1.0/3.2.1/firmware-5.bin_10.4-3.2.1-00053 \
> + 
> $(PKG_BUILD_DIR)/QCA4019/hw1.0/3.4/firmware-5.bin_10.4-3.4-00082 \
>   $(1)/lib/firmware/ath10k/QCA4019/hw1.0/firmware-5.bin
>  endef
The new IPQ4019 firmware isn't as stable as the old one. I do see hangs
from time to time (rx ring became corrupted). Whenever this is due to a
bug in the firmware or the firmware is pushing harder, I don't know.


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

[LEDE-DEV] [PATCH] dnsmasq: add listen_address parameter

[Christian Lamparter]

This patch adds a parser for the uci representation of
dnsmasq's "-a | --listen-address" option.

In summary, this option forces dnsmasq to listen on the
given IP address(es). Both interface and listen-address
options may be given, in which case the set of both
interfaces and addresses is used.

Note that if no interface option is given, but listen_address is,
dnsmasq will not automatically listen on the loopback interface.
To achieve this, the loopback IP addresses, 127.0.0.1 and/or ::1
must be explicitly added.

This option is useful for ujailed dnsmasq instances, that would
otherwise fail to work properly, because listening to the
"This host on this network" address (aka 0.0.0.0 see rfc1700 page 4)
may not be allowed.

Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
 package/network/services/dnsmasq/files/dnsmasq.init | 5 +
 1 file changed, 5 insertions(+)

diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
b/package/network/services/dnsmasq/files/dnsmasq.init
index 0149643959..3d3d83334e 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -142,6 +142,10 @@ append_interface() {
xappend "--interface=$ifname"
 }
 
+append_listenaddress() {
+   xappend "--listen-address=$1"
+}
+
 append_notinterface() {
network_get_device ifname "$1" || ifname="$1"
xappend "--except-interface=$ifname"
@@ -835,6 +839,7 @@ dnsmasq_start()
append_parm "$cfg" "maxport" "--max-port"
append_parm "$cfg" "domain" "--domain"
append_parm "$cfg" "local" "--server"
+   config_list_foreach "$cfg" "listen_address" append_listenaddress
config_list_foreach "$cfg" "server" append_server
config_list_foreach "$cfg" "rev_server" append_rev_server
config_list_foreach "$cfg" "address" append_address
-- 
2.15.0.rc0


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

[LEDE-DEV] [RFC] base-files: upgrade: make get_partitions() endian agnostic

[Christian Lamparter]

This patch fixes two issues with the current get_partitions()
function.

First: "Invalid partition table on $disk" will pop up on
legitimate images on big endian system.

This is because the little-endian representation of "55 AA" is
assumed in the context of little-endian architectures. On these
comparing it to the 16-bit word 0xAA55 does work as intented.
Whereas on big-endian systems, this would have to be 0x55AA.

This patch fixes the issue by replacing the integer conversion
and value match check with just a string comparision.

Second: The extraction of the type, start LBA and LBA num from
the partition table has the same endianness issue. This has been
fixed by using the new hex_le32_to_cpu() function. This function
will translate the stored little-endian data to the correct
byte-order if necessary.

Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
I stumbled upon this bug, when I was porting over the x86's 
sysupgrade code to the PPC MyBook Live. I'm not entirely happy
with this yet. I'm looking for a better way that could to without
the hex_le32_to_cpu. Any ideas?
---
 package/base-files/files/lib/upgrade/common.sh | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/package/base-files/files/lib/upgrade/common.sh 
b/package/base-files/files/lib/upgrade/common.sh
index 428ec735d6..71cffc8587 100644
--- a/package/base-files/files/lib/upgrade/common.sh
+++ b/package/base-files/files/lib/upgrade/common.sh
@@ -160,6 +160,14 @@ export_partdevice() {
return 1
 }
 
+hex_le32_to_cpu() {
+   [ "$(echo 01 | hexdump -v -n 2 -e '/2 "%x"')" == "3031" ] && {
+   echo "${1:0:2}${1:8:2}${1:6:2}${1:4:2}${1:2:2}"
+   return
+   }
+   echo "$@"
+}
+
 get_partitions() { #  
local disk="$1"
local filename="$2"
@@ -167,8 +175,8 @@ get_partitions() { #  
if [ -b "$disk" -o -f "$disk" ]; then
v "Reading partition table from $filename..."
 
-   local magic="$(hexdump -v -n 2 -s 0x1FE -e '1/2 "0x%04X"' 
"$disk")"
-   if [ "$magic" != 0xAA55 ]; then
+   local magic=$(dd if="$disk" bs=2 count=1 skip=255 2>/dev/null)
+   if [ "$magic" != $'\x55\xAA' ]; then
v "Invalid partition table on $disk"
exit
fi
@@ -179,9 +187,9 @@ get_partitions() { #  
for part in 1 2 3 4; do
set -- $(hexdump -v -n 12 -s "$((0x1B2 + $part * 16))" 
-e '3/4 "0x%08X "' "$disk")
 
-   local type="$(($1 % 256))"
-   local lba="$(($2))"
-   local num="$(($3))"
+   local type="$(( $(hex_le32_to_cpu $1) % 256))"
+   local lba="$(( $(hex_le32_to_cpu $2) ))"
+   local num="$(( $(hex_le32_to_cpu $3) ))"
 
[ $type -gt 0 ] || continue
 
-- 
2.15.0.rc0


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

[LEDE-DEV] [PATCH] kernel: kmod packaging for IEEE 802.1AE (MACsec) for 4.9+

[Christian Lamparter]

MACsec/IEEE 802.1AE is useful to secure communication to and
from endpoints at Layer 2.

Starting with 4.6, the linux kernel provides a universal
macsec driver for authentication and encryption of traffic
in a LAN, typically with GCM-AES-128, and optional replay
protection.

http://standards.ieee.org/getieee802/download/802.1AE-2006.pdf

Note:
LEDE can utilize MACsec with a static connectivity association
key (static PSK) with the ip-full package installed.
<http://man7.org/linux/man-pages/man8/ip-macsec.8.html>

Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
 package/kernel/linux/modules/netsupport.mk | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/package/kernel/linux/modules/netsupport.mk 
b/package/kernel/linux/modules/netsupport.mk
index 6c9b03be1d..e4740428af 100644
--- a/package/kernel/linux/modules/netsupport.mk
+++ b/package/kernel/linux/modules/netsupport.mk
@@ -1009,3 +1009,18 @@ define KernelPackage/mdio/description
 endef
 
 $(eval $(call KernelPackage,mdio))
+
+define KernelPackage/macsec
+  SUBMENU:=$(NETWORK_SUPPORT_MENU)
+  TITLE:=IEEE 802.1AE MAC-level encryption (MAC)
+  DEPENDS:=+kmod-crypto-gcm @!LINUX_3_18 @!LINUX_4_1 @!LINUX_4_4
+  KCONFIG:=CONFIG_MACSEC
+  FILES:=$(LINUX_DIR)/drivers/net/macsec.ko
+  AUTOLOAD:=$(call AutoLoad,13,macsec)
+endef
+
+define KernelPackage/macsec/description
+ MACsec is an encryption standard for Ethernet.
+endef
+
+$(eval $(call KernelPackage,macsec))
-- 
2.15.0.rc0


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

Re: [LEDE-DEV] wlan issue with TP-LINK wdr3600

[Christian Lamparter]

On Wednesday, October 11, 2017 10:42:17 PM CEST e9hack wrote:
> Hi,
> 
> Is end the hostapd config files. They are generated by a modified hostapd.sh 
> script.

Just a quick "cross-reference". It looks like this is related to ieee802.11w.
This was reported in the forum was well:
https://forum.lede-project.org/t/wpad-802-11w-no-longer-working-in-trunk/7244

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

Re: [LEDE-DEV] [PATCH 1/3] Remove ttl==255 restriction for queries

[Christian Lamparter via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Thursday, September 28, 2017 1:36:52 PM CEST Philip Prindeville wrote:
> Why was this test there and equally why are we removing it?
I guess it was there so umdns would ignore any forwarded mdns?
This would stop two mDNS reflectors to ping-pong each other. 
The avahi-daemon manpages speaks about this in:



Regards,
Christian

> 
> > On Sep 28, 2017, at 1:09 AM, Philipp Meier  
> > wrote:
> > 
> > Signed-off-by: Philipp Meier 
> > ---
> > interface.c | 6 --
> > 1 file changed, 6 deletions(-)
> > 
> > diff --git a/interface.c b/interface.c
> > index 3904c89..7f814d2 100644
> > --- a/interface.c
> > +++ b/interface.c
> > @@ -233,9 +233,6 @@ read_socket4(struct uloop_fd *u, unsigned int events)
> >}
> >}
> > 
> > -if (ttl != 255)
> > -return;
> > -
> >if (debug > 1) {
> >char buf[256];
> > 
> > @@ -310,9 +307,6 @@ read_socket6(struct uloop_fd *u, unsigned int events)
> >}
> >}
> > 
> > -if (ttl != 255)
> > -return;
> > -
> >if (debug > 1) {
> >char buf[256];
> > 
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 



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

Re: [LEDE-DEV] [PATCHv2 3/4] kernel/4.4: add generic spi-nand framework

[Christian Lamparter via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Monday, September 4, 2017 1:48:38 PM CEST Weijie Gao wrote:
> Yes. If I search "spi-nand linux" in Google, Micron's framework is the
> first result.
> However, Micron's patches are based on higher version of kernel, which
> require lots of modifications to port to linux-4.4.
> I choose the framework from LEDE's
> target/linux/pistachio/patches-4.9/, which requires only few changes.

Yes exactly this is my concern: all the porting of of out-of-tree patches.
linux-4.4 has only about five to six more month left before the patches
will run out:
 (Projected EOL: Feb, 2018).
So question is, what will ar71xx do in six month? Will it be updated to 4.9?
Or will it be ported to the upcoming 4.14? (I don't know?) Would you be 
willing to stick around and be prepared to revisit the patch in this case too?

> I've read nearly all datasheets from GigaDevice, Micron, Winbond,
> Macronix, and other manufacturers. I found that their chips are not
> full compatiable with each other.
> For example, the ECC status bits definition. GigaDevice uses one
> status to indicate the unrecoverable bits while Winbond uses two
> statuses to indicate that.

> And stacked die selection command is different between Micron and
> Winbond. And Mircon's chip has its own plane selection bit.
> 
> Even chips of the same manufacturer, the page size/OOB size and layout
> can be different. You can see differences of GigaDevice's chips in
> this patch.
> 
> So, the mt29f_spinand is not enough, it's designed only for
> Micron's chips.
A micron engineer put it like this:


" As far as I've seen from the datasheets I have available (SPI NAND
GigaDevice 1Gb/2Gb/4Gb, Micron 1Gb/2Gb/4Gb), the command sequencing
is the same for read/write/erase operations (read: enable ECC, read to cache,
wait, read from cache, check for errors, disable ECC; write: enable ECC,
write enable, program load, program execute, wait, verify, disable ECC;
erase: write enable, erase block, verify).

Regarding the stream of bytes for each command, the problematic
commands are the read from cache ones (read, fast read, read x2,
read x4, read dual read quad) that have different command format
(additional dummy bytes, a plane select bit to be set).
Other differences are in the structure of the protection and status registers
(some of them use more ECC and protection bits according to the size
of the chip). Also, each has a different ECC layout "

The funny thing is, that a micron engineer made a patch back in the day
that had support for both the MT29F and your GD5F with

>From the look of it, it seems easy to support the GD5F that way...

So much so, that "this unification habbit" was picked up by imgtec
for the pistachio!

Just look at this pull request from an ImgTec engineer titled:
"Add Imagination's Pistachio SoC and (Ci40) Marduk platform support" for
openwrt project:


Look at the 
target/linux/pistachio/patches-4.4/0001-mtd-nand-Introduce-SPI-NAND-framework.patch
commit message:

"5. mtd: spi-nand: Support common SPI NAND devices
This commit uses the recently introduced SPI NAND framework to support
Micron MT29F and Gigadevice GD5F serial NAND devices. These two families
of devices are fairly similar and so they are supported with only minimal
differences."

> The framework I chose from
> 
> 
> has two layers, one for generic nand operation and one for
> manufacturer-specific operations, such as the ecc status check.
> 
> I think this is a good practice.
Depends on how ar71xx will play out. For now, assume let's assume that
ar71xx is updated to 4.9. Then these patches would have to be moved to
either ar71xx's kernel patch directory: target/linux/ar71xx/patches-4.9
Or someone would have to *move* the existing 4.9 version out of 
target/linux/pistachio/patches-4.9 and into target/linux/generic/patches-4.9.
(Otherwise, quilt will complain because of the duplicated patches).

Regards,
Christian

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

Re: [LEDE-DEV] [PATCH] ar71xx: Add GRO support to ag71xx

[Christian Lamparter via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Sunday, September 3, 2017 11:35:46 AM CEST Rosen Penev wrote:
> On a TL-WN710N, this patch increases iperf performance from ~92.5 to ~93.5 
> mbps. Keep in mind the WN710N is a 100mbps device. I expect greater numbers 
> from gigabit devices.
> 
> Signed-off-by: Rosen Penev 
> ---
I've done a quick test of the patch on my WD Range Extender.
(It has a Atheros AR9344 rev 2 SoC @ CPU:560.000MHz, DDR:400.000MHz
The PHY is a AR8035, which supports 1 GBit/s Links)

The range extender (DUT) was running iperf3 server in both tests.
Another desktop PC was acting as the iperf3 client.

without the patch:

Connecting to host range-extender, port 5201
[  4] local 192.168.8.7 port 51518 connected to 192.168.8.204 port 5201
[ ID] Interval   Transfer Bandwidth   Retr  Cwnd
[  4]   0.00-1.00   sec  23.5 MBytes   197 Mbits/sec0105 KBytes
[  4]   1.00-2.00   sec  23.7 MBytes   199 Mbits/sec0105 KBytes
[  4]   2.00-3.00   sec  23.6 MBytes   198 Mbits/sec0105 KBytes
[  4]   3.00-4.00   sec  23.0 MBytes   193 Mbits/sec0105 KBytes
[  4]   4.00-5.00   sec  23.4 MBytes   197 Mbits/sec0105 KBytes
[  4]   5.00-6.00   sec  23.3 MBytes   195 Mbits/sec0105 KBytes
[  4]   6.00-7.00   sec  23.4 MBytes   196 Mbits/sec0105 KBytes
[  4]   7.00-8.00   sec  23.6 MBytes   198 Mbits/sec0105 KBytes
[  4]   8.00-9.00   sec  23.1 MBytes   194 Mbits/sec0105 KBytes
[  4]   9.00-10.00  sec  22.1 MBytes   185 Mbits/sec0105 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bandwidth   Retr
[  4]   0.00-10.00  sec   233 MBytes   195 Mbits/sec0 sender
[  4]   0.00-10.00  sec   232 MBytes   195 Mbits/sec  receiver

iperf Done.

with the patch (gro enabled - this is done by default):

Connecting to host range-extender, port 5201
[  4] local 192.168.8.7 port 52004 connected to 192.168.8.204 port 5201
[ ID] Interval   Transfer Bandwidth   Retr  Cwnd
[  4]   0.00-1.00   sec  32.7 MBytes   274 Mbits/sec0106 KBytes   
[  4]   1.00-2.00   sec  32.6 MBytes   274 Mbits/sec0106 KBytes   
[  4]   2.00-3.00   sec  32.4 MBytes   272 Mbits/sec0106 KBytes   
[  4]   3.00-4.00   sec  32.3 MBytes   271 Mbits/sec0106 KBytes   
[  4]   4.00-5.00   sec  32.5 MBytes   273 Mbits/sec0106 KBytes   
[  4]   5.00-6.00   sec  32.5 MBytes   273 Mbits/sec0106 KBytes   
[  4]   6.00-7.00   sec  32.6 MBytes   273 Mbits/sec0106 KBytes   
[  4]   7.00-8.00   sec  32.4 MBytes   272 Mbits/sec0106 KBytes   
[  4]   8.00-9.00   sec  32.6 MBytes   273 Mbits/sec0106 KBytes   
[  4]   9.00-10.00  sec  31.4 MBytes   264 Mbits/sec0106 KBytes   
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bandwidth   Retr
[  4]   0.00-10.00  sec   324 MBytes   272 Mbits/sec0 sender
[  4]   0.00-10.00  sec   324 MBytes   272 Mbits/sec  receiver

iperf Done.

(range-extender) # ethtool -K eth0 gro off

Connecting to host range-extender, port 5201
[  4] local 192.168.8.7 port 52120 connected to 192.168.8.204 port 5201
[ ID] Interval   Transfer Bandwidth   Retr  Cwnd
[  4]   0.00-1.00   sec  24.8 MBytes   208 Mbits/sec0105 KBytes   
[  4]   1.00-2.00   sec  23.6 MBytes   198 Mbits/sec0105 KBytes   
[  4]   2.00-3.00   sec  24.5 MBytes   206 Mbits/sec0105 KBytes   
[  4]   3.00-4.00   sec  23.9 MBytes   201 Mbits/sec0105 KBytes   
[  4]   4.00-5.00   sec  24.6 MBytes   207 Mbits/sec0105 KBytes   
[  4]   5.00-6.00   sec  24.7 MBytes   207 Mbits/sec0105 KBytes   
[  4]   6.00-7.00   sec  24.5 MBytes   206 Mbits/sec0105 KBytes   
[  4]   7.00-8.00   sec  24.0 MBytes   201 Mbits/sec0105 KBytes   
[  4]   8.00-9.00   sec  24.3 MBytes   204 Mbits/sec0105 KBytes   
[  4]   9.00-10.00  sec  24.5 MBytes   206 Mbits/sec0105 KBytes   
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bandwidth   Retr
[  4]   0.00-10.00  sec   244 MBytes   204 Mbits/sec0 sender
[  4]   0.00-10.00  sec   243 MBytes   204 Mbits/sec  receiver

iperf Done.

So, the throughput went from 195 Mbits/sec to 272 Mbits/sec.
The gain would be (272 Mbps - 195 Mbps) / 195 Mbps = 0.3949 ~ 40%

Regards,
Christian

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

Re: [LEDE-DEV] [PATCHv2 3/4] kernel/4.4: add generic spi-nand framework

[Christian Lamparter via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Sunday, September 3, 2017 1:43:59 PM CEST hackpascal wrote:
> From: Weijie Gao 
> 
> This patch adds generic SPI-NAND framework for linux-4.4.
> 
> Files come from patches of target pistachio, but have lots of modifications
> to add full support for GD5F series.
> 
> Signed-off-by: Weijie Gao 
> ---
Hm, from what I know multiple "generic" SPI-NAND driver/framework exist.

The current favourite of linux-mtd seems to be from Micron:

(Altought, development has sadly stalled as well ;( )


Is this correct? Or was there a recent attempt at upstreaming "this"
older framework too that I can't find?

Note:
The kernel had some support for spinand since v3.13 via the
staging "mt29f_spinand" driver. I had some success with it
on the RT-AC58U. All I needed there was to add a custom 
definition for the Winbond W25N01GV chip [0] and enable
CONFIG_MTD_SPINAND_MT29F=y
CONFIG_MTD_SPINAND_ONDIEECC=y

Maybe you too can get away with something similar to this?
Until linux-mtd _finally_ knows what they want to merge.

Regards,
Christian

[0] 


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

[LEDE-DEV] [PATCH] base-files: nand: use CI_KERNPART whenever the kernel volume is needed

[Christian Lamparter via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
This patch is in continuation of: commit 93aa86040523
"procd: nand: make it possible to configure kernel and ubi partition"

The $CI_KERNPART variable should be used in place
of the fixed "kernel" partition name. This allows
targets to specifiy alternate names for the kernel
partition.

Cc: Chris Blake <chrisrblak...@gmail.com>
Signed-off-by: Christian Lamparter <chunk...@googlemail.com>
---
 package/base-files/files/lib/upgrade/nand.sh | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/package/base-files/files/lib/upgrade/nand.sh 
b/package/base-files/files/lib/upgrade/nand.sh
index 894964e178..6b2bdba256 100644
--- a/package/base-files/files/lib/upgrade/nand.sh
+++ b/package/base-files/files/lib/upgrade/nand.sh
@@ -142,7 +142,7 @@ nand_upgrade_prepare_ubi() {
}
fi
 
-   local kern_ubivol="$( nand_find_volume $ubidev kernel )"
+   local kern_ubivol="$( nand_find_volume $ubidev $CI_KERNPART )"
local root_ubivol="$( nand_find_volume $ubidev rootfs )"
local data_ubivol="$( nand_find_volume $ubidev rootfs_data )"
 
@@ -157,13 +157,13 @@ nand_upgrade_prepare_ubi() {
fi
 
# kill volumes
-   [ "$kern_ubivol" ] && ubirmvol /dev/$ubidev -N kernel || true
+   [ "$kern_ubivol" ] && ubirmvol /dev/$ubidev -N $CI_KERNPART || true
[ "$root_ubivol" ] && ubirmvol /dev/$ubidev -N rootfs || true
[ "$data_ubivol" ] && ubirmvol /dev/$ubidev -N rootfs_data || true
 
# update kernel
if [ "$has_kernel" = "1" ]; then
-   if ! ubimkvol /dev/$ubidev -N kernel -s $kernel_length; then
+   if ! ubimkvol /dev/$ubidev -N $CI_KERNPART -s $kernel_length; 
then
echo "cannot create kernel volume"
return 1;
fi
@@ -270,7 +270,7 @@ nand_upgrade_tar() {
 
local ubidev="$( nand_find_ubi "$CI_UBIPART" )"
[ "$has_kernel" = "1" ] && {
-   local kern_ubivol="$(nand_find_volume $ubidev kernel)"
+   local kern_ubivol="$(nand_find_volume $ubidev $CI_KERNPART)"
tar xf $tar_file sysupgrade-$board_name/kernel -O | \
ubiupdatevol /dev/$kern_ubivol -s $kernel_length -
}
-- 
2.11.0


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

Re: [LEDE-DEV] [PATCH v2] ipq806x: Add support for ipq40xx AP-DK01.1-C1 and AP-DK04.1-C1

[Christian Lamparter via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Tuesday, May 23, 2017 12:41:41 PM CEST Ram Chandra Jangir wrote:
> On Freitag, Monday, May 22, 2017 7:22 PM Sven Eckelmann wrote:
> >On Freitag, 21. April 2017 00:25:37 CEST Ram Chandra Jangir wrote:
> > +@@ -419,18 +424,19 @@
> > +   status = "disabled";
> > +
> > +   gmac0: gmac0 {
> > +   local-mac-address = [00 00 00 00 00 00];
> > +-  vlan_tag = <1 0x1f>;
> > +-  };
> > +-
> > +-  gmac1: gmac1 {
> > +-  local-mac-address = [00 00 00 00 00 00];
> > +   qcom,phy_mdio_addr = <4>;
> > +   qcom,poll_required = <1>;
> > +   qcom,forced_speed = <1000>;
> > +   qcom,forced_duplex = <1>;
> > +   vlan_tag = <2 0x20>;
> > +   };
> > ++
> > ++  gmac1: gmac1 {
> > ++  local-mac-address = [00 00 00 00 00 00];
> > ++  qcom,poll_required_dynamic = <1>;
> > ++  vlan_tag = <1 0x1e>;
> > ++  };
> 
> >Why did you swap the gmac0 and gmac1 interface? I would guess that you have
> to fix the network setup for the other devices (qcom-ipq4019-rt-ac58u.dts,
> qcom- ipq4019-nbg6617.dts, qcom-ipq4019-fritz4040.dts) when you do that.
> 
> >Kind regards,
> > Sven
> 
> Thanks Sven,
> 
> Normally we configure gmac0 for  WAN group and gmac1 for  LAN group,
> existing ipq806x boards are also following the same, and we would like to
> continue with the  same convention. I do not see any reason to deviate this
> in ipq40xx based boards.
>
> I agree that ac58u nbg6617 and fritz4040 needs some changes, and Christian
> can help us to make the same.
No. I commented on this issue in v1 of this patch:


| For the record: eth1 IS NOT a separate MAC. From what I can tell, the
| essedma driver just maps different VLANs to multiple ethX instances. 
| So both eth0 and eth1 share the same PSGMII link to the QCA8075. 
| Therefore I suggest to let the kernel handle the VLAN and switch to:
|
|ucidef_add_switch "switch0" \
|"0@eth0" "1:lan" "2:lan" "3:lan" "4:lan" "5:wan"
|
|(the ucidef_set_interfaces_lan_wan gets removed)
|
|This will create eth0.1 and eth0.2 instead of eth0 and eth1.
|I've already tested this and made a patch:
|
| [@John, I think this should fix the weird VLAN issues you had with your box]
|(I'm waiting for AP devices with a AR8036 to see how they behave here)

There's no GMAC1/eth1. it's just a virtual construct in the
essedma driver that is not upstreamable. I think any time
spent on reassigning, renaming or rearranging these custom
properties: vlan_tags, phy-mdio-addr, ... is better spend elsewhere...
Like:
 - adding qca8075 support to the existing qca8k driver.
   From what I know John is looking into this.
 - writing a proper DSA driver for the internal ess-switch (1).
 - remove cruft from essedma and get everything upstream.

(1): Chris Blake picked up an Meraki MR33. The MR33 only has a
single PHY chip: QCA8033. It's PHY ID matches the ar8035 and it
is supported by the at803x driver.

However, he ran into a big issue with the current ar40xx.c code.
The internal ess-switch does not have a working autoneg for connected
single PHYs. Meraki solved this by polling the QCA8033's MII status
register and forcing the ess-switch's port to match its speed and 
duplex setting. This will need to be addressed as well!

Thanks,
Christian

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

Re: [LEDE-DEV] [PATCH] ipq806x: Add nand boot support for ipq40xx AP-DK04.1-C1

[Christian Lamparter via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hello Ram,

On Thursday, May 11, 2017 8:39:46 PM CEST Christian Lamparter wrote:
> On Thursday, May 11, 2017 10:15:58 PM CEST Ram Chandra Jangir wrote:
> > I added nand pinmux in https://patchwork.ozlabs.org/patch/761243/ ,
> > Could you please try with this, if it helps you.
> Thanks, I'll forward it to Chris Blake. He can test it once
> he returns. I'll let you know how it turned out.

Chris reported:
[1.40] nand: device found, Manufacturer ID: 0x01, Chip ID: 0xf1
[1.007580] nand: AMD/Spansion S34ML01G2
[1.014146] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB 
size: 64
[1.018135] 11 ofpart partitions found on MTD device qcom_nand.0
[1.025449] Creating 11 MTD partitions on "qcom_nand.0":

so, it's working now.

Regards,
Christian



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

Re: [LEDE-DEV] [PATCH] ipq806x: Add nand boot support for ipq40xx AP-DK04.1-C1

[Christian Lamparter via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hello Ram,

On Thursday, May 11, 2017 10:15:58 PM CEST Ram Chandra Jangir wrote:
> I added nand pinmux in https://patchwork.ozlabs.org/patch/761243/ ,
> Could you please try with this, if it helps you.
Thanks, I'll forward it to Chris Blake. He can test it once
he returns. I'll let you know how it turned out.

Regards,
Christian

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

Re: [LEDE-DEV] [PATCH] ipq806x: Add nand boot support for ipq40xx AP-DK04.1-C1

[Christian Lamparter via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hello,

On Friday, May 5, 2017 9:19:36 PM CEST Ram Chandra Jangir wrote:
> This change add nand boot support for IPQ40xx based
> AP-DK04.1-C1 board using ubi image, also add sysupgrage
> support for AP-DK04.1-C1 and generates a sysupgrade.tar
> image.
> 
> Testing:
> *Tested on IPQ40xx AP-DK04.1-C1 and IPQ806x AP148 Board:
>   a. NAND boot
>   b. ubi sysupgrade
> 
> Signed-off-by: Ram Chandra Jangir 

Thanks for posting this.

Chris Blake is currently in the process of adding the Cisco Meraki MR33.

The MR33 uses the IPQ4029 and has just a Spansion S34ML01G200TFV00 128MiB
NAND Flash for storage.

He reported that with this patch attached. The driver is loading, but it
can't access the nand: 

[0.860703] nand: second ID read did not match 7f,7f against 01,71
[0.861633] nand: No NAND device found

The id is supposed to be 01 (manuf = Spanion), f1 (128MiB).
both readings are bad.

I think this is caused by two problems:

1. 7f, 7f should be 0xff, 0xff. 0x71 should be 0xf1.

2. It seems that the NAND chip was not ready on the first read. 

I strongly suspect (due to the MSB error for BIT 7), that
at least one I/O line is missing due to a bad pinctrl/mux
setup.

Could you please add the pinctrl nand definitions to
the dts so he can test again?

Regards,
Christian

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

Re: [LEDE-DEV] [PATCH 2/2] ipq806x: Add support for ipq40xx subtarget

[Christian Lamparter via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hello Ram,

On Monday, April 17, 2017 11:13:11 PM CEST Ram Chandra Jangir wrote:
> > diff --git a/target/linux/ipq806x/Makefile 
> > b/target/linux/ipq806x/Makefile index 5a5551c..b5b36e1 100644
> > --- a/target/linux/ipq806x/Makefile
> > +++ b/target/linux/ipq806x/Makefile
> > @@ -21,7 +21,7 @@ DEFAULT_PACKAGES += \
> > kmod-ata-core kmod-ata-ahci kmod-ata-ahci-platform \
> > kmod-usb-core kmod-usb-ohci kmod-usb2 kmod-usb-ledtrig-usbport \
> > kmod-usb3 kmod-usb-dwc3-of-simple kmod-usb-phy-qcom-dwc3 \
> > -   kmod-ath10k wpad-mini \
> > +   kmod-ath10k wpad-mini kmod-switch-ar40xx kmod-ipq40xx-edma \
> 
> >>the switch and edma driver are already part of the default image.
> >>Why do you want to have them as separate packages?
> [Ram]: It is good to have enabled them as module instead of inbuilt,
> Theoretically ar40xx switch depends on swconfig module which is 
> enabled as kmod only.
I fail to see why this would be good idea. Can you please explain in !detail!
why having this as an external module would be advantageous. As for why not:
The kmod-swconfig module does not set SWCONFIG_LEDS. This will break the LAN
LED on the Fritz!Box 4040.

> > diff --git 
> > a/target/linux/ipq806x/patches-4.9/852-ipq4019-pinctrl-Updated-various
> > -Pin-definitions.patch 
> > b/target/linux/ipq806x/patches-4.9/852-ipq4019-pinctrl-Updated-various
> > -Pin-definitions.patch
> > new file mode 100644
> > index 000..4267d47
> > --- /dev/null
> > +++ b/target/linux/ipq806x/patches-4.9/852-ipq4019-pinctrl-Updated-var
> > +++ ious-Pin-definitions.patch
> > @@ -0,0 +1,1332 @@
> > +From fc6cf61517b8b4ab4678659936fc7572f699d6e7 Mon Sep 17 00:00:00 
> > +2001
> > +From: Ram Chandra Jangir 
> > +Date: Tue, 28 Mar 2017 14:00:00 +0530
> > +Subject: [PATCH] ipq4019: pinctrl: Updated various Pin definitions
> > +
> > +Populate default values for various GPIO functions
> > +
> > +Signed-off-by: Ram Chandra Jangir 
> >Please send this upstream to linux-g...@vger.kernel.org.
> >I'm saying this because it has become nearly impossible to merge this stuff
> into the kernel without the right domain in the email-address.
>  [Ram]: it will be upstreamed soon.

There were a bunch of comments for the original submission to linux-gpio.
Please check them out: 
before you submit this again. Because from what I can tell, the original
issues in v2 did not get addressed in this version. 
(i.e.: owner parameter. see Bjorn's comment about the platform driver.)

> > +@@ -122,11 +123,60 @@ static int ipq40xx_mdio_write(struct mii_bus *bus,
> int mii_id, int regnum,
> > +   return 0;
> > + }
> > +
> > ++static int ipq40xx_phy_reset(struct platform_device *pdev) {
> > ++  struct device_node *mdio_node;
> > ++  int phy_reset_gpio_number;
> > ++  int ret;
> > ++
> > ++  mdio_node = of_find_node_by_name(NULL, "mdio");
> > ++  if (!mdio_node) {
> > ++  dev_err(>dev, "Could not find mdio node\n");
> > ++  return -ENOENT;
> > ++  }
> > ++
> > ++  ret = of_get_named_gpio(mdio_node, "phy-reset-gpio", 0);
> > ++  if (ret < 0) {
> > ++  dev_err(>dev, "Could not find phy-reset-gpio\n");
> > ++  return ret;
> >This could break existing configurations. Please add a check that would
> skip the error in case the "phy-reset-gpio" property isn't available.
> [Ram]: This is required to reset via gpio, will skip if this property is not
> available/defined in next patch version.
One thing, can you ask around what would happen if the PHY is resetted on a
device powered by PoE? I know that this is an issue with a Meraki MR18 
(AR71XX with AR8035) when it is powered by PoE Alternative B. In this
case, the MR18 will simply fail to boot, because once the PHY reset GPIO
is asserted it just restarts due to the "sudden" loss of power.

> > diff --git 
> > a/target/linux/ipq806x/patches-4.9/858-arm-dts-Add-ess-switch-device-f
> > or-IPQ4019.patch 
> > b/target/linux/ipq806x/patches-4.9/858-arm-dts-Add-ess-switch-device-f
> > or-IPQ4019.patch
> > new file mode 100644
> > index 000..4598451
> > --- /dev/null
> > +++ b/target/linux/ipq806x/patches-4.9/858-arm-dts-Add-ess-switch-devi
> > +++ ce-for-IPQ4019.patch
> > @@ -0,0 +1,486 @@
> > +From 4842020af3b39ce8c7c9a92de106d8fffd92b7c0 Mon Sep 17 00:00:00 
> > +2001
> > +From: Ram Chandra Jangir 
> > +Date: Tue, 28 Mar 2017 14:00:00 +0530
> > +Subject: [PATCH] arm: dts: Add ess switch device for IPQ4019
> > +
> > +- Update ipq4019 dts nodes for mdio interface, ess-switch
> > +   and edma driver.
> > +- Update dt documentation for qca-ess ethernet subsystem
> > +
> > +Signed-off-by: xiaofeis 
> 

Re: [LEDE-DEV] [PATCH 2/2] ipq806x: Add support for ipq40xx subtarget

[Christian Lamparter via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Thursday, April 13, 2017 8:40:30 PM CEST Ram Chandra Jangir wrote:
> This change adds QCA IPQ40xx SoC based board support
> 
> Supported IPQ40xx boards:
>  - AP-DK01.1-C1 and AP-DK04.1-C1 with nor flash boot.
This is Great. There are several users which are waiting for DK04.

On is the Compex WPJ428. There are several remaining issues with it:
- The USB 3.0 does not work on his board and is downgraded to USB 2.0.
It's working on the FB4040 and RT-AC58U though.

This is what the user sees on the WPJ428:
[   30.614478] usb 1-1: new high-speed USB device number 3 using 
xhci-hcd
[   31.356496] xhci-hcd xhci-hcd.0.auto: Cannot set link state.
[   31.357151] usb usb2-port1: cannot disable (err = -32)

Can you please check the usb port functionality on your board too?

- the board fails to reboot / restart.
The WPJ428 LEDE-Image will just freeze. The FB4040 and RT-AC58U doesn't
have no issue though and neither does the Stock Image. Can you please
check, if this is working with your image?

> ---
> diff --git a/target/linux/ipq806x/Makefile b/target/linux/ipq806x/Makefile
> index 5a5551c..b5b36e1 100644
> --- a/target/linux/ipq806x/Makefile
> +++ b/target/linux/ipq806x/Makefile
> @@ -21,7 +21,7 @@ DEFAULT_PACKAGES += \
>   kmod-ata-core kmod-ata-ahci kmod-ata-ahci-platform \
>   kmod-usb-core kmod-usb-ohci kmod-usb2 kmod-usb-ledtrig-usbport \
>   kmod-usb3 kmod-usb-dwc3-of-simple kmod-usb-phy-qcom-dwc3 \
> - kmod-ath10k wpad-mini \
> + kmod-ath10k wpad-mini kmod-switch-ar40xx kmod-ipq40xx-edma \
the switch and edma driver are already part of the default image.
Why do you want to have them as separate packages?

> diff --git a/target/linux/ipq806x/base-files/etc/board.d/02_network 
> b/target/linux/ipq806x/base-files/etc/board.d/02_network
> index 36e0fb3..082105a 100755
> --- a/target/linux/ipq806x/base-files/etc/board.d/02_network
> +++ b/target/linux/ipq806x/base-files/etc/board.d/02_network
> @@ -48,6 +48,12 @@ nbg6817)
>   ucidef_set_interface_macaddr "lan" "$hw_mac_addr"
>   ucidef_set_interface_macaddr "wan" "$(macaddr_add $hw_mac_addr 1)"
>   ;;
> +ap-dk01.1-c1|\
> +ap-dk04.1-c1)
> + ucidef_set_interfaces_lan_wan "eth1" "eth0"
> + ucidef_add_switch "switch0" \
> + "0t@eth1" "1:lan" "2:lan" "3:lan" "4:lan"
> + ;;

For the record: eth1 IS NOT a separate MAC. From what I can tell, the
essedma driver just maps different VLANs to multiple ethX instances. 
So both eth0 and eth1 share the same PSGMII link to the QCA8075. 
Therefore I suggest to let the kernel handle the VLAN and switch to:

ucidef_add_switch "switch0" \
"0@eth0" "1:lan" "2:lan" "3:lan" "4:lan" "5:wan"

(the ucidef_set_interfaces_lan_wan gets removed)

This will create eth0.1 and eth0.2 instead of eth0 and eth1.
I've already tested this and made a patch:

[@John, I think this should fix the weird VLAN issues you had with your box]
(I'm waiting for AP devices with a AR8036 to see how they behave here)
> diff --git 
> a/target/linux/ipq806x/patches-4.9/851-dts-ipq40xx-Add-support-for-spi-nor-32-MB-flash-and-.patch
>  
> b/target/linux/ipq806x/patches-4.9/851-dts-ipq40xx-Add-support-for-spi-nor-32-MB-flash-and-.patch
> new file mode 100644
> index 000..5753f10
> --- /dev/null
> +++ 
> b/target/linux/ipq806x/patches-4.9/851-dts-ipq40xx-Add-support-for-spi-nor-32-MB-flash-and-.patch
> @@ -0,0 +1,111 @@
> +From 5f07811771ad92a3413248a240eaedfee09ace93 Mon Sep 17 00:00:00 2001
> +From: Ram Chandra Jangir 
> +Date: Fri, 24 Mar 2017 14:00:00 +0530
> +Subject: [PATCH] dts: ipq40xx: Add support for spi nor 32 MB flash and enable
> + wifi support
> +
> +- Add micron n25q128a11 spi nor 32MB flash and fixes spi nodes
> +  to work on DK01 and DK04 boards.
> +- Add support for default SPI configuration
> +- Enable and fixed WiFi nodes to work with DK boards
> +
> +Signed-off-by: Ram Chandra Jangir 
> +---
> +[...]
> +diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi 
> b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
> +index 768a2a4..2a5cc5e 100644
> +--- a/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
>  b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
> +@@ -81,13 +81,16 @@
> + pinctrl-names = "default";
> + status = "ok";
> + cs-gpios = < 54 0>;
> ++num-cs = <1>;
> +
> +-mx25l25635e@0 {
> ++m25p80@0 {
There are already boards that use the mx25l25635e property.
Please, just add a separate property for the generic "m25p80" and set
its 

Re: [LEDE-DEV] ARM64 platform updates

[Christian Lamparter via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hello,

On Tuesday, April 11, 2017 12:13:42 PM CEST Florian Fainelli wrote:
> I am planning on switch the arm64 multiplatform target to 4.9 and remove
> support for the ARM Foundation v8 model since QEMU is just nicer.
> 
> Any objections?
> 
No objections per se. But since you are already updating the arm64 target,
why not also do the same to armvirt? After all, both are mostly virtual 
targets and from what I can tell, it's just ARMv8 vs ARMv7
(or maybe can these be folded into one?)

Regards,
Christian

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

Re: [LEDE-DEV] Using stable wireless/kernel but trunk userspace/kernel

[Christian Lamparter via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hello,

On Tuesday, April 4, 2017 8:14:58 PM CEST Daniel Dickinson wrote:
> I'm wondering if there is an easy way to use trunk userspace with the stable
> release's wireless (and if necessary the rest of the kernel). 

At the end of last year, I had issues with getting ath10k to work with
the new IPQ4019. And I wanted to know if the was due to LEDE's patched
mac80211 or if this was problem in the mainline as well.

The attached patch allowed me to use the ath10k from the kernel
source to boot up the ath10k device. But as you can see, there 
were quite a few things that needed to be modified in order to
do it this way (Is there a better one?).

In any case, If you want to adapt it, I think you would have to
add a kmod-net-ath9k package (see mac80211-package's kmod-ath9k)
to it and do a few modifications to the AR71XX kernel config.
Have Fun!

(I hope patchwork doesn't pick this up. If it does, please delete it there.)
---
diff --git a/package/kernel/linux/modules/wireless.mk 
b/package/kernel/linux/modules/wireless.mk
index 7b1c663567..826b027134 100644
--- a/package/kernel/linux/modules/wireless.mk
+++ b/package/kernel/linux/modules/wireless.mk
@@ -62,3 +62,88 @@ define KernelPackage/owl-loader/description
 endef
 
 $(eval $(call KernelPackage,owl-loader))
+
+define KernelPackage/net-mac80211/Default
+  SUBMENU:=$(WIRELESS_MENU)
+  URL:=https://wireless.wiki.kernel.org/
+endef
+
+define KernelPackage/net-cfg80211
+  $(call KernelPackage/net-mac80211/Default)
+  TITLE:=cfg80211 - wireless configuration API
+  DEPENDS+= +iw
+  FILES:= $(LINUX_DIR)/net/wireless/cfg80211.ko
+  KCONFIG:=CONFIG_CFG80211 \
+  CONFIG_CFG80211_INTERNAL_REGDB=y \
+  CONFIG_NL80211_TESTMODE=y \
+  CONFIG_CFG80211_DEBUGFS=y \
+  CONFIG_CFG80211_CRDA_SUPPORT=y
+endef
+
+define KernelPackage/net-cfg80211/description
+cfg80211 is the Linux wireless LAN (802.11) configuration API.
+endef
+
+$(eval $(call KernelPackage,net-cfg80211))
+
+define KernelPackage/net-mac80211
+  $(call KernelPackage/net-mac80211/Default)
+  TITLE:=Linux 802.11 Wireless Networking Stack
+  DEPENDS+= +kmod-net-cfg80211 +hostapd-common +kmod-crypto-aead
+  FILES:= $(LINUX_DIR)/net/mac80211/mac80211.ko
+  MENU:=1
+  KCONFIG:=CONFIG_MAC80211 \
+  CONFIG_MAC80211_RC_MINSTREL=y \
+  CONFIG_MAC80211_RC_MINSTREL_HT=y \
+  CONFIG_MAC80211_RC_MINSTREL_VHT=y \
+  CONFIG_MAC80211_MESH=y \
+  CONFIG_MAC80211_LEDS=y \
+  CONFIG_MAC80211_DEBUGFS=y
+endef
+
+define KernelPackage/net-mac80211/description
+Generic IEEE 802.11 Networking Stack (mac80211)
+endef
+
+$(eval $(call KernelPackage,net-mac80211))
+
+define KernelPackage/net-ath
+  $(call KernelPackage/net-mac80211/Default)
+  TITLE:=Atheros common driver part
+  DEPENDS+= @PCI_SUPPORT||USB_SUPPORT||TARGET_ipq40xx +kmod-net-mac80211
+  FILES:=$(LINUX_DIR)/drivers/net/wireless/ath/ath.ko
+  KCONFIG:=CONFIG_ATH_COMMON
+  MENU:=1
+endef
+
+define KernelPackage/net-ath/description
+ This module contains some common parts needed by Atheros Wireless drivers.
+endef
+
+$(eval $(call KernelPackage,net-ath))
+
+define KernelPackage/net-ath10k
+  $(call KernelPackage/net-mac80211/Default)
+  TITLE:=Atheros 802.11ac wireless cards support
+  URL:=https://wireless.wiki.kernel.org/en/users/Drivers/ath10k
+  KCONFIG:=CONFIG_ATH10K \
+  CONFIG_ATH10K_PCI \
+  CONFIG_ATH10K_AHB=y \
+  CONFIG_ATH10K_DEBUG=y \
+  CONFIG_ATH10K_DEBUGFS=y \
+  CONFIG_ATH10K_TRACING=y
+  DEPENDS+= @PCI_SUPPORT +kmod-net-ath +@DRIVER_11N_SUPPORT 
+@DRIVER_11W_SUPPORT +@KERNEL_RELAY
+  FILES:= \
+$(LINUX_DIR)/drivers/net/wireless/ath/ath10k/ath10k_core.ko \
+$(LINUX_DIR)/drivers/net/wireless/ath/ath10k/ath10k_pci.ko
+  AUTOLOAD:=$(call AutoLoad,55,ath10k_core ath10k_pci)
+endef
+
+define KernelPackage/net-ath10k/description
+This module adds support for wireless adapters based on
+Atheros IEEE 802.11ac family of chipsets. For now only
+PCI is supported.
+endef
+
+$(eval $(call KernelPackage,net-ath10k))
+
diff --git a/package/network/services/hostapd/Makefile 
b/package/network/services/hostapd/Makefile
index 9570b2a8f5..b228a91950 100644
--- a/package/network/services/hostapd/Makefile
+++ b/package/network/services/hostapd/Makefile
@@ -25,8 +25,8 @@ PKG_BUILD_PARALLEL:=1
 
 PKG_CONFIG_DEPENDS:= \
CONFIG_WPA_SUPPLICANT_NO_TIMESTAMP_CHECK \
-   CONFIG_PACKAGE_kmod-ath9k \
-   CONFIG_PACKAGE_kmod-cfg80211 \
+   CONFIG_PACKAGE_kmod-net-ath9k \
+   CONFIG_PACKAGE_kmod-net-cfg80211 \
CONFIG_PACKAGE_hostapd \
CONFIG_PACKAGE_hostapd-mini \
CONFIG_WPA_RFKILL_SUPPORT \
@@ -63,8 +63,8 @@ ifneq ($(CONFIG_DRIVER_11N_SUPPORT),)
 

Re: [LEDE-DEV] QCA Dakota support

[Christian Lamparter via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Friday, February 17, 2017 4:29:51 PM CET John Crispin wrote:
> On 17/02/2017 15:46, Christian Lamparter wrote:
> > On Monday, October 31, 2016 10:38:18 PM CET Christian Mehlis wrote:
> >> Hi,
> >>
> >> is there someone working on QCA Dakota support for lede?
> > Heads-up!
> > 
> > <https://git.lede-project.org/?p=source.git;a=commit;h=bb255f74290d889b65a563bac7a4be0427fdbec8>
> > 
> > John has silently integrated Matthew McClintock's patches
> > for the ipq40xx platform into the ipq806x target.
> > 
> > John: Do you have plan for a IPQ40xx subtarget? And what's the plan
> > for the essedma (ethernet), ar40xx/qca8075 (switch),
> > qca-adhoc-bus, scm, ... drivers?
> > 
> > Regards,
> > Christian
> > 
> 
> yes, we are currently fixing support for missing patches.
> dissent1 is working on this.
That's great. Last time I talk to   dissent1 about ath10k
related stuff, he got very defensive. I presume, he had
already plans for his own implementation. 
(That's fine too.)

> there will be a dakota subtarget, i have a ap145 (?)
> reference board on my desk.
Pavel/dissent1, do a you have a public repository with the
subtarget and the rest of the patches and fixes ready?
Because I would like to move the Fritz!Box 4040 there.
I haven't seen any message on the forum/wiki/ML/github, so
where are these updates posted? Or is the plan that it will
just be added to the repository like the platform support
without any change of a discussion?

Regards,
Christian

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

[LEDE-DEV] [PATCH v1 1/3] mac80211: make relay support depend on ATH_DEBUG

[Christian Lamparter via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
both ath9k and ath10k use the kernel's relay framework
to pass spectral data to userspace. However, both drivers
only have this option enabled if the driver's debugfs
option is enabled as well.

In case of ath10k_*, the relayfs dependency can be moved
to the config ATH_DEBUG symbol.

ath9k needed more work. A patch to the ath9k driver was
added to detangle RELAY and DEBUG_FS:
"ath9k: move RELAY and DEBUG_FS to ATH9K[_HTC]_DEBUGFS"
<https://patchwork.kernel.org/patch/9501361/>.

NB: CONFIG_PACKAGE_MAC80211_DEBUGFS needs to be disabled to
notice the change.

Signed-off-by: Christian Lamparter <chunk...@googlemail.com>
---
Here are some numbers for my WD Range Extender (AR7370 with a AR9300):
For both configurations MAC80211_DEBUGFS and ATH_DEBUG is disabled.
(if they are enabled, there should be no change). All sizes are in
bytes. And I only test with or without the patch applied.

module | file size | .text size |
ath9k_common.ko (w/o)  | 32208 |  12832 |
ath9k_common.ko (with) | 12204 |   3456 |

Note: The kernel with the patch, doesn't need RELAY support anymore.
Therefore it shrinks a bit as well.

  | lzma uimage size | .text size |
4.4 kernel (w/o)  |  1181777 |3004592 |
4.4 kernel (with) |  1179666 |2999448 |

If anyone wants to play with it, I made a test-patch For LEDE [0].
Just remember to disable CONFIG_PACKAGE_MAC80211_DEBUGFS and
CONFIG_PACKAGE_ATH_DEBUG.

The main motivation was that relayfs can be very costly on the RAM
as well (on ath10k in can eat like 4MiB per device with VM debugging
etc...).
---
 package/kernel/mac80211/Makefile | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/package/kernel/mac80211/Makefile b/package/kernel/mac80211/Makefile
index 5a591e4b83..cb709c85d2 100644
--- a/package/kernel/mac80211/Makefile
+++ b/package/kernel/mac80211/Makefile
@@ -173,6 +173,7 @@ define KernelPackage/ath/config
 
config PACKAGE_ATH_DEBUG
bool "Atheros wireless debugging"
+   select KERNEL_RELAY
help
  Say Y, if you want to debug atheros wireless drivers.
  Only ath9k & ath10k make use of this.
@@ -220,7 +221,7 @@ define KernelPackage/ath9k-common
   TITLE:=Atheros 802.11n wireless devices (common code for ath9k and ath9k_htc)
   URL:=https://wireless.wiki.kernel.org/en/users/drivers/ath9k
   HIDDEN:=1
-  DEPENDS+= @PCI_SUPPORT||USB_SUPPORT||TARGET_ar71xx +kmod-ath 
+@DRIVER_11N_SUPPORT +@DRIVER_11W_SUPPORT +@KERNEL_RELAY
+  DEPENDS+= @PCI_SUPPORT||USB_SUPPORT||TARGET_ar71xx +kmod-ath 
+@DRIVER_11N_SUPPORT +@DRIVER_11W_SUPPORT
   FILES:= \
$(PKG_BUILD_DIR)/drivers/net/wireless/ath/ath9k/ath9k_common.ko \
$(PKG_BUILD_DIR)/drivers/net/wireless/ath/ath9k/ath9k_hw.ko
@@ -277,7 +278,7 @@ define KernelPackage/ath10k
   $(call KernelPackage/mac80211/Default)
   TITLE:=Atheros 802.11ac wireless cards support
   URL:=https://wireless.wiki.kernel.org/en/users/Drivers/ath10k
-  DEPENDS+= @PCI_SUPPORT +kmod-ath +@DRIVER_11N_SUPPORT +@DRIVER_11AC_SUPPORT 
+@DRIVER_11W_SUPPORT +@KERNEL_RELAY
+  DEPENDS+= @PCI_SUPPORT +kmod-ath +@DRIVER_11N_SUPPORT +@DRIVER_11AC_SUPPORT 
+@DRIVER_11W_SUPPORT
   FILES:= \
$(PKG_BUILD_DIR)/drivers/net/wireless/ath/ath10k/ath10k_core.ko \
$(PKG_BUILD_DIR)/drivers/net/wireless/ath/ath10k/ath10k_pci.ko
@@ -1476,9 +1477,6 @@ ifdef CONFIG_PACKAGE_MAC80211_DEBUGFS
   config-y += \
CFG80211_DEBUGFS \
MAC80211_DEBUGFS \
-   ATH9K_DEBUGFS \
-   ATH9K_HTC_DEBUGFS \
-   ATH10K_DEBUGFS \
CARL9170_DEBUGFS \
ATH5K_DEBUG
 endif
@@ -1498,7 +1496,7 @@ config-$(call config_package,lib80211) += LIB80211 
LIB80211_CRYPT_WEP LIB80211_C
 config-$(call config_package,airo) += AIRO
 
 config-$(call config_package,ath) += ATH_CARDS ATH_COMMON
-config-$(CONFIG_PACKAGE_ATH_DEBUG) += ATH_DEBUG ATH10K_DEBUG 
ATH9K_STATION_STATISTICS
+config-$(CONFIG_PACKAGE_ATH_DEBUG) += ATH_DEBUG ATH10K_DEBUG ATH9K_DEBUGFS 
ATH9K_HTC_DEBUGFS ATH9K_STATION_STATISTICS
 config-$(CONFIG_PACKAGE_ATH_DFS) += ATH9K_DFS_CERTIFIED ATH10K_DFS_CERTIFIED
 
 config-$(call config_package,ath9k) += ATH9K
-- 
2.11.0


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

Re: [LEDE-DEV] [PATCH] iperf3: update to version 3.1.5 and download via git

[Christian Lamparter via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Monday, January 30, 2017 6:48:09 AM CET Dave Täht wrote:
> Could you verify this version has a working -S Qos option? 
no, not as efficiently as you could. the commit log is c
from the release tag.

> It took it, but didn't actually set it in the packets, misleading
> a lot of people.
> 
> There's a pull request on github outstanding to improve, that adding a
> dscp option
> 
> See also:
> 
> http://burntchrome.blogspot.com/2016/09/iperf3-and-microbursts.html
> 
> I think the patches for that were only partially taken up.
Well, since you are an expert on this, wouldn't you agree that you
could verify, make and post the patches for this feature quicker?

I'm mostly interested in iperf3 as an easy-to-install-and-run-anywhere
tool. It can make drivers crash and hardware misbehave and for this
purpose it works fine.

Regards,
Christian

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

Re: [LEDE-DEV] [PATCH] iperf3: update to version 3.1.5 and download via git

[Christian Lamparter via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hello,

On Monday, January 30, 2017 12:43:40 PM CET Daniel Engberg wrote:
> On 2017-01-15 22:06, Daniel Engberg wrote:
> > On 2017-01-15 21:56, Christian Lamparter wrote:
> >> On Sunday, January 15, 2017 9:25:28 PM CET Daniel Engberg wrote:
> >>> Thanks for submitting a patch but can you please outline why we would
> >>> want to switch from a tarball release to a git repo pull for iperf3?
> >>> 
> >> 
> >> Actually, it's in the commit. It saves a couple of KiB since we can 
> >> switch to
> >> xz along the way too. As for iperf 3.1.5 this is:
> >> 
> >> 550862 Bytes for iperf-3.1.5.tar.gz
> >> 
> >> vs.
> >> 
> >> 400468 Bytes for 
> >> iperf-3.1.5-a46d5aec9726e196e86ab192c3f77dea6a3beb8e.tar.xz
> >> 
> >> That's around 27% savings of bandwidth. Because once it's uploaded
> >> onto the mirror
> >> the download methods will pick it from there - instead of the listed 
> >> address.
> >> 
> >> Anyway, if you have your own idea of how to do it: Then just make a
> >> patch as well.
> >> 
> >> Regards,
> >> Christian
> > 
> > I'm all for saving space and bandwidth but as far as I know the common
> > practice is to use tarballs where it makes sense (ie pretty much
> > everywhere) and upstream download mirrors/sites. Directing all users
> > to the LEDE "backup" mirror is not a desirable outcome as there's no
> > official xz package. That's just my point of view.
> > 
> > Regards,
> > Daniel Engberg
> I just wanted to information you (as asked by mkresin) that I've 
> submitted a pr on GitHub 
> (https://github.com/lede-project/source/pull/755) that uses the release 
> tarball which is considered to be the preferred way for this package.

Let's hope so :).

> Something completely different, great work on the ipq4xx stuff. Any 
> plans on upstreaming it?
Depends. Most of / all the platform code and the important drivers would
need to be upstream. As far as I can tell, there's little progress on the
ipq40xx. It's rotting since Matthew McClintock left QCA. Maybe it will
pick up a bit once the devices are getting more common... But people might
as well just skip it (for 2.5G/5G and VHT160).

The apm821xx was way easier to add. As it had full kernel support from
the get go and the big DMA and SATA patches were all backports.

Regards,
Christian

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

[LEDE-DEV] [PATCH] kmodloader: fix out-of-order module loading

[Christian Lamparter via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Currently, kmodloader is trying to load all modules during
boot. This is because all the modules (and not just those
which start with a number) are set to probe.

Signed-off-by: Christian Lamparter <chunk...@googlemail.com>
---
The load_modprobe() seems to be necessary, since I've also hit
a hang with 4.9 caused by nf_nat_ipv6.ko. This is because it
calls request_module for nf_conntrack_ipv6. So the order in
the /etc/modprobe.d/ files is still important.

I have the following options enabled:

CONFIG_PACKAGE_kmod-ip6tables-extra=y
CONFIG_PACKAGE_kmod-ipt-conntrack-extra=y
CONFIG_PACKAGE_kmod-ipt-ipsec=y
CONFIG_PACKAGE_kmod-ipt-nat-extra=y
CONFIG_PACKAGE_kmod-ipt-nat6=y

I fixed this by adding nf_conntrack_ipv6 to NF_CONNTRACK6
in modules/netfilter.mk. No idea if this is also a problem
on 4.4 or not.
---
 kmodloader.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/kmodloader.c b/kmodloader.c
index 729027a..bf8c36c 100644
--- a/kmodloader.c
+++ b/kmodloader.c
@@ -933,10 +933,11 @@ static int main_loader(int argc, char **argv)
 
if (opts)
m->opts = strdup(opts);
-   m->state = PROBE;
-   if (basename(gl.gl_pathv[j])[0] - '0' <= 9)
-   load_modprobe();
 
+   if (basename(gl.gl_pathv[j])[0] - '0' <= 9) {
+   m->state = PROBE;
+   load_modprobe();
+   }
}
free(mod);
fclose(fp);
-- 
2.11.0


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

Re: [LEDE-DEV] [RFC] [PULL REQUEST] rt2x00 patches from OpenWrt.org

[Christian Lamparter via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Friday, January 13, 2017 4:46:30 PM CET Daniel Golle wrote:
> On Fri, Jan 13, 2017 at 12:46:56PM +0200, Kalle Valo wrote:
> > Daniel Golle  writes:
> > > ...
> > > Please review and comment, so we can get those patches merged!
> > 
> > No pull requests, please. Instead send these as patches, easier to
> > review and actually also easier for me to merge.
> 
> The advantage of pull requests is that author information can be
> preserved more easily. Running git format-patch results in most patches
> having wrong SMTP sender information due to the assumption that the
> patch author is the same person also submitting the patch.
> So in practise, this would either require changing the From: (and thus
> Author) to myself or having most mails eaten by anti-spam measures due
> to non-matching SPF which prohibits my SMTP to send mail on behalf of
> the original authors of the patches.
> 
> How do you suggest to handle this situation?
> 
>From what I know, git format-patch and send-email [0] will add a second
FROM: in the email's body with the author of the commit automatically
(if author isn't you). This is what it did, when I posted the apm821xx
patches on lede-dev [1] (Look at the additional "FROM: Chris Blake ..."
line in these patches. Whereas the mail came from my address).

The MTA (MDA, ...) will use the first FROM: (your address) whereas git will
use the FROM in the mail body (so the patch will be correctly attributed to
the original patch author). If you don't want to bother the original
authors, you can look at the --suppress-cc=author option and enable --dry-run
on git send-email.

I would say, just give it a "dry".
(Sadly, I didn't find any documentation for this feature.
But I know it worked back then and it should be fine with SPF.)

Regards,
Christian

[0] 
[1] 

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

Re: [LEDE-DEV] [PATCH] iperf3: update to version 3.1.5 and download via git

[Christian Lamparter via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Sunday, January 15, 2017 9:25:28 PM CET Daniel Engberg wrote:
> Thanks for submitting a patch but can you please outline why we would
> want to switch from a tarball release to a git repo pull for iperf3?
>

Actually, it's in the commit. It saves a couple of KiB since we can switch to
xz along the way too. As for iperf 3.1.5 this is:

550862 Bytes for iperf-3.1.5.tar.gz

vs.

400468 Bytes for iperf-3.1.5-a46d5aec9726e196e86ab192c3f77dea6a3beb8e.tar.xz

That's around 27% savings of bandwidth. Because once it's uploaded
onto the mirror
the download methods will pick it from there - instead of the listed address.

Anyway, if you have your own idea of how to do it: Then just make a
patch as well.

Regards,
Christian

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

[LEDE-DEV] [PATCH] iperf3: update to version 3.1.5 and download via git

[Christian Lamparter via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
"This version of iperf3 makes some improvements to the
fair-queue-based pacing and improves the selection of
the default UDP packet size. Users who use either of
these aspects of iperf3 are encourage to review the
release notes for this version."
<http://software.es.net/iperf/news.html#iperf-3-1-5-released>

This patch also changes the package to download the
source via github <https://github.com/esnet/iperf>.
This also allows to switch to xz and save a couple of
KiB on the mirrors for every new release.

Signed-off-by: Christian Lamparter <chunk...@googlemail.com>
---
Alternatively, the project's homepage also provides a
iperf-3.1.5.tar.gz <http://downloads.es.net/pub/iperf>.
In this case all that needs to be updated is
PKG_VERSION:=3.1.5
PKG_HASH:=6e1a6200cd38baeab58ef0d7b8769e7aa6410c3a3168e65ea8277a4de79e5500
---
 package/network/utils/iperf3/Makefile | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/package/network/utils/iperf3/Makefile 
b/package/network/utils/iperf3/Makefile
index 56782ea520..72fa4e3bff 100644
--- a/package/network/utils/iperf3/Makefile
+++ b/package/network/utils/iperf3/Makefile
@@ -8,12 +8,14 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=iperf
-PKG_VERSION:=3.1.4
+PKG_VERSION:=3.1.5
 PKG_RELEASE:=1
 
-PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
-PKG_SOURCE_URL:=http://downloads.es.net/pub/iperf
-PKG_HASH:=db61d70ac62003ebe0bf15496bd8c4b3c4b728578a44d0a1a88fcf8afc0e8f76
+PKG_SOURCE_PROTO:=git
+PKG_SOURCE_URL:=https://github.com/esnet/iperf.git
+PKG_SOURCE_VERSION:=a46d5aec9726e196e86ab192c3f77dea6a3beb8e
+PKG_MIRROR_HASH:=ebcbde749e02a437bc829163735ac0ce13c50594ad6e3728c0b5e006bb34f3f7
+PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.xz
 
 PKG_MAINTAINER:=Felix Fietkau <n...@nbd.name>
 PKG_LICENSE:=BSD-3-Clause
-- 
2.11.0


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

Re: [LEDE-DEV] image: when using the new image build code, gzip ext4 images by default

[Christian Lamparter via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
This is a comment on the patch:
>commit 87b668765e1e987aebef8cf0aae657569b631477
>Author: Felix Fietkau 
>Date:   Fri Jan 13 15:58:37 2017 +0100
>
>   image: when using the new image build code, gzip ext4 images by default
>
>   This reduces the amount of hacks in the makefile code.
>
>   Remove the apm821xx code to do the same - it was broken and left both
>   compressed and uncompressed images in $(BIN_DIR)

Let me explain that apm821xx code.

The uncompressed image was left in place because it allowed "easy install
method" by just using dd with the image on the original WD firmware. 
I refered to this method in the commit [0]:

>The extracted/raw image can be directly installed on
>the internal HDD via "dd if=img.ext4 of=/dev/sdX".
>
>This can either be done in place with the stock MyBook Live
>firmware via ssh. Or by removing the HDD and writing the image
>with a different PC.
>
>The the compressed images are useful for sysupgrade.

so there was some reason behind the uncompressed and compressed image.

Of course, back then the generated ext4 images where like 50-60 MiB.
So I'm fine with the change. But I would like to document the change
somewhere. Editing my wiki [1] is easy enough, but I would like to
move the article to LEDE's wiki. 

So how do I do that? 

[Actually, I want to know: If it is possible to add new articles to 
the wiki for supported devices in LEDE (not OpenWRT sadly) now - and
what format these articles should have.
As far as I can tell the current ToH just links to wiki.openwrt.org.
So I'm looking for a sample/template that just needs to be customized
for the different apm821xx targets.]

Regards,
Christian

[0] 

[1] 

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

[LEDE-DEV] [PATCH] musl: update musl to 1.1.16 and switch to download from git

[Christian Lamparter via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
This patch updates musl to 1.1.16 [0] and removes all the
backported patches. This is a major release and tagged as such.
For more information visit musl-libc.org or read the WHATSNEW.

Furthermore, this patch also changes musl to download directly
from git. This makes it easier to update musl in the future.
This has also an effect on the cached copy of musl in the dl/
directory, from now on, it's a tar.xz.

[0] 
<http://git.musl-libc.org/cgit/musl/commit/?id=8fe1f2d79b275b7f7fb0d41c99e379357df63cd9>

Signed-off-by: Christian Lamparter <chunk...@googlemail.com>
---
No idea, if you want to fudge that in for the upcoming release or
not. A few 4.9 ABI changes could break a few things... This can
be a problem for some packages in the feeds or architectures.
---
 toolchain/musl/Config.version  |   2 +-
 toolchain/musl/common.mk   |   8 +-
 ...ime-day-month-names-not-to-vary-by-locale.patch |  41 ---
 ...regression-in-tcsetattr-on-all-mips-archs.patch |  67 
 ...d-pwrite-syscall-calling-convention-on-sh.patch |  71 
 ...ttyname-refers-to-the-same-file-as-the-fd.patch |  49 ---
 .../025-fix-ffsync-by-changing-it-to-osync.patch   |  25 --
 ...-alt-form-octal-zero-flag-and-field-width.patch |  31 --
 ...-ifru_data-and-ifcu_buf-types-in-net-if.h.patch |  35 --
 .../030-fix-if_indextoname-error-case.patch|  36 --
 ...and-wcsftime_l-prototypes-to-wchar-header.patch |  38 --
 ...fined-behavior-in-sched.h-cpu_set_t-usage.patch |  43 ---
 ...getservby_r-result-pointer-value-on-error.patch |  41 ---
 .../036-fix-strftime-y-for-negative-tm_year.patch  |  23 --
 ...hecks-in-regexec-buffer-size-computations.patch |  72 
 ...with-haystack-strings-longer-than-int_max.patch | 189 --
 ...float-printf-needed-precision-computation.patch |  35 --
 ...ows-and-uncaught-eoverflow-in-printf-core.patch | 390 -
 .../patches/048-math-fix-pow-signed-shift-ub.patch |  38 --
 .../049-fix-clock_nanosleep-error-case.patch   |  30 --
 .../musl/patches/050-add-pthread_setname_np.patch  |  58 ---
 ...at-formatting-of-some-exact-halfway-cases.patch |  30 --
 ...pt_long_only-misinterpreting-as-an-option.patch |  24 --
 ...gratuitous-undefined-behavior-in-strptime.patch |  33 --
 ...-strtof-rounding-with-many-trailing-zeros.patch |  36 --
 ...optimization-in-non-nearest-rounding-mode.patch |  38 --
 ...teger-overflow-of-tm_year-in-__secs_to_tm.patch |  39 ---
 ...-internal-buffer-state-and-error-handling.patch |  36 --
 ...gression-on-archs-with-variable-page-size.patch |  32 --
 ...t-attribute-to-some-function-declarations.patch | 197 ---
 .../musl/patches/400-fix_quoted_timezone.patch |  11 -
 31 files changed, 6 insertions(+), 1792 deletions(-)
 delete mode 100644 
toolchain/musl/patches/005-fix-asctime-day-month-names-not-to-vary-by-locale.patch
 delete mode 100644 
toolchain/musl/patches/010-fix-regression-in-tcsetattr-on-all-mips-archs.patch
 delete mode 100644 
toolchain/musl/patches/015-fix-pread-pwrite-syscall-calling-convention-on-sh.patch
 delete mode 100644 
toolchain/musl/patches/020-verify-that-ttyname-refers-to-the-same-file-as-the-fd.patch
 delete mode 100644 
toolchain/musl/patches/025-fix-ffsync-by-changing-it-to-osync.patch
 delete mode 100644 
toolchain/musl/patches/028-fix-printf-regression-with-alt-form-octal-zero-flag-and-field-width.patch
 delete mode 100644 
toolchain/musl/patches/029-fix-ifru_data-and-ifcu_buf-types-in-net-if.h.patch
 delete mode 100644 
toolchain/musl/patches/030-fix-if_indextoname-error-case.patch
 delete mode 100644 
toolchain/musl/patches/031-add-missing-unlocked-and-wcsftime_l-prototypes-to-wchar-header.patch
 delete mode 100644 
toolchain/musl/patches/033-fix-undefined-behavior-in-sched.h-cpu_set_t-usage.patch
 delete mode 100644 
toolchain/musl/patches/035-fix-getservby_r-result-pointer-value-on-error.patch
 delete mode 100644 
toolchain/musl/patches/036-fix-strftime-y-for-negative-tm_year.patch
 delete mode 100644 
toolchain/musl/patches/037-fix-missing-integer-overflow-checks-in-regexec-buffer-size-computations.patch
 delete mode 100644 
toolchain/musl/patches/038-fix-regexec-with-haystack-strings-longer-than-int_max.patch
 delete mode 100644 
toolchain/musl/patches/039-fix-integer-overflow-in-float-printf-needed-precision-computation.patch
 delete mode 100644 
toolchain/musl/patches/040-fix-integer-overflows-and-uncaught-eoverflow-in-printf-core.patch
 delete mode 100644 
toolchain/musl/patches/048-math-fix-pow-signed-shift-ub.patch
 delete mode 100644 
toolchain/musl/patches/049-fix-clock_nanosleep-error-case.patch
 delete mode 100644 toolchain/musl/patches/050-add-pthread_setname_np.patch
 delete mode 

Re: [LEDE-DEV] Help needed: IP175D + RT3662 issues on a "new" device

[Christian Lamparter via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Wed, Dec 28, 2016 at 10:32 AM, John Crispin <j...@phrozen.org> wrote:
> On 25/12/2016 14:33, Christian Lamparter wrote:
>>
>> I helped Antonio a bit. It turns out that the GE1 needs to be set to MII
>> mode (The default is RGMII). As far as I can tell, he had added this setting
>> already in the DTS. But the rt2880_port_init() didn't do anything with the
>> phy mode. I've made a patch (attached) that will set the bits in SYSCTL1
>> and he's currently testing it.
>>
>> For now, I just added it to rt2880_port_init. However I don't know if the
>> RT2880 uses the same registers and bits (Don't have the RT2880 datasheet).
>> So, what do you think?
>
> I'd merge this path. could you submit it please with proper annotation,
> SoB 
Do you have a RT2880 Datasheet that describe the SYSCTL1 register in
detail? I'm asking because I don't really know if the bits do anything
for the RT2880 too. (I think the RT2880 also should have a way to control
whenever it's a RGMII/MII/RMII).

Because as far as I can tell, the RT3883/3662 code needs to be extended
to support the GE2 too. (This can be mostly copied from the existing
soc_mt7620 code). The RT3883/3662 just lacks the internal switch otherwise
it looks to be the same.

Regards,
Christian

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

Re: [LEDE-DEV] Help needed: IP175D + RT3662 issues on a "new" device

[Christian Lamparter via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hello,

On Saturday, December 24, 2016 6:22:13 PM CET John Crispin wrote:
> On 24/12/2016 17:49, Martin Blumenstingl wrote:
> > On Sat, Dec 24, 2016 at 5:17 PM, antonio rossi  wrote:
> >> Hi everybody,
> >>
> >> i'll try to make this as short as possible despite the large amount of
> >> information needed to describe the issue:
> >>
> >> i am working on adding support to LEDE/OpenWRT for DIR-815 A1, it's a
> >> RT3662+RT3092 device with an infamous IP175D switch IC.
> >> i managed to get everything working properly, save for the fact that
> >> network (both ethernet) works only after the stock bootloader
> >> does some funky stuff to set up the internal cpu port and/or switch
> >> to receive images via TFTP.
> > if only ethernet was affected then this might have been some pinctrl issue.
> > but since wifi is also affected this might be more of a clock (gate?) issue.
> > 
> > maybe John has more information (or even a suspect) here?
> 
> 
> 
> 
> this sound like either
> 
> 1) the cpu port is not configrued properly,
> 2) the switch is not configured properly
> 3) pinmux is failing
> 
> the odd thing is that wifi fails without bootloader init. how does wifi
> fail exactly ?

I helped Antonio a bit. It turns out that the GE1 needs to be set to MII
mode (The default is RGMII). As far as I can tell, he had added this setting
already in the DTS. But the rt2880_port_init() didn't do anything with the 
phy mode. I've made a patch (attached) that will set the bits in SYSCTL1
and he's currently testing it.

For now, I just added it to rt2880_port_init. However I don't know if the
RT2880 uses the same registers and bits (Don't have the RT2880 datasheet).
So, what do you think? 

Regards,
Christian--- a/drivers/net/ethernet/mediatek/mdio_rt2880.c	2016-12-25 13:26:58.456509613 +0100
+++ b/drivers/net/ethernet/mediatek/mdio_rt2880.c	2016-12-25 13:42:08.238633833 +0100
@@ -156,7 +156,7 @@ void rt2880_port_init(struct fe_priv *pr
 	const __be32 *id = of_get_property(np, "reg", NULL);
 	const __be32 *link;
 	int size;
-	int phy_mode;
+	int phy_mode, set_phy_mode = -1;
 
 	if (!id || (be32_to_cpu(*id) != 0)) {
 		pr_err("%s: invalid port id\n", np->name);
@@ -175,10 +175,13 @@ void rt2880_port_init(struct fe_priv *pr
 	phy_mode = of_get_phy_mode(np);
 	switch (phy_mode) {
 	case PHY_INTERFACE_MODE_RGMII:
+		set_phy_mode = 0;
 		break;
 	case PHY_INTERFACE_MODE_MII:
+		set_phy_mode = 1;
 		break;
 	case PHY_INTERFACE_MODE_RMII:
+		set_phy_mode = 2;
 		break;
 	default:
 		if (!priv->phy->phy_fixed[0])
@@ -187,6 +190,18 @@ void rt2880_port_init(struct fe_priv *pr
 		break;
 	}
 
+	if (set_phy_mode != -1) {
+		u32 tmp;
+		u32 ge_offset;
+
+		ge_offset = 12 + id * 2; /* GE1 is at 12-13. GE2 is at 14-15 */
+
+		tmp = rt_sysc_r32(RT3883_SYSC_REG_SYSCFG1);
+		tmp = (t & ~GENMASK(ge_offset + 1, ge_offset)) |
+		(set_phy_mode << ge_offset);
+		rt_sysc_w32(tmp, RT3883_SYSC_REG_SYSCFG1);
+	}
+
 	priv->phy->phy_node[0] = of_parse_phandle(np, "phy-handle", 0);
 	if (!priv->phy->phy_node[0] && !priv->phy->phy_fixed[0])
 		return;
--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Release planning

[Christian Lamparter via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Thursday, December 22, 2016 1:19:46 PM CET Koen Vandeputte wrote:
> 
> On 2016-12-21 20:13, Jo-Philipp Wich wrote:
> > - Are there any outstanding changes?
> >
> >Is there important changes we should wait for before branching the
> >release? Is there pending stuff in the staging trees which should
> >absolutely go into the first release?
> >
> Bump musl to a newer head? (or better to backport some fixes?)
> 
> I see a lot of fixes since 1.1.15 on important parts which could 
> influence stability as a lot of packages depend on musl:
> 
> http://git.musl-libc.org/cgit/musl/log/
> 
> Some examples:
>  fix build regression on archs with variable page size
>  fix swprintf internal buffer state and error handling
[...]

Well, if anyone is interested, here's a stand-alone patch for building
musl from git [0]. There's a small problem though with using GIT and
not point releases. It's because the musl version is used in the target and
toolchain triplet so unless you want ridiculously long names like
target-arm_cortex-a7+neon-vfpv4_musl-4c487165ff074e2f3fe7116140d1d9cded95b018_eabi

so I opt to just use 1.1.16 which unfortunately has the downside that
it's not getting updated automatically.

[0] 


Regards,
Christian

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

Re: [LEDE-DEV] [PATCH] mediatek: enable support for vfpv4 and neon

[Christian Lamparter via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Sunday, December 11, 2016 9:13:56 AM CET John Crispin wrote:
> 
> On 25/11/2016 20:57, Christian Lamparter wrote:
> > While researching for the armvirt target, I looked at the
> > existing arm platforms. It turns out that the mediatek target
> > with its sole MT7623N/A chip is sold as a "highly integrated
> > multimedia network router system-on-chip". To that end, it
> > lists support for the "NEON multimedia processing engine with
> > SIMDv2 / VFPv4 ISA support".
> > 
> > <http://topics.mediatek.com/en/products/connectivity/wifi/home-network/wifi-ap/mt7623na/>
> > 
> > So this patch enables the CPU_SUBTYPE to use this information.
> > This should have the nice side effect that LEDE's phase2 builders
> > no longer need to built a separate "cortex-a7" target, so this
> > should free up some resources.
> > 
> > Cc: John Crispin <j...@phrozen.org>
> > Signed-off-by: Christian Lamparter <chunk...@gmail.com>
> 
> sorry took me ages to build/boot an image. merged into my staging tree
> just now

Looks like this was silently dropped? Doesn't the CPU like NEON/VFPV4
or was the patch lost in a rebase?

Regards,
Christian

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

[LEDE-DEV] [PATCH] mac80211: backport "cfg80211: limit scan results cache size"

[Christian Lamparter]

The patch commit states:
"It's possible to make scanning consume almost arbitrary amounts
of memory, e.g. by sending beacon frames with random BSSIDs at
high rates while somebody is scanning.

Limit the number of BSS table entries we're willing to cache to
1000, limiting maximum memory usage to maybe 4-5MB, but lower
in practice - that would be the case for having both full-sized
beacon and probe response frames for each entry; this seems not
possible in practice, so a limit of 1000 entries will likely be
closer to 0.5 MB."

Signed-off-by: Johannes Berg <johannes.b...@intel.com>"

This patch was added in 4.4.36. But because LEDE backports
cfg80211, mac80211 and the wifi drivers separately, it needs
to be added manually for now. It can be dropped later as it
will be part of the next mac80211 refresh.

Signed-off-by: Christian Lamparter <chunk...@googlemail.com>
---
 ...06-cfg80211-limit-scan-results-cache-size.patch | 161 +
 1 file changed, 161 insertions(+)
 create mode 100644 
package/kernel/mac80211/patches/006-cfg80211-limit-scan-results-cache-size.patch

diff --git 
a/package/kernel/mac80211/patches/006-cfg80211-limit-scan-results-cache-size.patch
 
b/package/kernel/mac80211/patches/006-cfg80211-limit-scan-results-cache-size.patch
new file mode 100644
index 00..eb26fd9241
--- /dev/null
+++ 
b/package/kernel/mac80211/patches/006-cfg80211-limit-scan-results-cache-size.patch
@@ -0,0 +1,161 @@
+From 9853a55ef1bb66d7411136046060bbfb69c714fa Mon Sep 17 00:00:00 2001
+From: Johannes Berg <johannes.b...@intel.com>
+Date: Tue, 15 Nov 2016 12:05:11 +0100
+Subject: [PATCH] cfg80211: limit scan results cache size
+
+It's possible to make scanning consume almost arbitrary amounts
+of memory, e.g. by sending beacon frames with random BSSIDs at
+high rates while somebody is scanning.
+
+Limit the number of BSS table entries we're willing to cache to
+1000, limiting maximum memory usage to maybe 4-5MB, but lower
+in practice - that would be the case for having both full-sized
+beacon and probe response frames for each entry; this seems not
+possible in practice, so a limit of 1000 entries will likely be
+closer to 0.5 MB.
+
+Cc: sta...@vger.kernel.org
+Signed-off-by: Johannes Berg <johannes.b...@intel.com>
+---
+ net/wireless/core.h |  1 +
+ net/wireless/scan.c | 69 +
+ 2 files changed, 70 insertions(+)
+
+diff --git a/net/wireless/core.h b/net/wireless/core.h
+index 08d2e948c9ad..f0c0c8a48c92 100644
+--- a/net/wireless/core.h
 b/net/wireless/core.h
+@@ -71,6 +71,7 @@ struct cfg80211_registered_device {
+   struct list_head bss_list;
+   struct rb_root bss_tree;
+   u32 bss_generation;
++  u32 bss_entries;
+   struct cfg80211_scan_request *scan_req; /* protected by RTNL */
+   struct sk_buff *scan_msg;
+   struct cfg80211_sched_scan_request __rcu *sched_scan_req;
+diff --git a/net/wireless/scan.c b/net/wireless/scan.c
+index b5bd58d0f731..35ad69fd0838 100644
+--- a/net/wireless/scan.c
 b/net/wireless/scan.c
+@@ -57,6 +57,19 @@
+  * also linked into the probe response struct.
+  */
+ 
++/*
++ * Limit the number of BSS entries stored in mac80211. Each one is
++ * a bit over 4k at most, so this limits to roughly 4-5M of memory.
++ * If somebody wants to really attack this though, they'd likely
++ * use small beacons, and only one type of frame, limiting each of
++ * the entries to a much smaller size (in order to generate more
++ * entries in total, so overhead is bigger.)
++ */
++static int bss_entries_limit = 1000;
++module_param(bss_entries_limit, int, 0644);
++MODULE_PARM_DESC(bss_entries_limit,
++ "limit to number of scan BSS entries (per wiphy, default 
1000)");
++
+ #define IEEE80211_SCAN_RESULT_EXPIRE  (30 * HZ)
+ 
+ static void bss_free(struct cfg80211_internal_bss *bss)
+@@ -137,6 +150,10 @@ static bool __cfg80211_unlink_bss(struct 
cfg80211_registered_device *rdev,
+ 
+   list_del_init(>list);
+   rb_erase(>rbn, >bss_tree);
++  rdev->bss_entries--;
++  WARN_ONCE((rdev->bss_entries == 0) ^ list_empty(>bss_list),
++"rdev bss entries[%d]/list[empty:%d] corruption\n",
++rdev->bss_entries, list_empty(>bss_list));
+   bss_ref_put(rdev, bss);
+   return true;
+ }
+@@ -163,6 +180,40 @@ static void __cfg80211_bss_expire(struct 
cfg80211_registered_device *rdev,
+   rdev->bss_generation++;
+ }
+ 
++static bool cfg80211_bss_expire_oldest(struct cfg80211_registered_device 
*rdev)
++{
++  struct cfg80211_internal_bss *bss, *oldest = NULL;
++  bool ret;
++
++  lockdep_assert_held(>bss_lock);
++
++  list_for_each_entry(bss, >bss_list, list) {
++  if (atomic_read(>hold))
++  continue;
++
++  if (!list_empty(>hidden_list) &&
++  !bss->pub.hidden_b

Re: [LEDE-DEV] QCA Dakota support

[Christian Lamparter]

Hello Alexis,

On Sunday, November 27, 2016 12:18:00 PM CET Alexis Green wrote:
> Could you post .config for your build? I cloned your repo and
> successfully built and installed an image, but I'm seeing some rather
> weird behavior.
I added it, but I don't have any magic values in the .config. I played
around with adding LPAE for KVM but as it turns out the DMA driver doesn't
like that.

And there are definitely bugs. If you are looking for support, your best
option is to ask: Matthew McClintock. Since developed most of the platform
code while he was working for QCA, so he more familiar with the hardware
and drivers as I just got this and put a port together for just my hardware...
It's too bad that he didn't get to keep his board.  
 
> I get kernel oops (null derefrence) in bridge code when I connect a
> client to WPA2 AP that is bridged. The oops is gone after I removed
> the following patches (I'm sure it's just one of them, but I have not
> had a chance  to figure out which one exactly it is).
> target/linux/generic/patches-4.8/120-bridge_allow_receiption_on_disabled_port.patch
> target/linux/generic/patches-4.8/640-bridge_no_eap_forward.patch
> target/linux/generic/patches-4.8/641-bridge_always_accept_eap.patch
I have to add Alvaro for this (I'm using his experimental 4.8-rc series
which he is using for his raspberrypi 3 code). As for which one causes 
the issue: I think 640-bridge_no_eap_forward.patch is the one. It looks
like the following patch in 4.8. changed the way the skb and skb2 works:

commit b35c5f632b630183396a2ea2e2247ff8bbf2c94f
Author: Nikolay Aleksandrov 
Date:   Thu Jul 14 06:10:01 2016 +0300

net: bridge: drop skb2/skb0 variables and use a local_rcv boolean [0]

Looking at this commit and the original patch [1]: 
I think we can drop the skb = NULL there (and maybe put the comment
in front of the local_rcv = true;)

> I'm also seeing rather fast memory leak/wastage when wireless devices
> are up - takes 10-15 min to run out of memory. I tried using kmemleak,
> but it doesn't report any suspected leaks. I guess I'll try some
> tracing next.
I've added a few new patches to mac80211-package from the current
wireless-testing.git. If the issue persists, can you report this to
the ath10k-devel mailing list? 

Note: You should check, if it's really the ath10k driver. This can
be done by plugging in a usb-wifi device and setting it up. If it
also fails then there's probably another issue with the patchset.

Regards,
Christian

[0] 


[1] 


config-4.8.xz
Description: application/xz
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [RFC] target: armvirt: new target

[Christian Lamparter]

On Saturday, November 26, 2016 11:08:30 AM CET Yousong Zhou wrote:
> On 26/11/2016, Christian Lamparter <chunk...@googlemail.com> wrote:
> > On Saturday, November 26, 2016 12:43:38 AM CET Yousong Zhou wrote:
> > So, given that information: Selecting just neon would automatically mean:
> > neon and vfpv4... However, Since the build-script isn't that clever it
> > will make an extra target and the phase2 builder would essentially build
> > the same stuff twice.
> >
> > (the older A9 and A8 had neon-vfpv3 tops [2] - but they can be a different
> > subtarget.)
> 
> That neon in FEATURES will be used to form gcc flag -mfpu=neon which
> according to gcc doc is an alias for -mfpu=neon-vfpv3, so I guess
> that's why neon and neon-vfpv4 are built separately.
"NEON" is an alias for "Advanced SIMD". ARM updated Advanced SIMD for 
the Cortex-A7 and A15 chips called it "Advanced SIMDv2" (they added
FMA and half-precision). So from that perspective it makes sense to
map fpu=neon to neon-vfpv3... but also have the neon-vfpv4 (for 
A7, A15, +++)

> >> The allwinner-a20 soc (dual-core cortex-a7) on cubieboard2 is also
> >> capable
> >> of neon-vfpv4 and I just assembled a small binary with ".fpu neon-vfpv4"
> >> from gas testsuite and it runs to end just fine with accel=kvm.  It
> >> should
> >> also work with accel=tcg as qemu can provide the emulation.  But I am not
> >> sure how it will work out with accel=kvm on a hardware without
> >> neon-vfpv4...
> >
> > I think the best idea would to make it like the brcm2708 targets and
> > have multiple subtargets each with different CPU_TYPE and CPU_SUBTYPEs.
> >
> > This is mainly because the RPI, RPI2 and now the RPI3 had all very
> > different
> > CPUs (RPI1 had a ARMv6 with just vfp, the RPI2 had an A7 with neon-vfpv4
> > and
> > the RPI3 had A53 with everything as well).
> >
> > So looking at <http://phase2.builds.lede-project.org/builders>, There are
> > already existing targets that compile:
> > A5 (at91)
> > A7 (Mediatek ARM? - really no features?)
> > A7-neon-vfpv4 (RPI2/bcm2709, (ipq4xxx))
> > A8-vfpv3 (sunxi(Allwinner A1X/A20/A3x),
> > A9 (layerscape)
> > A9-neon (zynq,imx6)
> > A9-vfpv3 (omap,mvebu)
> > A15-neon-vfpv4 (ipq806x)
> > A53-neon-vfpv4 (RPI3/bcm2710 (in the making))
> >
> 
> This list can be compacted a liitle to lift more burden on buildbots,
> e.g. -mtune only for a7, a15, a53
I've already posted a patch to the ML that set neon-vfpv4 for the MediaTek ARM.
Another candidate should be the layerscape platform (A9-neon?). omap could be
moved to the A9-Neon too. However the mvebu can't (The old Armada-370 doesn't
support NEON, but all other do.).

As for the armvirt target: If you only want to stick with a single target,
I think the A7 would be a better pick for the ARMv7... Not that it changes
much.
 
> >> I will provide a updated patch in the following days.
> > I very much like the idea. Getting kvm on arm and lede/openwrt is a bit
> > clunky.
> > Do you know of any qemu+kvm packages for openwrt/lede? Or should we try our
> >
> > hands at it?
> >
> 
> I opened a pr about qemu few days ago:
> https://github.com/openwrt/packages/pull/3550 .  I am going to disable
> a few features explicitly, otherwise it may fail when built by
> buildbots
Thanks, that's very useful. 

Regards,
Christian


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

[LEDE-DEV] [PATCH] mediatek: enable support for vfpv4 and neon

[Christian Lamparter]

While researching for the armvirt target, I looked at the
existing arm platforms. It turns out that the mediatek target
with its sole MT7623N/A chip is sold as a "highly integrated
multimedia network router system-on-chip". To that end, it
lists support for the "NEON multimedia processing engine with
SIMDv2 / VFPv4 ISA support".

<http://topics.mediatek.com/en/products/connectivity/wifi/home-network/wifi-ap/mt7623na/>

So this patch enables the CPU_SUBTYPE to use this information.
This should have the nice side effect that LEDE's phase2 builders
no longer need to built a separate "cortex-a7" target, so this
should free up some resources.

Cc: John Crispin <j...@phrozen.org>
Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
I don't have any MT7623, so I can't say if this works or not.
---
 target/linux/mediatek/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/linux/mediatek/Makefile b/target/linux/mediatek/Makefile
index 689ba31..e3eecd5 100644
--- a/target/linux/mediatek/Makefile
+++ b/target/linux/mediatek/Makefile
@@ -7,6 +7,7 @@ BOARD:=mediatek
 BOARDNAME:=MediaTek Ralink ARM
 FEATURES:=squashfs nand ubifs
 CPU_TYPE:=cortex-a7
+CPU_SUBTYPE:=neon-vfpv4
 MAINTAINER:=John Crispin <j...@phrozen.org>
 
 KERNEL_PATCHVER:=4.4
-- 
2.10.2


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

Re: [LEDE-DEV] [RFC] target: armvirt: new target

[Christian Lamparter]

On Saturday, November 26, 2016 12:43:38 AM CET Yousong Zhou wrote:
> On 25 November 2016 at 01:29, Christian Lamparter
> <chunk...@googlemail.com> wrote:
> > Hello,
> >
> > On Friday, November 25, 2016 12:03:54 AM CET Yousong Zhou wrote:
> >> An ARM Cortex-A machine provided by QEMU.
> >>
> >> Kernel drivers enabled:
> >>
> >>  - pl011, uart
> >>  - pl031, rtc
> >>  - pl061, gpio
> >>  - pci-host-generic
> >>  - virtio_{mmio,pci,net,blk,scsi,console,balloon}
> >>  - ext4
> >>  - DEBUG_BUGVERBOSE for debug purposes
> >>  - neon, vfp extensions support (otherwise userland will fail with
> >>illegal instruction signal (code 0x0004))
> >>
> >> Signed-off-by: Yousong Zhou <yszhou4t...@gmail.com>
> >> ---
> >> I prepared this target initially only for the purposes of proper testing 
> >> KVM
> >> support on Cubieboard2 as I cannot find an usable prebuilt binary on the 
> >> net.
> >>
> >> It is posted as RFC because it will introduce a new target combination
> >> cortex-a15_neon and may place an extra burden on the build system of LEDE 
> >> and
> >> the target users at the moment may be quite small.
> >
> > I started up initramfs image with qemu. And the /proc/cpuinfo stated:
> > Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt 
> > vfpd32 lpae evtstrm
> >
> > So, wouldn't it make sense to change the
> >
> > CPU_SUBTYPE:=neon
> >
> > to
> >
> > CPU_SUBTYPE:=neon-vfpv4
> >
> > Because, this way it will share the same "packages" with ipq806x.
> > So it will be less work for the phase2 builds.
> >
> > (Note: I haven't tested this with kvm on a A15, but only qemu-system-arm
> > on a x86). But I haven't seen any "illegal instruction signal (code 
> > 0x0004)"
> > there when I compiled a initramfs with neon-vfpv4.
> >
> >
> > Regards,
> > Christian
> 
> Yes, turning to neon-vfpv3 seems to be a fair trade-off as cortex-a15
> is expected to have that feature on.
And that's what I don't understand. Because even the first Cortex-A15 (and
all A7) revisions that went into mass-production comes according to
ARM's Cortex-A15 Technical Reference Manual Table 14.1 [0] in the following
configurations:
- Neon (Advanced SIMDv2) and vfpv4 supported.
- only vfp4
- no neon and no vfpv4 

So, given that information: Selecting just neon would automatically mean:
neon and vfpv4... However, Since the build-script isn't that clever it
will make an extra target and the phase2 builder would essentially build
the same stuff twice.

(the older A9 and A8 had neon-vfpv3 tops [2] - but they can be a different
subtarget.)

> The allwinner-a20 soc (dual-core cortex-a7) on cubieboard2 is also capable
> of neon-vfpv4 and I just assembled a small binary with ".fpu neon-vfpv4" 
> from gas testsuite and it runs to end just fine with accel=kvm.  It should
> also work with accel=tcg as qemu can provide the emulation.  But I am not
> sure how it will work out with accel=kvm on a hardware without neon-vfpv4...

I think the best idea would to make it like the brcm2708 targets and
have multiple subtargets each with different CPU_TYPE and CPU_SUBTYPEs.

This is mainly because the RPI, RPI2 and now the RPI3 had all very different
CPUs (RPI1 had a ARMv6 with just vfp, the RPI2 had an A7 with neon-vfpv4 and
the RPI3 had A53 with everything as well).

So looking at <http://phase2.builds.lede-project.org/builders>, There are
already existing targets that compile:
A5 (at91)
A7 (Mediatek ARM? - really no features?)
A7-neon-vfpv4 (RPI2/bcm2709, (ipq4xxx))
A8-vfpv3 (sunxi(Allwinner A1X/A20/A3x), 
A9 (layerscape)
A9-neon (zynq,imx6)
A9-vfpv3 (omap,mvebu) 
A15-neon-vfpv4 (ipq806x)
A53-neon-vfpv4 (RPI3/bcm2710 (in the making))

So adding a subtarget for those for your armvirt would come at no cost to
the phase2 builders.

(Funnily enough, I also looked at the arm64 target and the README states
that it's currently kind of a virtual platform as well. So this can
be integrated as well?)

> I will provide a updated patch in the following days.
I very much like the idea. Getting kvm on arm and lede/openwrt is a bit clunky.
Do you know of any qemu+kvm packages for openwrt/lede? Or should we try our 
hands at it?

Regards,
Christian

[0] 
<http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0438d/CEGCDBHC.html>
[1] <https://en.wikipedia.org/wiki/ARM_Cortex-A15>
[2] <https://en.wikipedia.org/wiki/List_of_ARM_microarchitectures>


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

Re: [LEDE-DEV] [RFC] target: armvirt: new target

[Christian Lamparter]

Hello,

On Friday, November 25, 2016 12:03:54 AM CET Yousong Zhou wrote:
> An ARM Cortex-A machine provided by QEMU.
> 
> Kernel drivers enabled:
> 
>  - pl011, uart
>  - pl031, rtc
>  - pl061, gpio
>  - pci-host-generic
>  - virtio_{mmio,pci,net,blk,scsi,console,balloon}
>  - ext4
>  - DEBUG_BUGVERBOSE for debug purposes
>  - neon, vfp extensions support (otherwise userland will fail with
>illegal instruction signal (code 0x0004))
> 
> Signed-off-by: Yousong Zhou 
> ---
> I prepared this target initially only for the purposes of proper testing KVM
> support on Cubieboard2 as I cannot find an usable prebuilt binary on the net.
> 
> It is posted as RFC because it will introduce a new target combination
> cortex-a15_neon and may place an extra burden on the build system of LEDE and
> the target users at the moment may be quite small.

I started up initramfs image with qemu. And the /proc/cpuinfo stated:
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 
lpae evtstrm

So, wouldn't it make sense to change the

CPU_SUBTYPE:=neon

to 

CPU_SUBTYPE:=neon-vfpv4

Because, this way it will share the same "packages" with ipq806x.
So it will be less work for the phase2 builds.

(Note: I haven't tested this with kvm on a A15, but only qemu-system-arm
on a x86). But I haven't seen any "illegal instruction signal (code 0x0004)"
there when I compiled a initramfs with neon-vfpv4.


Regards,
Christian

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

Re: [LEDE-DEV] QCA Dakota support

[Christian Lamparter]

Hi Christian,

On Wednesday, November 23, 2016 10:13:45 PM CET Christian Mehlis wrote:
> your current staging tree works for me, it generates an itb and a trx 
> file!
> I added some files to support the Compex board I own:
> https://github.com/mehlis/source/commits/compex-wpj428
> 
> Feel free to include some bits in your tree. I had to add dk04-c5 
> support, perhaps you know some other way?
> My commit is compile tested only.
I looked at it. But you need to consider what I previously wrote (in the
second to last mail?):

"the kernel devicetree maintainers frown upon "catch-all" compatible strings 
[0]."

This means that you have to replace all the generic "qcom,*ipq40xx*" with 
"qcom,*ipq4028*" in your dts and dtsi. Next, you have to add the bindings
to the kernel platform and driver code, so the device-tree will find the
driver for hardware definitions in your dtb. (Alternatively, you can
add the appropriate "qcom,*ipq4019*" binding)

> Please be more precise on the flashing steps. I would like to flash from 
> uboot. I never had a board running ubifs. QCA provides a img file, so 
> I'm a bit lost here.
I added an entry on how to boot the initramfs on the ASUS. And since that's
the only IPQ40XX device I have, I can only give "precise informations" for
it.

For the Asus RT-AC58U, it's very simple. During boot, you have this 1-2 Second
window to select the following option:

Please choose the operation: 
   1: Load System code to SDRAM via TFTP.
   2: Load System code then write to Flash via TFTP.
   3: Boot System code via Flash (default).
   4: Entr boot command line interface.
   7: Load Boot Loader code then write to Flash via Serial.
   9: Load Boot Loader code then write to Flash via TFTP.

And for the initramfs image. you just hit (1). It then continues to ask
about the IP, tftp server ip and tftp image name (obviously that's the
lede-ipq40xx-RT-AC58U-initramfs-fit-uImage.itb file in the tftp's server
directory). and that's it: it automatically boots.

Note: Currently, a working flash image is not implemented. But, you don't
need to flash the image in order to test it. The initramfs image is simply
loaded into the SDRAM and it boots from there. (The rootfs is part
of the initramfs image). Using initramfs is much better for development,
since you don't need to wait it to flash (The SPINAND is very slow and
also you'll burn through the NAND quite quickly)

Regards,
Christian

[0] 

BTW: If you have any questions, you can also find me on google hangouts
(with the same gmail). Note: If you have an "unusual mail/nick"* there,
just let me know beforehand via email as I tend to ignore unknown 
requests :-) )

* not something that resembles your name.

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