Re: [LEDE-DEV] [PATCH] include: Include new location for DT bindings

[Florian Fainelli]

Le 10/09/17 à 20:48, Florian Fainelli a écrit :
> Starting with commit d5d332d3f7e8 ("devicetree: Move include prefixes
> from arch to separate directory") included in 4.12 and newer relocated
> the dt-bindings directory, so account for that while passing CPPFLAGS
> before DTC runs.
> 
> Signed-off-by: Florian Fainelli 

Applied
-- 
Florian

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

Re: [LEDE-DEV] [PATCH] bcm53xx: Fix SmartRG SR400AC initramfs image

[Florian Fainelli]

Le 10/09/17 à 20:51, Florian Fainelli a écrit :
> The SmartRG SR400AC CFE does not accept a TRX image, just a normal
> binary image.
> 
> Signed-off-by: Florian Fainelli 

Applied
-- 
Florian

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

Re: [LEDE-DEV] [PATCH] uboot-sunxi: Backport fix for stale CONFIG_SUNXIG_GMAC references

[Florian Fainelli]

Le 10/15/17 à 15:16, Hauke Mehrtens a écrit :
> On 10/15/2017 11:05 AM, Zoltan HERPAI wrote:
>> On Sat, 14 Oct 2017, Florian Fainelli wrote:
>>
>>> This backports the upstream commit fixing stale references to
>>> CONFIG_SUNXI_GMAC which have been later replaced by CONFIG_SUN7I_GMAC.
>>> This fixes the designware MAC pinmuxing on e.g: Lamobo R1.
>>>
>>> Signed-off-by: Florian Fainelli 
>>
>> Acked-by: Zoltan HERPAI 
> 
> Please refresh the patch and then
> 
> Acked-by: Hauke Mehrtens 

Thanks, applied with a patches refresh (I did not take this from
patchwork so it's missing both of your Acks...).
-- 
Florian

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

Re: [LEDE-DEV] [source] ar71xx: deactivate some boards with too small kernel partitions

[Hauke Mehrtens]

Hi Piotr,

thanks for writing this mail.

On 10/23/2017 02:41 PM, Piotr Dymacz wrote:
> Hello Hauke,
> 
> AFAIK, "{image,kernel,rootfs} is too big" errors are/were just ignored
> before. As I understand this, with such approach, we can keep support
> for device and allow users to build images with custom configuration
> (different kernel options, set of packages, etc.) which makes image
> generation possible. If you look closer at the yesterday buildbot log
> [1], this was true for (some of) below devices (grep for "WARNING.*too
> big").

As discussed in IRC, this error message complains about too big kernel
image size which is different for overall image size.

> What I don't really understand here is why disabling image generation
> only for below boards made buildbot happy again if there are many other
> which have similar issues now [2] and are just ignored. How below boards
> were selected and why image for, for example "re450", wasn't disabled if
> it also fails?
> 
> Also, please have a look at my comments inline, below.
> 
> [1]
> http://phase1.builds.lede-project.org/builders/ar71xx%2Fgeneric/builds/388/steps/images/logs/stdio
> 
> 
> [2]
> http://phase1.builds.lede-project.org/builders/ar71xx%2Fgeneric/builds/389/steps/images/logs/stdio
> 
> 
> On 22.10.2017 23:19, LEDE Commits wrote:
>> hauke pushed a commit to source.git, branch master:
>> https://git.lede-project.org/f7a6fd31539be54d14d7c52b491b40b26bf8f740
>>
>> commit f7a6fd31539be54d14d7c52b491b40b26bf8f740
>> Author: Hauke Mehrtens 
>> AuthorDate: Sun Oct 22 23:10:08 2017 +0200
>>
>>  ar71xx: deactivate some boards with too small kernel partitions
>>   This affects the following boards:
>>   * dr344
> 
> The only way to fix this one I can think about, is to change mtd order
> (use kernel/rootfs instead of rootfs/kernel). But this would break
> backward compatibility and require change of "bootcmd" variable in
> U-Boot environment _before_ upgrade to new image.
> 
>>   * archer-c58-v1
>>   * archer-c60-v1
>>   * tl-wr902ac-v1
>>   * tl-wr942n-v1
> 
> These should be easily fixable. They use TP-Link "safeloader" image type
> with kernel/rootfs order (os-image/file-system), so we can increase
> kernel partition size and reduce the rootfs.

Could you write a patch for this please, I am busy the next few days.

> 
>>   * ubnt-uap-pro
>>   * ubnt-unifi-outdoor-plus
> 
> No idea about these two.


I think we should make the images smaller by deactivating
CONFIG_KERNEL_KALLSYMS by default and using some scripts to decode the
binary only stacktraces.

In addition we should provide more space for the kernel partition.

Hauke

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

[LEDE-DEV] [PATCH] sunxi: add Orange Pi 2 support

[Zoltan HERPAI]

- H3 @ 1.3 GHz
- 1GiB DDR3
- 10/100Mbps Ethernet
- Realtek RTL8189ETV wifi
- 4 USB 2.0

Difference to the "Orange Pi Plus" is the lack of Gbit ethernet
and lack of onboard flash.

Signed-off-by: Zoltan HERPAI 
---
 package/boot/uboot-sunxi/Makefile | 7 +++
 target/linux/sunxi/image/cortex-a7.mk | 9 +
 2 files changed, 16 insertions(+)

diff --git a/package/boot/uboot-sunxi/Makefile 
b/package/boot/uboot-sunxi/Makefile
index 50c6b06..b0737b7 100644
--- a/package/boot/uboot-sunxi/Makefile
+++ b/package/boot/uboot-sunxi/Makefile
@@ -144,6 +144,12 @@ define U-Boot/orangepi_plus
   BUILD_DEVICES:=sun8i-h3-orangepi-plus
 endef
 
+define U-Boot/orangepi_2
+  BUILD_SUBTARGET:=cortexa7
+  NAME:=Orange Pi 2 (H3)
+  BUILD_DEVICES:=sun8i-h3-orangepi-2
+endef
+
 define U-Boot/pangolin
   BUILD_SUBTARGET:=cortexa7
   NAME:=Theobroma A31-yQ7 devboard
@@ -179,6 +185,7 @@ UBOOT_TARGETS := \
nanopi_neo \
orangepi_r1 \
orangepi_plus \
+   orangepi_2 \
pangolin \
pine64_plus
 
diff --git a/target/linux/sunxi/image/cortex-a7.mk 
b/target/linux/sunxi/image/cortex-a7.mk
index d0b7aa0..d219a1d 100644
--- a/target/linux/sunxi/image/cortex-a7.mk
+++ b/target/linux/sunxi/image/cortex-a7.mk
@@ -136,6 +136,15 @@ endef
 
 TARGET_DEVICES += sun8i-h3-orangepi-plus
 
+define Device/sun8i-h3-orangepi-2
+  DEVICE_TITLE:=Xunlong Orange Pi 2
+  DEVICE_PACKAGES:=kmod-rtc-sunxi
+  SUPPORTED_DEVICES:=xunlong,orangepi-2
+  SUNXI_DTS:=sun8i-h3-orangepi-2
+endef
+
+TARGET_DEVICES += sun8i-h3-orangepi-2
+
 
 define Device/sun7i-a20-pcduino3
   DEVICE_TITLE:=LinkSprite pcDuino3
-- 
1.9.1


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

Re: [LEDE-DEV] Support for TP-Link Archer C7 1750 v4.0

[Alberto Bursi]

On 10/23/2017 09:43 PM, Emmanuel Grumbach wrote:

On Mon, Oct 23, 2017 at 9:50 PM, Emmanuel Grumbach  wrote:

On Mon, Oct 23, 2017 at 8:30 PM, Baptiste Jonglez
 wrote:

Hi,

On 23-10-17, Emmanuel Grumbach wrote:

I just bought a TP-Link Archer C7 AC1750 and got the v4.0 version. I
haven't found any image in
https://lede-project.org/toh/views/toh_fwdownload that claims it
features that version. I can see v1 and v2, but not v4.

Support for this board has just been merged: 
https://git.lede-project.org/9887afb1afcf387f6892315413e610a6816df463

So, there is no support in 17.01 but snapshot images should work, and the
ToH at actually links to downloadable images :)

   https://lede-project.org/toh/hwdata/tp-link/tp-link_archer_c7_v


Hmm... Broken link.
I took v4 at the end, but I couldn't get the webUI. The device did
respond to SSH though.
I tried to sysupgrade back to the stock firmware, but I screwed it up
apparently.
Now it doesn't even boot. Leds blink a bit and shut down immediately.

Seems like it is a brick now :(




Snapshot images don't have webUI, you need to install it from ssh (so 
that part was normal).
Snapshot images also have other limitations (you can't install 
driver-related packages after a few days and you need to do a full 
upgrade first, or use the Image Builder to integrate all packages in the 
firmware, see the wiki 
https://lede-project.org/docs/user-guide/imagebuilder )


That said, most modern routers have a bootloader with a recovery mode 
you can use to send over another firmware image for it to reflash. If 
you did not hose the first blocks of the onboard flash, the bootloader 
is still alive and you should be able to recover the router without 
factory flashing tools.


The v2 version of that router seems to have it (should be the same or at 
least very similar to yours, imho), see here 
https://mikepalmer.net/tp-link-archer-c7-ac1750-v2-tftp-recovery/
or google around for similar instructions for your device. (the "Make 
the router think its getting a normal recovery firmware" part is 
renaming the openwrt factory flash firmware into the name the recovery 
is looking for)


If you don't know how to set up a tftp server, see the wiki here 
https://lede-project.org/docs/user-guide/tftpserver


-Alberto

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

Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 6/9] ar71xx: add support for Anonabox Pro

[Piotr Dymacz]

Hello Zoltan, August,

On 23.10.2017 21:58, Zoltan HERPAI wrote:

L. D. Pinney wrote:

Why does this patch use "legacy" ?

On Monday, October 23, 2017, 4:23:20 AM GMT+8, Zoltan HERPAI 
 wrote:



Because this seemed to build, and without access to the actual hardware,
I had to rely on the PR sent.

[snip]

Please, move image generation code for this device to the new building 
code. You can follow definition for "zbt-we1526" which also uses 
rootfs-kernel mtd order and is based on the same h/w platform.


--
Cheers,
Piotr

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

Re: [LEDE-DEV] Support for TP-Link Archer C7 1750 v4.0

[Hauke Mehrtens]

On 10/23/2017 09:43 PM, Emmanuel Grumbach wrote:
> On Mon, Oct 23, 2017 at 9:50 PM, Emmanuel Grumbach  
> wrote:
>> On Mon, Oct 23, 2017 at 8:30 PM, Baptiste Jonglez
>>  wrote:
>>> Hi,
>>>
>>> On 23-10-17, Emmanuel Grumbach wrote:
 I just bought a TP-Link Archer C7 AC1750 and got the v4.0 version. I
 haven't found any image in
 https://lede-project.org/toh/views/toh_fwdownload that claims it
 features that version. I can see v1 and v2, but not v4.
>>>
>>> Support for this board has just been merged: 
>>> https://git.lede-project.org/9887afb1afcf387f6892315413e610a6816df463
>>>
>>> So, there is no support in 17.01 but snapshot images should work, and the
>>> ToH at actually links to downloadable images :)
>>>
>>>   https://lede-project.org/toh/hwdata/tp-link/tp-link_archer_c7_v
>>>
> 
> Hmm... Broken link.
> I took v4 at the end, but I couldn't get the webUI. The device did
> respond to SSH though.

The snapshot build do not contain luci, you have to install the webui by
your own, through SSH.

> I tried to sysupgrade back to the stock firmware, but I screwed it up
> apparently.
> Now it doesn't even boot. Leds blink a bit and shut down immediately.
> 
> Seems like it is a brick now :(

You should connect a 3.3V Uart to it and hope that at least the boot
loader is stating up, there are probably some informations in the
Internet on where to connect it.

>> Awesome... Don't send me emails in the coming 10 minutes, my router
>> will probably be rebooting... :)
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 


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

Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 6/9] ar71xx: add support for Anonabox Pro

[Zoltan HERPAI]

L. D. Pinney wrote:

Why does this patch use "legacy" ?

On Monday, October 23, 2017, 4:23:20 AM GMT+8, Zoltan HERPAI 
 wrote:


Because this seemed to build, and without access to the actual hardware, 
I had to rely on the PR sent.


Happy to see that August is also on the thread now. :)

Regards,
-w-

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

Re: [LEDE-DEV] Support for TP-Link Archer C7 1750 v4.0

[Emmanuel Grumbach]

On Mon, Oct 23, 2017 at 9:50 PM, Emmanuel Grumbach  wrote:
> On Mon, Oct 23, 2017 at 8:30 PM, Baptiste Jonglez
>  wrote:
>> Hi,
>>
>> On 23-10-17, Emmanuel Grumbach wrote:
>>> I just bought a TP-Link Archer C7 AC1750 and got the v4.0 version. I
>>> haven't found any image in
>>> https://lede-project.org/toh/views/toh_fwdownload that claims it
>>> features that version. I can see v1 and v2, but not v4.
>>
>> Support for this board has just been merged: 
>> https://git.lede-project.org/9887afb1afcf387f6892315413e610a6816df463
>>
>> So, there is no support in 17.01 but snapshot images should work, and the
>> ToH at actually links to downloadable images :)
>>
>>   https://lede-project.org/toh/hwdata/tp-link/tp-link_archer_c7_v
>>

Hmm... Broken link.
I took v4 at the end, but I couldn't get the webUI. The device did
respond to SSH though.
I tried to sysupgrade back to the stock firmware, but I screwed it up
apparently.
Now it doesn't even boot. Leds blink a bit and shut down immediately.

Seems like it is a brick now :(

>
>
> Awesome... Don't send me emails in the coming 10 minutes, my router
> will probably be rebooting... :)

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

Re: [LEDE-DEV] [PATCH 13/13] sunxi: Add A64 support with cortex53 subtarget

[Hauke Mehrtens]

Hi Baptiste,

On 10/23/2017 08:17 PM, Baptiste Jonglez wrote:
> Hi Hauke,
> 
> On 03-08-17, Hauke Mehrtens wrote:
>> This adds initial support for the A64 Allwinner SoC to LEDE.
>> It will be build in the new cortexa53 subtarget.
>>
>> Currently it only supports the pine64 and the image is able to boot on
>> this SoC.
> 
> This was merged a while ago, but I gave it another try on my Pine64+ and
> still couldn't boot a LEDE image.  But this time I have a serial console
> adapter :)
> 
> I tried to boot the latest LEDE snapshot from several different µSD card.
> The kernel always starts to boot, complains about errors reading from the
> mmc, and then gets stuck.  The device is a pine64+ with 1 GB of RAM.

I am also using the PINE64+ with 1GB memory and I also saw some problems
which I assume are related to MMC on my board.

> Sometimes it fails before mounting the root:
> 
> [1.273249] Waiting for root device /dev/mmcblk0p2...
> [1.281238] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 55, RE RCE !!
> [1.317715] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 3, RCE !!
> [1.323864] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 3, RCE !!
> [1.344409] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 55, RCE !!
> [1.350097] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 6, RE RCE !!
> [1.355941] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 55, RCE !!
> [1.361651] mmc0: new high speed SDHC card at address cda0
> [1.367559] mmcblk0: mmc0:cda0 0 7.51 GiB
> [1.372415] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 18, RD RE RCE !!
> [1.378609] sunxi-mmc 1c0f000.mmc: data error, sending stop command
> [2.374894] sunxi-mmc 1c0f000.mmc: send stop command failed
> 
> Sometimes it fails just after:
> 
> [1.273185] Waiting for root device /dev/mmcblk0p2...
> [1.342876] mmc0: new high speed SDHC card at address 0007
> [1.348790] mmcblk0: mmc0:0007 SD8GB 7.42 GiB
> [1.354623]  mmcblk0: p1 p2
> [1.401534] VFS: Mounted root (squashfs filesystem) readonly on device 
> 179:2.
> [1.408891] Freeing unused kernel memory: 320K
> [1.418724] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 18, RD DCE !!
> [1.424659] sunxi-mmc 1c0f000.mmc: data error, sending stop command
> [1.430953] sunxi-mmc 1c0f000.mmc: send stop command failed
> [1.436564] mmcblk0: timed out sending r/w cmd command, card status 
> 0x400900
> [1.443601] mmcblk0: command error, retrying timeout
> [1.449386] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 18, RD DCE !!
> [1.455309] sunxi-mmc 1c0f000.mmc: data error, sending stop command
> [1.461581] sunxi-mmc 1c0f000.mmc: send stop command failed
> [1.467185] mmcblk0: timed out sending r/w cmd command, card status 
> 0x400900
> [1.474221] mmcblk0: command error, retrying timeout
> [1.484737] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 18, RD DCE !!
> [1.490670] sunxi-mmc 1c0f000.mmc: data error, sending stop command
> [1.496956] sunxi-mmc 1c0f000.mmc: send stop command failed
> [1.502550] mmcblk0: timed out sending r/w cmd command, card status 
> 0x400900
> [1.509598] mmcblk0: command error, retrying timeout
> [1.516026] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 18, RD DCE !!
> [1.521959] sunxi-mmc 1c0f000.mmc: data error, sending stop command
> [2.524849] sunxi-mmc 1c0f000.mmc: send stop command failed
> 
> Do you have any idea of what could be wrong?
> 
> I also tried an Armbian image (based on Debian jessie, with a non-mainline
> 3.10 kernel) and it worked fine out-of-the-box.
> 
> Attached are full bootlogs for both LEDE and Armbian.
Could you try an image build the sunxi branch of my staging tree please:
https://git.lede-project.org/?p=lede/hauke/staging.git;a=shortlog;h=refs/heads/sunxi

I backproted the MMC driver in there as it got some patches which are
probably needed for the A64 SoC. For me it also boots up without these
changes, but sometimes I also see some error messages.

I never looked at the 3.10 kernel or booted it up, I only looked at what
is in mainline. If we add kernel 4.14 support before the next LEDE
release I will probably bring the sunxi target to kernel 4.14 as this
kernel version has official support for the A64 SoC.

Hauke



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

Re: [LEDE-DEV] Support for TP-Link Archer C7 1750 v4.0

[Emmanuel Grumbach]

On Mon, Oct 23, 2017 at 8:30 PM, Baptiste Jonglez
 wrote:
> Hi,
>
> On 23-10-17, Emmanuel Grumbach wrote:
>> I just bought a TP-Link Archer C7 AC1750 and got the v4.0 version. I
>> haven't found any image in
>> https://lede-project.org/toh/views/toh_fwdownload that claims it
>> features that version. I can see v1 and v2, but not v4.
>
> Support for this board has just been merged: 
> https://git.lede-project.org/9887afb1afcf387f6892315413e610a6816df463
>
> So, there is no support in 17.01 but snapshot images should work, and the
> ToH at actually links to downloadable images :)
>
>   https://lede-project.org/toh/hwdata/tp-link/tp-link_archer_c7_v
>


Awesome... Don't send me emails in the coming 10 minutes, my router
will probably be rebooting... :)

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

Re: [LEDE-DEV] [PATCH 13/13] sunxi: Add A64 support with cortex53 subtarget

[Baptiste Jonglez]

Hi Hauke,

On 03-08-17, Hauke Mehrtens wrote:
> This adds initial support for the A64 Allwinner SoC to LEDE.
> It will be build in the new cortexa53 subtarget.
> 
> Currently it only supports the pine64 and the image is able to boot on
> this SoC.

This was merged a while ago, but I gave it another try on my Pine64+ and
still couldn't boot a LEDE image.  But this time I have a serial console
adapter :)

I tried to boot the latest LEDE snapshot from several different µSD card.
The kernel always starts to boot, complains about errors reading from the
mmc, and then gets stuck.  The device is a pine64+ with 1 GB of RAM.

Sometimes it fails before mounting the root:

[1.273249] Waiting for root device /dev/mmcblk0p2...
[1.281238] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 55, RE RCE !!
[1.317715] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 3, RCE !!
[1.323864] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 3, RCE !!
[1.344409] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 55, RCE !!
[1.350097] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 6, RE RCE !!
[1.355941] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 55, RCE !!
[1.361651] mmc0: new high speed SDHC card at address cda0
[1.367559] mmcblk0: mmc0:cda0 0 7.51 GiB
[1.372415] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 18, RD RE RCE !!
[1.378609] sunxi-mmc 1c0f000.mmc: data error, sending stop command
[2.374894] sunxi-mmc 1c0f000.mmc: send stop command failed

Sometimes it fails just after:

[1.273185] Waiting for root device /dev/mmcblk0p2...
[1.342876] mmc0: new high speed SDHC card at address 0007
[1.348790] mmcblk0: mmc0:0007 SD8GB 7.42 GiB
[1.354623]  mmcblk0: p1 p2
[1.401534] VFS: Mounted root (squashfs filesystem) readonly on device 179:2.
[1.408891] Freeing unused kernel memory: 320K
[1.418724] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 18, RD DCE !!
[1.424659] sunxi-mmc 1c0f000.mmc: data error, sending stop command
[1.430953] sunxi-mmc 1c0f000.mmc: send stop command failed
[1.436564] mmcblk0: timed out sending r/w cmd command, card status 0x400900
[1.443601] mmcblk0: command error, retrying timeout
[1.449386] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 18, RD DCE !!
[1.455309] sunxi-mmc 1c0f000.mmc: data error, sending stop command
[1.461581] sunxi-mmc 1c0f000.mmc: send stop command failed
[1.467185] mmcblk0: timed out sending r/w cmd command, card status 0x400900
[1.474221] mmcblk0: command error, retrying timeout
[1.484737] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 18, RD DCE !!
[1.490670] sunxi-mmc 1c0f000.mmc: data error, sending stop command
[1.496956] sunxi-mmc 1c0f000.mmc: send stop command failed
[1.502550] mmcblk0: timed out sending r/w cmd command, card status 0x400900
[1.509598] mmcblk0: command error, retrying timeout
[1.516026] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 18, RD DCE !!
[1.521959] sunxi-mmc 1c0f000.mmc: data error, sending stop command
[2.524849] sunxi-mmc 1c0f000.mmc: send stop command failed

Do you have any idea of what could be wrong?

I also tried an Armbian image (based on Debian jessie, with a non-mainline
3.10 kernel) and it worked fine out-of-the-box.

Attached are full bootlogs for both LEDE and Armbian.

Thanks,
Baptiste
U-Boot SPL 2017.07 (Oct 19 2017 - 19:48:49)
DRAM: 1024 MiB
Trying to boot from MMC1
NOTICE:  BL3-1: Running on A64/H64 (1689) in SRAM A2 (@0x44000)
NOTICE:  Configuring SPC Controller
NOTICE:  BL3-1: v1.0(debug):fbde9ac
NOTICE:  BL3-1: Built : 23:50:51, Oct 19 2017
NOTICE:  Configuring AXP PMIC
NOTICE:  PMIC: fixing DRAM voltage from 1.24V to 1.36V
NOTICE:  PMIC: setup successful
NOTICE:  SCPI: dummy stub handler, implementation level: 00
INFO:BL3-1: Initializing runtime services
INFO:BL3-1: Preparing for EL3 exit to normal world
INFO:BL3-1: Next image address: 0x4a00, SPSR: 0x3c9


U-Boot 2017.07 (Oct 19 2017 - 19:48:49 +) Allwinner Technology

CPU:   Allwinner A64 (SUN50I)
Model: Pine64+
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Net:   No ethernet found.
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
reading /boot.scr
384 bytes read in 16 ms (23.4 KiB/s)
## Executing script at 4fc0
reading uImage
7090184 bytes read in 690 ms (9.8 MiB/s)
reading dtb
8592 bytes read in 27 ms (310.5 KiB/s)
## Flattened Device Tree blob at 4fa0
   Booting using the fdt blob at 0x4fa0
   Loading Device Tree to 49ffa000, end 49fff18f ... OK

Starting kernel ...

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.9.57 (buildbot@crazyhorse) (gcc version 5.5.0 
(LEDE GCC 5.5.0 r5117-fbde9ac) ) #0 SMP PREEMPT Thu Oct 19 

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

[Roman Yeryomin]

On 2017-10-16 23:30, Christian Lamparter wrote:

On Monday, October 16, 2017 10:10:52 PM CEST Roman Yeryomin wrote:

On 2017-10-16 20:32, Christian Lamparter wrote:
> Added John, maybe he has more comments.

(This time with the right mail address - sorry)


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


I don't think it needs some different board data.
bmi id is 17 for the board (taken from ART partition) which exists in 
board-2.bin
Also now, after fixing CPU speed (again), I'm getting 550Mbps which is 
close to max for open air tests.



I was going to deal with wifi related issues later.

Please don't defere the wireless issue. Fix it now.


Hm? Don't understand this.
There are a lot boards added with something not working. Double 
standards?

And in this case it was actually working.

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"."


I don't feed it with board.bin, you refer to irrelevant context.


and also:

"board-2 is a key-value store of actual board files. Some devices,


Exactly, that's why board-2.bin just works.


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.


I don't understand this.
I would rather clean this up now and move all the other calls lower. So 
they would fit at least some logic.



[...]


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

I didn't change that. And will not in v3, since I'm going to patch
qcom-ipq4019-ap.dk01.1-c1.dts

This has to be done! Again the usage-model.txt clearly states that:
"The 'compatible' property contains a sorted list of strings starting
with the *exact name of the machine*, followed by an optional list of
boards it is compatible with sorted from most compatible to least."
(Read the rest of 2.2 Platform Identification as well)


I think you forgot what you wrote yourself.
This is dtsi, for dts, the one which should be changed (as you noted 
yourself), I agree makes sense, but not dtsi.



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)


That's good, but I cannot rely on plans and have to add custom board 
identifier.
Once that's introduced he can change every user, as it's always done 
with many other different things.

Currently 01_preinit_do_ipq806x.sh overrides this:


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".


Sure, but again, not for dtsi

Actually it appeared that the board I have is AP-DK01.2-C1
All ref boards differ either with flash configuration 

Re: [LEDE-DEV] Support for TP-Link Archer C7 1750 v4.0

[Baptiste Jonglez]

Hi,

On 23-10-17, Emmanuel Grumbach wrote:
> I just bought a TP-Link Archer C7 AC1750 and got the v4.0 version. I
> haven't found any image in
> https://lede-project.org/toh/views/toh_fwdownload that claims it
> features that version. I can see v1 and v2, but not v4.

Support for this board has just been merged: 
https://git.lede-project.org/9887afb1afcf387f6892315413e610a6816df463

So, there is no support in 17.01 but snapshot images should work, and the
ToH at actually links to downloadable images :)

  https://lede-project.org/toh/hwdata/tp-link/tp-link_archer_c7_v

Baptiste


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

Re: [LEDE-DEV] [source] ar71xx: deactivate some boards with too small kernel partitions

[Matthias Schiffer]

-SNIP-

> 
>>   * ubnt-uap-pro
>>   * ubnt-unifi-outdoor-plus
> 
> No idea about these two.
> 

I have a UAP Outdoor+ here, I'll have a look at it soon-ish.

Matthias



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

[LEDE-DEV] [PATCH procd] add limits.h because it is needed for INT_MAX

[Johannes Wegener]

---
 trace/trace.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/trace/trace.c b/trace/trace.c
index 76b6b7f..c471e15 100644
--- a/trace/trace.c
+++ b/trace/trace.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 

 #ifndef PTRACE_EVENT_STOP
 /* PTRACE_EVENT_STOP is defined in linux/ptrace.h, but this header
-- 
2.14.2

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

[LEDE-DEV] [PATCH] iwinfo: add "PKG_MIRROR_HASH" to the Makefile

[Arjun AK]

>From 575a285f08501838596c34615568fe2559ec19fa Mon Sep 17 00:00:00 2001
From: Arjun AK 
Date: Mon, 23 Oct 2017 19:33:34 +0530
Subject: [PATCH] iwinfo: add "PKG_MIRROR_HASH" to the Makefile

Defining it will let the build tool download the tarball file from
a buildbot server, avoiding a clone of the source repo.

Signed-off-by: Arjun AK 
---
 package/network/utils/iwinfo/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/network/utils/iwinfo/Makefile b/package/network/utils/
iwinfo/Makefile
index a42aa13ee0..1b8a3ad2bc 100644
--- a/package/network/utils/iwinfo/Makefile
+++ b/package/network/utils/iwinfo/Makefile
@@ -13,6 +13,7 @@ PKG_SOURCE_PROTO:=git
 PKG_SOURCE_URL=$(LEDE_GIT)/project/iwinfo.git
 PKG_SOURCE_DATE:=2017-08-23
 PKG_SOURCE_VERSION:=c1a03e8231a5d8b348b70a182d256725c98a3b0b
+PKG_MIRROR_HASH:=7bd294f50f8ec8c0497c5fbe5527f3ae098814cdfeecf4ccf78a2a8937611664
 PKG_MAINTAINER:=Jo-Philipp Wich 
 PKG_LICENSE:=GPL-2.0
 
-- 
2.14.2



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

[LEDE-DEV] Support for TP-Link Archer C7 1750 v4.0

[Emmanuel Grumbach]

Hey there,

I just bought a TP-Link Archer C7 AC1750 and got the v4.0 version. I
haven't found any image in
https://lede-project.org/toh/views/toh_fwdownload that claims it
features that version. I can see v1 and v2, but not v4.

Has someone tried this? Can I install a v2 image?

Thanks :)

Emmanuel Grumbach
egrumb...@gmail.com

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

Re: [LEDE-DEV] meetup for beer in Prague

[Denis Periša]

Wish I could be there but it's getting snowy and my Transalp would be
a little too much for travel :D
Maybe next yr, Have a beer for me.. or dozen :D

On Mon, Oct 23, 2017 at 12:55 AM, Hauke Mehrtens  wrote:
> On 10/19/2017 10:18 PM, Hauke Mehrtens wrote:
>> On 10/18/2017 08:58 PM, Hauke Mehrtens wrote:
>>> Hi,
>>>
>>> We have ELCE and the OpenWrt summit next week in Prague and a lot of
>>> people will be there.
>>>
>>> I would like to have a meeting next Wednesday evening 25. October 2017
>>> in Prague, like we did it last year at c-base:
>>> http://lists.infradead.org/pipermail/lede-dev/2016-October/003229.html
>>>
>>> I do not know any locations in Prague so it would be nice if someone
>>> could help me with that. ;-)
>>>
>>> Who is interested in this and would join?
>>
>> Michael Richardson suggested this place from his IETF meetings:
>> https://goo.gl/R7hCEK
>> http://www.pivovarskyklub.com/
>>
>> It looks nice and they have a lot of beer and also food. They are open
>> till 11:30 PM. It is about 1.8 kilometers away from the conference hotel.
>>
>> The meetup will happen on Wednesday 25. October 2017 starting at 19:30
>> PM, you can also arrive later if you want.
>>
>> Please take part in this doodle if you want to participate, I would like
>> to know roughly who many people to expect and reserve accordingly:
>> https://doodle.com/poll/trw548epm4mcxvmr
>>
>> This is open for everyone and is not officially part of the OpenWrt
>> summit or ELCE.
>>
>> Hauke
>
> Hi all,
>
> everyone is invited to join this meeting and have some beer or other
> drinks, you do not need a ticket to ELCE or OpenWrt summit and this is
> not directly related to any of these events.
>
> I reserved for 15 people now, I would like you to still add your name or
> nick into the doodle so I can extend this in case it looks like more
> people will show up.
> https://doodle.com/poll/trw548epm4mcxvmr
>
>
> Hauke
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

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

Re: [LEDE-DEV] [source] ar71xx: deactivate some boards with too small kernel partitions

[Piotr Dymacz]

Hello Hauke,

AFAIK, "{image,kernel,rootfs} is too big" errors are/were just ignored 
before. As I understand this, with such approach, we can keep support 
for device and allow users to build images with custom configuration 
(different kernel options, set of packages, etc.) which makes image 
generation possible. If you look closer at the yesterday buildbot log 
[1], this was true for (some of) below devices (grep for "WARNING.*too 
big").


What I don't really understand here is why disabling image generation 
only for below boards made buildbot happy again if there are many other 
which have similar issues now [2] and are just ignored. How below boards 
were selected and why image for, for example "re450", wasn't disabled if 
it also fails?


Also, please have a look at my comments inline, below.

[1] 
http://phase1.builds.lede-project.org/builders/ar71xx%2Fgeneric/builds/388/steps/images/logs/stdio


[2] 
http://phase1.builds.lede-project.org/builders/ar71xx%2Fgeneric/builds/389/steps/images/logs/stdio


On 22.10.2017 23:19, LEDE Commits wrote:

hauke pushed a commit to source.git, branch master:
https://git.lede-project.org/f7a6fd31539be54d14d7c52b491b40b26bf8f740

commit f7a6fd31539be54d14d7c52b491b40b26bf8f740
Author: Hauke Mehrtens 
AuthorDate: Sun Oct 22 23:10:08 2017 +0200

 ar71xx: deactivate some boards with too small kernel partitions
 
 This affects the following boards:

  * dr344


The only way to fix this one I can think about, is to change mtd order 
(use kernel/rootfs instead of rootfs/kernel). But this would break 
backward compatibility and require change of "bootcmd" variable in 
U-Boot environment _before_ upgrade to new image.



  * archer-c58-v1
  * archer-c60-v1
  * tl-wr902ac-v1
  * tl-wr942n-v1


These should be easily fixable. They use TP-Link "safeloader" image type 
with kernel/rootfs order (os-image/file-system), so we can increase 
kernel partition size and reduce the rootfs.



  * ubnt-uap-pro
  * ubnt-unifi-outdoor-plus


No idea about these two.

--
Cheers,
Piotr

 
 The build fails for any of these boards because the resulting kernel

 image will not fit into the kernel partition.
 
 When CONFIG_KERNEL_KALLSYMS  is not set it could be that the kernel will

 fit onto the board again, this is the case for release images.
 
 Signed-off-by: Hauke Mehrtens 

---
  target/linux/ar71xx/image/generic.mk | 1 -
  target/linux/ar71xx/image/tp-link.mk | 5 ++---
  target/linux/ar71xx/image/ubnt.mk| 1 -
  3 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/target/linux/ar71xx/image/generic.mk 
b/target/linux/ar71xx/image/generic.mk
index 6f5a701..3c5fcc3 100644
--- a/target/linux/ar71xx/image/generic.mk
+++ b/target/linux/ar71xx/image/generic.mk
@@ -358,7 +358,6 @@ define Device/dr344
MTDPARTS := 
spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,6336k(rootfs),1408k(kernel),64k(nvram),64k(art)ro,7744k@0x5(firmware)
IMAGE/sysupgrade.bin := append-rootfs | pad-rootfs | pad-to 
(ROOTFS_SIZE) | append-kernel | check-size (IMAGE_SIZE)
  endef
-TARGET_DEVICES += dr344
  
  define Device/dr531

DEVICE_TITLE := Wallys DR531
diff --git a/target/linux/ar71xx/image/tp-link.mk 
b/target/linux/ar71xx/image/tp-link.mk
index ae711e7..868bbda 100644
--- a/target/linux/ar71xx/image/tp-link.mk
+++ b/target/linux/ar71xx/image/tp-link.mk
@@ -150,7 +150,7 @@ define Device/archer-c60-v1
MTDPARTS := 
spi0.0:64k(u-boot)ro,64k(mac)ro,1344k(kernel),6592k(rootfs),64k(tplink)ro,64k(art)ro,7936k@0x2(firmware)
SUPPORTED_DEVICES := archer-c60-v1
  endef
-TARGET_DEVICES += archer-c25-v1 archer-c58-v1 archer-c59-v1 archer-c60-v1
+TARGET_DEVICES += archer-c25-v1 archer-c59-v1
  
  define Device/archer-c5-v1

$(Device/tplink-16mlzma)
@@ -1043,7 +1043,6 @@ define Device/tl-wr902ac-v1
append-metadata | check-size (IMAGE_SIZE)
MTDPARTS := spi0.0:128k(u-boot)ro,7360k(firmware),640k(tplink)ro,64k(art)ro
  endef
-TARGET_DEVICES += tl-wr902ac-v1
  
  define Device/tl-wr940n-v4

$(Device/tplink-4mlzma)
@@ -1118,4 +1117,4 @@ define Device/tl-wr942n-v1
MTDPARTS := 
spi0.0:128k(u-boot)ro,1344k(kernel),13120k(rootfs),64k(product-info)ro,64k(partition-table)ro,256k(oem-config)ro,1344k(oem-vars)ro,64k(ART)ro,14464k@0x2(firmware)
SUPPORTED_DEVICES := tl-wr942n-v1
  endef
-TARGET_DEVICES += tl-wr940n-v4 tl-wr941nd-v2 tl-wr941nd-v3 tl-wr941nd-v4 
tl-wr941nd-v5 tl-wr941nd-v6 tl-wr941nd-v6-cn tl-wr942n-v1
+TARGET_DEVICES += tl-wr940n-v4 tl-wr941nd-v2 tl-wr941nd-v3 tl-wr941nd-v4 
tl-wr941nd-v5 tl-wr941nd-v6 tl-wr941nd-v6-cn
diff --git a/target/linux/ar71xx/image/ubnt.mk 
b/target/linux/ar71xx/image/ubnt.mk
index f80f2f1..dfc795b 100644
--- a/target/linux/ar71xx/image/ubnt.mk
+++ b/target/linux/ar71xx/image/ubnt.mk
@@ -256,4 +256,3 @@ define Device/ubnt-unifi-outdoor-plus
BOARDNAME := UBNT-UOP
DEVICE_PROFILE := UBNT
  endef
-TARGET_DEVICES += 

Re: [LEDE-DEV] [PATCH 9/9] ar71xx: add support for Comfast E214N V2 Outdoor CPE

[Piotr Dymacz]

Hello Zoltan,

On 22.10.2017 22:21, Zoltan HERPAI wrote:

Based on Robert Budde's patch, with additional reworks.
https://github.com/openwrt/openwrt/pull/390

Signed-off-by: Zoltan HERPAI 
---
  target/linux/ar71xx/base-files/etc/board.d/01_leds |  10 ++
  target/linux/ar71xx/base-files/lib/ar71xx.sh   |   3 +
  .../ar71xx/base-files/lib/upgrade/platform.sh  |   1 +
  target/linux/ar71xx/config-4.4 |   1 +
  target/linux/ar71xx/config-4.9 |   1 +
  .../ar71xx/files/arch/mips/ath79/Kconfig.openwrt   |   8 ++
  target/linux/ar71xx/files/arch/mips/ath79/Makefile |   1 +
  .../files/arch/mips/ath79/mach-cf-e214n-v2.c   | 124 +
  .../linux/ar71xx/files/arch/mips/ath79/machtypes.h |   1 +
  target/linux/ar71xx/image/generic.mk   |   8 ++
  10 files changed, 158 insertions(+)
  create mode 100644 
target/linux/ar71xx/files/arch/mips/ath79/mach-cf-e214n-v2.c


We have some COMFAST devices already supported under ar71xx target in 
LEDE and as they are very similar, support for all of them (IIRC) is 
kept in single mach file [1]. This limits code duplication, e.g. for 
their external watchdog, network initialization, etc.


Also, after a brief review, I found some issues here:
- LED names don't follow general naming convention (color is missing)
- support for reset button is missing
- COMFAST keeps ART copy in last 64 KB mtd partition, thus we have a 
"art-backup" partition defined [2], not "nvram" as in the patch


Personally, I would prefer to include support for this model in the same 
way as we did for rest from this vendor. How would you like to proceed 
with this one then?


--
Cheers,
Piotr

[1] 
https://github.com/lede-project/source/blob/master/target/linux/ar71xx/files/arch/mips/ath79/mach-cf-e316n-v2.c


[2] 
https://github.com/lede-project/source/blob/master/target/linux/ar71xx/image/generic.mk#L142




diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds 
b/target/linux/ar71xx/base-files/etc/board.d/01_leds
index 27e6c8a..5707624 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -182,6 +182,16 @@ carambola2)
ucidef_set_led_netdev "wan" "WAN" "$board:orange:eth1" "eth1"
ucidef_set_led_wlan "wlan" "WLAN" "$board:green:wlan" "phy0tpt"
;;
+cf-e214n-v2)
+   ucidef_set_led_netdev "lan" "LAN" "$board:lan" "eth0"
+   ucidef_set_led_netdev "wan" "WAN" "$board:wan" "eth1"
+   ucidef_set_led_wlan "wlan" "WLAN" "$board:wlan" "phy0tpt"
+   ucidef_set_rssimon "wlan" "20" "1"
+   ucidef_set_led_rssi "rssilow" "RSSILOW" "$board:link1" "wlan" "1" "100" "0" 
"13"
+   ucidef_set_led_rssi "rssimediumlow" "RSSIMEDIUMLOW" "$board:link2" "wlan" "26" "100" 
"-25" "13"
+   ucidef_set_led_rssi "rssimediumhigh" "RSSIMEDIUMHIGH" "$board:link3" "wlan" "51" "100" 
"-50" "13"
+   ucidef_set_led_rssi "rssihigh" "RSSIHIGH" "$board:link4" "wlan" "76" "100" "-75" 
"13"
+   ;;
  cf-e316n-v2)
ucidef_set_led_netdev "lan" "LAN" "$board:blue:lan" "eth0"
ucidef_set_led_netdev "wan" "WAN" "$board:blue:wan" "eth1"
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh 
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index bdba81b..1c1317d 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -504,6 +504,9 @@ ar71xx_board_detect() {
*"Carambola2"*)
name="carambola2"
;;
+   *"CF-E214N v2")
+   name="cf-e214n-v2"
+   ;;
*"CF-E316N v2")
name="cf-e316n-v2"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh 
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index a60e44c..e768386 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -215,6 +215,7 @@ platform_check_image() {
bullet-m|\
c-55|\
carambola2|\
+   cf-e214n-v2|\
cf-e316n-v2|\
cf-e320n-v2|\
cf-e355ac|\
diff --git a/target/linux/ar71xx/config-4.4 b/target/linux/ar71xx/config-4.4
index 4793bf4..d8f94e3 100644
--- a/target/linux/ar71xx/config-4.4
+++ b/target/linux/ar71xx/config-4.4
@@ -67,6 +67,7 @@ CONFIG_ATH79_MACH_C55=y
  CONFIG_ATH79_MACH_CAP324=y
  CONFIG_ATH79_MACH_CAP4200AG=y
  CONFIG_ATH79_MACH_CARAMBOLA2=y
+CONFIG_ATH79_MACH_CF_E214N_V2=y
  CONFIG_ATH79_MACH_CF_E316N_V2=y
  CONFIG_ATH79_MACH_CF_E320N_V2=y
  CONFIG_ATH79_MACH_CF_E355AC=y
diff --git a/target/linux/ar71xx/config-4.9 b/target/linux/ar71xx/config-4.9
index 285c638..df90b20 100644
--- a/target/linux/ar71xx/config-4.9
+++ b/target/linux/ar71xx/config-4.9
@@ -66,6 +66,7 @@ CONFIG_ATH79_MACH_C55=y
  CONFIG_ATH79_MACH_CAP324=y
  CONFIG_ATH79_MACH_CAP4200AG=y
  CONFIG_ATH79_MACH_CARAMBOLA2=y
+CONFIG_ATH79_MACH_CF_E214N_V2=y
  

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

[p . wassi]

Hi,
 
> > - https://github.com/openwrt/openwrt/pull/539
> > Add TL-WA901v5 support
> 
> The GCC 7 patches are probably already in, but the target commit looks
> ok to me, but I am not a ar71xx expert.

Yesterday, I came across a TL-WA901v5 and did a PR on LEDE github, without 
knowing that
someone already started on the OpenWrt side ;-)
The OpenWrt PR adds another mach-*-v5 file, which basically is a copy of the 
mach-*-v4.
Since both boards are identical in HW (used CPU, RAM, Flash, WLAN, GPIO 
assignments),
I've just added another MIPS_MACHINE in the existing mach-*-v4 file without 
introducing
a clone there.
However, as the OEM bootloader requires the image to have the correct HW-ID 
(09010005), we
still need to make a seperate image for these devices.
Flashing is successfully tested via TFTP, like for the -v4 unit as described in 
[1]
You can find the LEDE PR at [2] - everything is compile-tested and run-tested 
on real HW.

Best regards,
P. Wassi

[1]:
https://forum.openwrt.org/viewtopic.php?pid=320942#p320942

[2]:
https://github.com/lede-project/source/pull/1446

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

Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 8/9] ramips: add Devolo WiFi Repeater (mt2681)

[Zoltan HERPAI]

Hi Mathias,

On Mon, 23 Oct 2017, Mathias Kresin wrote:


22.10.2017 22:21, Zoltan HERPAI:
This is pretty much the same as the ALL0256N-8M but with different LED 
settings.


Based on Matt Jenkins' patch, with additional reworks.
https://github.com/openwrt/openwrt/pull/491

Signed-off-by: Zoltan HERPAI 


Hey Zoltan,

I'm not sure how proceed with the patch. It has bunch of issues and if 
someone else would send this patch I wouldn't merge it as it is.


Some of the issues are:

- missing hardware description in the commit message
- missing initial install instructions in the commit message
- bad board naming (the name looks like a mediatek reference board)
- wrong use of wifi led
- outdated syntax in the dts

Since you most likely do not have this board, I'm not sure if it does make 
any sense to do the full review => request changes cycle.


Any suggestions how to proceed with this one?


Correct, I don't have the hardware, and the HW descriptions I've found on 
google are misleading. I'm leaning more towards dropping this, and if 
someone wants support for it, he/she can prep the patch correctly.


-w-

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

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

[Zoltan HERPAI]

Hi Mathias,

On Mon, 23 Oct 2017, Mathias Kresin wrote:


22.10.2017 22:56, Hauke Mehrtens:

On 10/22/2017 10:28 PM, Zoltan HERPAI wrote:

Hi,




- https://github.com/openwrt/openwrt/pull/312
ar71xx: add support for Zsun WiFi SD Card Reader


This is missing a Singed-of-by line


A few days ago a similar PR was created (and unfortunately already 
closed): https://github.com/lede-project/source/pull/1422.


The OpenWrt PR has a lot of issues, like enabling unencrypted wireless 
for the whole target.


"- #5 needs some work as it has some dirty hacks. This can be taken care on 
the summit's second day - I recall someone going there has a ZSun reader"


So, fully agree, I could have written s/some work/full rework/. If n0p 
doesn't come back with the fixes by the summit, we could take care of 
adding the support there, with the actual hardware to test.


-w-

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

Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 8/9] ramips: add Devolo WiFi Repeater (mt2681)

[Mathias Kresin]

22.10.2017 22:21, Zoltan HERPAI:

This is pretty much the same as the ALL0256N-8M but with different LED settings.

Based on Matt Jenkins' patch, with additional reworks.
https://github.com/openwrt/openwrt/pull/491

Signed-off-by: Zoltan HERPAI 


Hey Zoltan,

I'm not sure how proceed with the patch. It has bunch of issues and if 
someone else would send this patch I wouldn't merge it as it is.


Some of the issues are:

- missing hardware description in the commit message
- missing initial install instructions in the commit message
- bad board naming (the name looks like a mediatek reference board)
- wrong use of wifi led
- outdated syntax in the dts

Since you most likely do not have this board, I'm not sure if it does 
make any sense to do the full review => request changes cycle.


Any suggestions how to proceed with this one?

Mathias

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

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

[Mathias Kresin]

22.10.2017 22:56, Hauke Mehrtens:

On 10/22/2017 10:28 PM, Zoltan HERPAI wrote:

Hi,

Zoltan HERPAI wrote:

Hi Hauke,

On Sun, 22 Oct 2017, Hauke Mehrtens wrote:


I am working on merging the missing commits from the OpenWrt git
repository into the LEDE repository.

Here is a list of all non merge commits from the OpenWrt git repository
and their corresponding LEDE commit IDs:
https://github.com/hauke/openwrt-lede-merge/blob/master/commits.csv

I only looked into the non merge commits and assumed that commits with
the same title are the same, if this is wrong please point me to some
place where this causes problems.

I used this script to generate the csv table:
https://github.com/hauke/openwrt-lede-merge/blob/master/openwrt-merge.py

The bigger topics I see are:
* addition of SoCFPGA target with kernel 4.4 support
* Will someone port this to kernel 4.9 or provide me with hardware so I
   can try to port this and test it?
* There are some commits without a Signed-off-by line, I will contact
  the authors.
* The realview target was removed from LEDE, but it got an update to
  kernel 4.4 in OpenWrt, how do we want to handle this? Does anyone need
  the realview target?


As discussed earlier, I've prepared manually a list of commits that
are missing from LEDE. I was about to send:

  - a set of patches that probably don't need any discussion and can be
merged right away,
  - a set of patches that are RFC, and should be discussed.

Let me know if that should still happen.

The series has been sent as discussed on irc. I don't recall any more
required - also based on checking the CSV, thanks for prepping that.

The RFC patches/PRs are:




...


- https://github.com/openwrt/openwrt/pull/312
ar71xx: add support for Zsun WiFi SD Card Reader


This is missing a Singed-of-by line


A few days ago a similar PR was created (and unfortunately already 
closed): https://github.com/lede-project/source/pull/1422.


The OpenWrt PR has a lot of issues, like enabling unencrypted wireless 
for the whole target.





https://github.com/openwrt/openwrt/commit/4f997727aef0603f02e9320ba787ea1b894747c0

lantiq: td-w8980: fix failsafe mode via ethernet.


This looks correct to me, but I do not have this board.


This one isn't required. The wrong interface in failsafe was fixed for 
the whole target with f080cfab72d8801856fa01f0476f1fc9b920a9d9.


Mathias

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