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

[Álvaro Fernández Rojas]

Applied, thanks!


El 17/12/2017 a las 15:18, Christian Lamparter escribió:

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



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

Re: [LEDE-DEV] Policies for changes to LEDE stable branches, or LEDE patches in general?

[Álvaro Fernández Rojas]

Hi Bjørn,

El 25/04/2017 a las 13:43, Bjørn Mork escribió:
> Hello,
> 
> I note that a recent commit to the lede-17.01 branch has added a few
> driver patches which have barely hit the mainline kernel:
> 
> https://github.com/lede-project/source/commit/1ab41265c39354332630bcba0ec704abd2e790f0
> 
> This surprised me quite a bit.  I would expect any such fixes to go the
> normal route from mainline to stable to LEDE, like they do for most
> other current distros. This usually does not take more than a couple of
> weeks anyway, and less if a fix is critical.
You're right, but we're dealing with something that has been accepted upstream 
and has been tested and discussed by several developers, and I don't think that 
waiting for a fix to come from linux-stable is mandatory (@lede-dev correct me 
if I'm wrong).

> 
> It was surprising enough that this hit the master branch.  But going
> into a stable LEDE branch before davem has considered it for stable
> kernels?  Why?
Because it fixes a long standing bug for the Raspberry Pi (and any other 
devices bridging interfaces that rely on drivers that alter sk_buff data 
without duplicating its content).

As far as I know, only fixes can be pushed to stable branches.
You're right, davem hasn't yet considered it for stable branches, but in this 
case the patch has been tested by quite a lot of users (Raspberry Pi 
community), and I thought this was sufficient to consider it stable (BTW, I've 
also tested it myself).

> 
> And then there is the issue of making LEDE patches for fixes which can
> be, or already are, upstream: Is that wise use of resources? Reading
> https://lede-project.org/docs/guide-developer/the-source-code I see that
> I am wrong thinking that there are policies for this.
> 
> But maybe there should be?
> 
> 
> 
> Bjørn
> 

~Álvaro.

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

Re: [LEDE-DEV] [PATCH] brcm2708: backport upstream thermal driver

[Álvaro Fernández Rojas]

Maybe you should also provide a new kernel module in modules.mk for this one...

Acked-by: Álvaro Fernández Rojas <nolt...@gmail.com>

El 02/04/2017 a las 0:34, Rafał Miłecki escribió:
> From: Rafał Miłecki <ra...@milecki.pl>
> 
> Signed-off-by: Rafał Miłecki <ra...@milecki.pl>
> ---
>  ...cm2835-add-thermal-driver-for-bcm2835-SoC.patch | 365 
> +
>  1 file changed, 365 insertions(+)
>  create mode 100644 
> target/linux/brcm2708/patches-4.9/081-0001-thermal-bcm2835-add-thermal-driver-for-bcm2835-SoC.patch
> 
> diff --git 
> a/target/linux/brcm2708/patches-4.9/081-0001-thermal-bcm2835-add-thermal-driver-for-bcm2835-SoC.patch
>  
> b/target/linux/brcm2708/patches-4.9/081-0001-thermal-bcm2835-add-thermal-driver-for-bcm2835-SoC.patch
> new file mode 100644
> index 00..a11c542913
> --- /dev/null
> +++ 
> b/target/linux/brcm2708/patches-4.9/081-0001-thermal-bcm2835-add-thermal-driver-for-bcm2835-SoC.patch
> @@ -0,0 +1,365 @@
> +From bcb7dd9ef206f7d646ed8dac6fe7772083714253 Mon Sep 17 00:00:00 2001
> +From: Stefan Wahren <stefan.wah...@i2se.com>
> +Date: Fri, 31 Mar 2017 20:03:06 +
> +Subject: [PATCH] thermal: bcm2835: add thermal driver for bcm2835 SoC
> +MIME-Version: 1.0
> +Content-Type: text/plain; charset=UTF-8
> +Content-Transfer-Encoding: 8bit
> +
> +Add basic thermal driver for bcm2835 SoC.
> +
> +This driver currently make sure that tsense HW block is set up
> +correctly.
> +
> +Tested-by: Rafał Miłecki <ra...@milecki.pl>
> +Signed-off-by: Martin Sperl <ker...@martin.sperl.org>
> +Signed-off-by: Stefan Wahren <stefan.wah...@i2se.com>
> +Acked-by: Eric Anholt <e...@anholt.net>
> +Acked-by: Eduardo Valentin <edubez...@gmail.com>
> +Signed-off-by: Eduardo Valentin <edubez...@gmail.com>
> +---
> + drivers/thermal/Kconfig   |   8 +
> + drivers/thermal/Makefile  |   1 +
> + drivers/thermal/bcm2835_thermal.c | 314 
> ++
> + 3 files changed, 323 insertions(+)
> + create mode 100644 drivers/thermal/bcm2835_thermal.c
> +
> +--- a/drivers/thermal/Kconfig
>  b/drivers/thermal/Kconfig
> +@@ -434,4 +434,12 @@ depends on (ARCH_QCOM && OF) || COMPILE_
> + source "drivers/thermal/qcom/Kconfig"
> + endmenu
> + 
> ++config BCM2835_THERMAL
> ++tristate "Thermal sensors on bcm2835 SoC"
> ++depends on ARCH_BCM2835 || COMPILE_TEST
> ++depends on HAS_IOMEM
> ++depends on THERMAL_OF
> ++help
> ++  Support for thermal sensors on Broadcom bcm2835 SoCs.
> ++
> + endif
> +--- a/drivers/thermal/Makefile
>  b/drivers/thermal/Makefile
> +@@ -55,3 +55,4 @@ obj-$(CONFIG_TEGRA_SOCTHERM)   += tegra/
> + obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
> + obj-$(CONFIG_MTK_THERMAL)   += mtk_thermal.o
> + obj-$(CONFIG_GENERIC_ADC_THERMAL)   += thermal-generic-adc.o
> ++obj-$(CONFIG_BCM2835_THERMAL)   += bcm2835_thermal.o
> +--- /dev/null
>  b/drivers/thermal/bcm2835_thermal.c
> +@@ -0,0 +1,314 @@
> ++/*
> ++ * Driver for Broadcom BCM2835 SoC temperature sensor
> ++ *
> ++ * Copyright (C) 2016 Martin Sperl
> ++ *
> ++ * This program is free software; you can redistribute it and/or modify
> ++ * it under the terms of the GNU General Public License as published by
> ++ * the Free Software Foundation; either version 2 of the License, or
> ++ * (at your option) any later version.
> ++ *
> ++ * This program is distributed in the hope that it will be useful,
> ++ * but WITHOUT ANY WARRANTY; without even the implied warranty of
> ++ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> ++ * GNU General Public License for more details.
> ++ */
> ++
> ++#include 
> ++#include 
> ++#include 
> ++#include 
> ++#include 
> ++#include 
> ++#include 
> ++#include 
> ++#include 
> ++#include 
> ++#include 
> ++#include 
> ++
> ++#define BCM2835_TS_TSENSCTL 0x00
> ++#define BCM2835_TS_TSENSSTAT0x04
> ++
> ++#define BCM2835_TS_TSENSCTL_PRWDW   BIT(0)
> ++#define BCM2835_TS_TSENSCTL_RSTBBIT(1)
> ++
> ++/*
> ++ * bandgap reference voltage in 6 mV increments
> ++ * 000b = 1178 mV, 001b = 1184 mV, ... 111b = 1220 mV
> ++ */
> ++#define BCM2835_TS_TSENSCTL_CTRL_BITS   3
> ++#define BCM2835_TS_TSENSCTL_CTRL_SHIFT  2
> ++#define BCM2835_TS_TSENSCTL_CTRL_MASK   \
> ++GENMASK(BCM2835_TS_TSENSCTL_CTRL_BITS + \
> ++BCM2835_TS_TSENSCTL_CTRL_SHIFT - 1, \
> ++BCM2835_TS_TSENSCTL_CTRL_SHIFT)
> ++#define BCM2835_TS_TSENSCTL_CTRL_DEFAULT1
> ++#d

Re: [LEDE-DEV] [PATCH] brcm2708: backport upstream sdhost controller driver

[Álvaro Fernández Rojas]

You only added CONFIG_MMC_BCM2835_UPSTREAM symbol for bcm2708, missing bcm2709 
and bcm2710, which will break buildbot for those subtargets.

Apart from that, what's the purpose of adding a disabled driver?
Maybe you should create a branch in your staging repo in which this driver is 
enabled by default, in order to see if it works or not.

El 01/04/2017 a las 15:30, Rafał Miłecki escribió:
> From: Rafał Miłecki 
> 
> Signed-off-by: Rafał Miłecki 
> ---
>  target/linux/brcm2708/bcm2708/config-4.9   |1 +
>  ...-Add-new-driver-for-the-sdhost-controller.patch | 1536 
> 
>  ...-Fix-possible-NULL-ptr-dereference-in-bcm.patch |   30 +
>  ...-rename-Kconfig-symbol-to-avoid-downstrea.patch |   40 +
>  4 files changed, 1607 insertions(+)
>  create mode 100644 
> target/linux/brcm2708/patches-4.9/080-0001-mmc-bcm2835-Add-new-driver-for-the-sdhost-controller.patch
>  create mode 100644 
> target/linux/brcm2708/patches-4.9/080-0002-mmc-bcm2835-Fix-possible-NULL-ptr-dereference-in-bcm.patch
>  create mode 100644 
> target/linux/brcm2708/patches-4.9/080-0100-mmc-bcm2835-rename-Kconfig-symbol-to-avoid-downstrea.patch
> 
> diff --git a/target/linux/brcm2708/bcm2708/config-4.9 
> b/target/linux/brcm2708/bcm2708/config-4.9
> index c1bed074c3..76dd1fde18 100644
> --- a/target/linux/brcm2708/bcm2708/config-4.9
> +++ b/target/linux/brcm2708/bcm2708/config-4.9
> @@ -251,6 +251,7 @@ CONFIG_MMC_BCM2835=y
>  CONFIG_MMC_BCM2835_DMA=y
>  CONFIG_MMC_BCM2835_PIO_DMA_BARRIER=2
>  CONFIG_MMC_BCM2835_SDHOST=y
> +# CONFIG_MMC_BCM2835_UPSTREAM is not set
>  CONFIG_MMC_BLOCK=y
>  CONFIG_MMC_BLOCK_MINORS=32
>  CONFIG_MMC_SDHCI=y
> diff --git 
> a/target/linux/brcm2708/patches-4.9/080-0001-mmc-bcm2835-Add-new-driver-for-the-sdhost-controller.patch
>  
> b/target/linux/brcm2708/patches-4.9/080-0001-mmc-bcm2835-Add-new-driver-for-the-sdhost-controller.patch
> new file mode 100644
> index 00..2c0238cad9
> --- /dev/null
> +++ 
> b/target/linux/brcm2708/patches-4.9/080-0001-mmc-bcm2835-Add-new-driver-for-the-sdhost-controller.patch
> @@ -0,0 +1,1536 @@
> +From a7d3e315a02c3154c38d09e51fc9461ba2cac396 Mon Sep 17 00:00:00 2001
> +From: Eric Anholt 
> +Date: Wed, 8 Mar 2017 10:19:03 +0100
> +Subject: [PATCH] mmc: bcm2835: Add new driver for the sdhost controller.
> +
> +The 2835 has two SD controllers: The Arasan sdhci controller (supported
> +by the iproc driver) and a custom sdhost controller.  This patch adds a
> +driver for the latter.
> +
> +The sdhci controller supports both sdcard and sdio.  The sdhost
> +controller supports the sdcard only, but has better performance.  Also
> +note that the rpi3 has sdio wifi, so driving the sdcard with the sdhost
> +controller allows to use the sdhci controller for wifi support.
> +
> +The configuration is done by devicetree via pin muxing.  Both SD
> +controller are available on the same pins (2 pin groups = pin 22 to 27 +
> +pin 48 to 53).  So it's possible to use both SD controllers at the same
> +time with different pin groups.
> +
> +The code was originally written by Phil Elwell in the downstream
> +Rasbperry Pi tree.   In preparation for the upstream merge it was
> +cleaned up and the code base was moderized by Eric Anholt, Stefan
> +Wahren and Gerd Hoffmann.
> +
> +Signed-off-by: Eric Anholt 
> +Signed-off-by: Stefan Wahren 
> +Signed-off-by: Gerd Hoffmann 
> +Signed-off-by: Ulf Hansson 
> +---
> + drivers/mmc/host/Kconfig   |   14 +
> + drivers/mmc/host/Makefile  |1 +
> + drivers/mmc/host/bcm2835.c | 1465 
> 
> + 3 files changed, 1480 insertions(+)
> + create mode 100644 drivers/mmc/host/bcm2835.c
> +
> +--- a/drivers/mmc/host/Kconfig
>  b/drivers/mmc/host/Kconfig
> +@@ -769,6 +769,20 @@ config MMC_TOSHIBA_PCI
> + depends on PCI
> + help
> + 
> ++config MMC_BCM2835
> ++tristate "Broadcom BCM2835 SDHOST MMC Controller support"
> ++depends on ARCH_BCM2835 || COMPILE_TEST
> ++depends on HAS_DMA
> ++help
> ++  This selects the BCM2835 SDHOST MMC controller. If you have
> ++  a BCM2835 platform with SD or MMC devices, say Y or M here.
> ++
> ++  Note that the BCM2835 has two SD controllers: The Arasan
> ++  sdhci controller (supported by MMC_SDHCI_IPROC) and a custom
> ++  sdhost controller (supported by this driver).
> ++
> ++  If unsure, say N.
> ++
> + config MMC_MTK
> + tristate "MediaTek SD/MMC Card Interface support"
> + depends on HAS_DMA
> +--- a/drivers/mmc/host/Makefile
>  b/drivers/mmc/host/Makefile
> +@@ -57,6 +57,7 @@ obj-$(CONFIG_MMC_MOXART)   += moxart-mmc.o
> + obj-$(CONFIG_MMC_SUNXI) += sunxi-mmc.o
> + obj-$(CONFIG_MMC_USDHI6ROL0)+= usdhi6rol0.o
> + obj-$(CONFIG_MMC_TOSHIBA_PCI)   += toshsd.o
> ++obj-$(CONFIG_MMC_BCM2835)   += bcm2835.o
> + 
> + obj-$(CONFIG_MMC_REALTEK_PCI)  

Re: [LEDE-DEV] [PATCH] brcm2708: include upstream bcm2835-rpi-zero DT binary in image

[Álvaro Fernández Rojas]

NACK,

If you want to test something with the alternative device trees then you can 
modify a single line while doing so.

Apart from that there are other alternative device trees for the other models, 
so why only adding the pi-zero one?
I guess because that's the one you're using for testing...

BTW, there's another way of using those alternative device trees without adding 
them to config.txt: using --283x when generating the kernel image:
https://github.com/raspberrypi/linux/blob/rpi-4.9.y/scripts/mkknlimg#L47

El 31/03/2017 a las 22:42, Rafał Miłecki escribió:
> From: Rafał Miłecki 
> 
> This allows easier testing/developing/debugging of upstream DTS file.
> Foundation's start.elf doesn't use it on its own so this won't cause any
> regressions. Testing this DTB requires using U-Boot or adding
> device_tree entry to the config.txt.
> 
> Signed-off-by: Rafał Miłecki 
> ---
>  target/linux/brcm2708/image/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/target/linux/brcm2708/image/Makefile 
> b/target/linux/brcm2708/image/Makefile
> index 7909c6d814..9c048f5e33 100644
> --- a/target/linux/brcm2708/image/Makefile
> +++ b/target/linux/brcm2708/image/Makefile
> @@ -56,7 +56,7 @@ 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
> +  DEVICE_DTS := bcm2708-rpi-b bcm2708-rpi-b-plus bcm2708-rpi-cm 
> bcm2708-rpi-0-w bcm2835-rpi-zero
>  endef
>  ifeq ($(SUBTARGET),bcm2708)
>TARGET_DEVICES += rpi
> 

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

Re: [LEDE-DEV] [PATCH] brcm2708: include upstream bcm2835-rpi-zero DT binary in image

[Álvaro Fernández Rojas]

Hi Rafał,

Yeah, you're right, but I've been busy with other stuff and I didn't want to 
reply until I had tested your patches.
I will reply now but I haven't been able to test them yet.

Regards,
Álvaro.

El 14/04/2017 a las 0:27, Rafał Miłecki escribió:
> Hi Alvaro,
> 
> On 03/31/2017 10:42 PM, Rafał Miłecki wrote:
>> From: Rafał Miłecki 
>>
>> This allows easier testing/developing/debugging of upstream DTS file.
>> Foundation's start.elf doesn't use it on its own so this won't cause any
>> regressions. Testing this DTB requires using U-Boot or adding
>> device_tree entry to the config.txt.
>>
>> Signed-off-by: Rafał Miłecki 
> 
> I didn't get any response for this or 2 another brcm2708 patches for 2 weeks.
> 
> You are brcm2708 maintainer so I didn't want to push them without your ack but
> I also can't work on brcm2708 having to wait that long every time.
> 
> Would some other solution work for you maybe? Would you be able to provide
> quicker replies or maybe could you give me a green light for pushing brcm2708
> changes on my own?
> 
> Please don't get this question wrong, there is no offence, I'm just looking
> for something that would work well for both of us :)

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

Re: [LEDE-DEV] [PATCH] brcm2708: rename all patches from raspberrypi git tree to use 999 prefix

[Álvaro Fernández Rojas]

El 23/03/2017 a las 18:38, Rafał Miłecki escribió:
> On 2017-03-23 18:29, Felix Fietkau wrote:
>> On 2017-03-22 21:36, Rafał Miłecki wrote:
>>> From: Rafał Miłecki 
>>>
>>> Right now all brcm2708 patches are extracted from the non-mainline
>>> raspberrypi/linux git tree. Many of them are hacks and/or are unneeded
>>> in LEDE. Raspberry Pi is getting better and better mainline support so
>>> it would be nice to finally start maintaining patches in a cleaner way:
>>> 1) Backport patches accepted in upstream tree
>>> 2) Start using upstream drivers
>>> 3) Pick only these patches that are needed for more complete support
>>>
>>> Handling above tasks requires grouping patches - ideally using the same
>>> prefixes as generic ones. It means we should rename existing patches to
>>> use some high prefix. This will allow e.g. use 0xx for backported code.
>> I agree with the split, but could you please use a number much lower
>> than 999? ;)
I also agree with the split, but I have to warn you that I may not be able to 
achieve this right now since I haven't got much free time lately...

> 
> I'd like to have "access" to all standard prefixes:
> 
> 0xx - upstream backports
> 1xx - code awaiting upstream merge
> 2xx - kernel build / config / header patches
> 3xx - architecture specific patches
> 4xx - mtd related patches (subsystem and drivers)
> 5xx - filesystem related patches
> 6xx - generic network patches
> 7xx - network / phy driver patches
> 8xx - other drivers
> 9xx - uncategorized other patches
I think those patches fit into the "uncategorized other patches" category so 
why don't we use 900-?

> 
> and have these patches applied on top of everything else.
> 
> Would something like 950 be a better choice?
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

~ Álvaro.

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

Re: [LEDE-DEV] Compile error on Raspberri Pi 3

[Álvaro Fernández Rojas]

Hello,

That's weird because neither the buildbot nor my local setup are failing.
Could you try again with a clean checkout of LEDE?
Which distro are you using?

Regards,
Álvaro.

El 23/02/2017 a las 13:35, Perry Couprie escribió:
> Hi,
> 
> Ik compiled lede for raspberri pi 2 and it compiled.
> 
> When i try to compile it for raspberri pi 3, it get the following compile 
> error:
> 
> What can i do to fix this ?
> 
> Perry
> 
>   CHK include/generated/asm-offsets.h
>   UPD include/generated/asm-offsets.h
>   CALLscripts/checksyscalls.sh
>   HOSTCC  scripts/dtc/dtc-parser.tab.o
>   HOSTCC  scripts/kallsyms
>   HOSTCC  scripts/pnmtologo
>   HOSTLD  scripts/mod/modpost
>   HOSTCC  scripts/conmakehash
>   HOSTLD  scripts/dtc/dtc
>   HOSTCC  scripts/sortextable
>   LDS arch/arm64/kernel/vdso/vdso.lds
>   VDSOA   arch/arm64/kernel/vdso/gettimeofday.o
> cc1: fatal error: symtab.h: No such file or directory
> compilation terminated.
> scripts/Makefile.build:405: recipe for target 
> 'arch/arm64/kernel/vdso/vdso.lds' failed
> make[7]: *** [arch/arm64/kernel/vdso/vdso.lds] Error 1
> make[7]: *** Waiting for unfinished jobs
> arch/arm64/Makefile:141: recipe for target 'vdso_prepare' failed
> make[6]: *** [vdso_prepare] Error 2
> make[6]: *** Waiting for unfinished jobs
> 
> 
> 
> 
> ___
> 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] Backporting stuff to lede-17.01

[Álvaro Fernández Rojas]

After doing some more tests it looks like these problems only come out when 
bridging WiFi & ethernet on the Raspberry Pi.
https://github.com/raspberrypi/firmware/issues/673

I'm currently running wifi and eth on separate interfaces and so far so good :).

~ Álvaro.

El 07/02/2017 a las 10:53, Álvaro Fernández Rojas escribió:
> Hi Rafał,
> 
> El 02/02/2017 a las 12:32, Rafał Miłecki escribió:
>> Hi,
>>
>> There are few changes that recently went into master and I'd like to
>> see in lede-17.01. Let me what do you think, if backporting any of
>> these is a bad idea.
>>
>> 1) bgmac support for external PHYs
>> 6a853776a502 ("kernel: backport bgmac support for external PHYs")
>> This adds support for some AP devices that don't have external switch
>> or just don't use internal one. Driver is used by brcm47xx/mips74k and
>> bcm53xx, I can test it (and I do) with both targets.
>>
>> 2) hostapd support for complete logging
>> 37b489fe0417 ("hostapd: backport support for sending debug messages to
>> the syslog")
>> This allows reading all error messages (and debugging ones if you
>> enable them) from the syslog (logread command). I find it very
>> important for debugging wireless/hostapd issues. This is a pretty
>> simple single hostapd patch.
>>
>> 3) brcmfmac update
>> There were quite a few improvements/fixes for brcmfmac. That includes
>> small fixes & debugging improvements. There are still some people
>> reporting problems with brcmfmac so getting useful info even with
>> 17.01 release would be desired.
>> We use brcmfmac for BCM43602 & BCM4366 PCIe devices and we support 4
>> routers with these. I own 3 of them so my testing should have a good
>> coverage.
>> One minor risk is I can't test brcmfmac with Raspberry Pi. The good
>> thing is that all patches were backported separately (and in few
>> commits) so any regression should be trivial to track.
> 
> I finally had some time to test this on my Raspberry Pi 3.
> BTW, thanks for these improvements ;D.
> 
> For what I've seen on my tests, performance has really improved since I added 
> support for the Raspberry Pi 3.
> There were some issues causing packet loss, but now it seems that those 
> problems are gone.
> However, I'm still getting these spam messages "brcmfmac: 
> brcmf_proto_bcdc_hdrpull: wlan0: non-BCDC packet received, flags 0x??", and 
> don't know where they come from...
> http://pastebin.com/1iEVLYQk
> Should we keep that message from being printed for brcm2708?
> 
> P.S: I will keep my Raspberry Pi 3 running for a while in order to check that 
> performance doesn't degrade over time.
> 
> Regards,
> Álvaro.
> 

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

Re: [LEDE-DEV] Backporting stuff to lede-17.01

[Álvaro Fernández Rojas]

Hi Rafał,

El 02/02/2017 a las 12:32, Rafał Miłecki escribió:
> Hi,
> 
> There are few changes that recently went into master and I'd like to
> see in lede-17.01. Let me what do you think, if backporting any of
> these is a bad idea.
> 
> 1) bgmac support for external PHYs
> 6a853776a502 ("kernel: backport bgmac support for external PHYs")
> This adds support for some AP devices that don't have external switch
> or just don't use internal one. Driver is used by brcm47xx/mips74k and
> bcm53xx, I can test it (and I do) with both targets.
> 
> 2) hostapd support for complete logging
> 37b489fe0417 ("hostapd: backport support for sending debug messages to
> the syslog")
> This allows reading all error messages (and debugging ones if you
> enable them) from the syslog (logread command). I find it very
> important for debugging wireless/hostapd issues. This is a pretty
> simple single hostapd patch.
> 
> 3) brcmfmac update
> There were quite a few improvements/fixes for brcmfmac. That includes
> small fixes & debugging improvements. There are still some people
> reporting problems with brcmfmac so getting useful info even with
> 17.01 release would be desired.
> We use brcmfmac for BCM43602 & BCM4366 PCIe devices and we support 4
> routers with these. I own 3 of them so my testing should have a good
> coverage.
> One minor risk is I can't test brcmfmac with Raspberry Pi. The good
> thing is that all patches were backported separately (and in few
> commits) so any regression should be trivial to track.

I finally had some time to test this on my Raspberry Pi 3.
BTW, thanks for these improvements ;D.

For what I've seen on my tests, performance has really improved since I added 
support for the Raspberry Pi 3.
There were some issues causing packet loss, but now it seems that those 
problems are gone.
However, I'm still getting these spam messages "brcmfmac: 
brcmf_proto_bcdc_hdrpull: wlan0: non-BCDC packet received, flags 0x??", and 
don't know where they come from...
http://pastebin.com/1iEVLYQk
Should we keep that message from being printed for brcm2708?

P.S: I will keep my Raspberry Pi 3 running for a while in order to check that 
performance doesn't degrade over time.

Regards,
Álvaro.

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

Re: [LEDE-DEV] [PATCH v2] include: Cortex-A53 is also an AArch64 CPU

[Álvaro Fernández Rojas]

ACK.

El 3/11/16 a las 19:16, Florian Fainelli escribió:
> Specifying a mtune option with cortex-a53 is also valid for an aarch64
> toolchain
> 
> Fixes: SVN 48964
> Signed-off-by: Florian Fainelli 
> ---
> Changes in v2:
> - add the option to the aarch64 architecture conditional
> 
>  include/target.mk | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/target.mk b/include/target.mk
> index c9c02fa03632..a8d3b2b24929 100644
> --- a/include/target.mk
> +++ b/include/target.mk
> @@ -212,6 +212,7 @@ ifeq ($(DUMP),1)
>ifeq ($(ARCH),aarch64)
>  CPU_TYPE ?= armv8-a
>  CPU_CFLAGS_armv8-a = -mcpu=armv8-a
> +CPU_CFLAGS_cortex-a53 = -mcpu=cortex-a53
>endif
>ifeq ($(ARCH),arc)
>  CPU_TYPE ?= arc700
> 

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

Re: [LEDE-DEV] getver.sh regression

[Álvaro Fernández Rojas]

That one is working fine after a small fix:
https://gist.github.com/Noltari/0c395c57b94598bdf96e6a292c7b5888
(You're missing one "|").

El 13/7/16 a las 11:45, Jonas Gorski escribió:
> On 13 July 2016 at 11:16, Álvaro Fernández Rojas <nolt...@gmail.com> wrote:
>> Appart from that, if there's no remote named origin it will also spam some 
>> errors about having no reference to origin/master.
>> My current setup includes lede, staging and github remotes, so there's no 
>> origin remote at all.
> 
> Can you give 
> https://git.lede-project.org/?p=lede/jogo/staging.git;a=commit;h=c73f3c4553cbc8320e3cca0f80a897421b1d62a4
> a try as well?
> 
> Jonas
> 

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

Re: [LEDE-DEV] fstools testing help

[Álvaro Fernández Rojas]

I will try to test it on RPi tonight.

Regards,
Álvaro.

El 30/6/16 a las 9:21, John Crispin escribió:
> Hi,
> 
> i have just merged to fstools patches into my staging tree that address
> a double mount issue and add back ext4 support. the ext4 patch
> previously broke rPi and other ext4 targets, but i thini with josua's
> patch applied it should work. i have done some basic testing already my
> end but would like further etst coverage to make sure there are no
> hidden regressions
> 
> things that should be tested are
> 
> * does ext4 mount work on eMMC
> * does rootfs mount work on rPi
> * does extroot still work with flat mounts
> * does extroot still work with flat overlay mounts
> 
> i have only tested the last one so far.
> 
>   John
> 

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

[LEDE-DEV] brcm2708: take over maintainership

[Álvaro Fernández Rojas]

Hello Florian,

Do you mind if I take over brcm2708's maintainership?
https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/brcm2708/Makefile;hb=HEAD#l14

Regards,
Álvaro.

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

Re: [LEDE-DEV] [PATCHv3 1/1] [brcm63xx] Add initial support for EVG2000

[Álvaro Fernández Rojas]

Hello Graham,

Pulled into my staging tree with some changes (whitespace fixes, cleanups...):
https://git.lede-project.org/?p=lede/noltari/staging.git;a=shortlog;h=refs/heads/brcm63xx-next

Regards,
Álvaro.

El 23/5/16 a las 0:56, Xotic750 escribió:
> From: Graham Fairweather 
>
> This patch adds support for the Netgear EVG2000 VoIP Gateway to the
> bcm63xx targets.
> Ran 'make target/linux/refresh V=s' after update to kernel 4.4.10 from
> 4.4.8 where the initial patch was added.
> This device was not sold to the general public, but rather is/was
> provided by telcos to customers in Sweden, Australia, Singapore and
> other parts of asia.
> System-On-Chip: Broadcom BCM6369 (2 * BMIPS4350 v3.1 / 400 MHz)
> Flash size: 16 MiB
> RAM size: 64 MiB
> Wireless: BCM4322 802.11b/g/n (onboard)
> Ethernet: Broadcom BCM53115
> USB: 2 x USB 2.0
> Known issues:
>  - Unable to detect 53115 switch. This appear to be a problem with
> probing for the PHY using MDIO and results in error 5. Doesn't seem to
> be a problem with the configuration, and could use someone with
> experience to have a look at it.
>  - Uses the b43 driver as using the OpenWRT/LEDE broadcom-wl driver
> fails to load the firmware for the 4322, so 802.11n is not supported.
> The factory build uses a newer broadcom-wl driver.
>  - No support for the 2 VoIP ports (not attempted)
> More info on the device and the research can be found at:
> https://wiki.openwrt.org/toh/netgear/evg2000
> https://wikidevi.com/wiki/Netgear_EVG2000
> https://github.com/Xotic750/mirror-lede/tree/evg2000
> https://forum.openwrt.org/viewtopic.php?id=63950
> Signed-off-by: Graham Fairweather 
> ---
>  .../linux/brcm63xx/base-files/etc/board.d/01_leds  |   7 ++
>  .../brcm63xx/base-files/etc/board.d/02_network |   1 +
>  target/linux/brcm63xx/base-files/etc/diag.sh   |   3 +
>  .../base-files/etc/uci-defaults/09_fix_crc |   2 +-
>  target/linux/brcm63xx/base-files/lib/brcm63xx.sh   |   3 +
>  .../lib/preinit/05_init_interfaces_brcm63xx|   1 +
>  target/linux/brcm63xx/dts/evg2000.dts  | 103 
> +
>  target/linux/brcm63xx/image/Makefile   |   2 +
>  .../brcm63xx/patches-4.1/575-board_EVG2000.patch   |  62 +
>  ...-m25p80-use-parsers-if-provided-in-flash-.patch |   2 +-
>  ...CES-m25p80-add-support-for-limiting-reads.patch |   4 +-
>  .../414-MTD-m25p80-allow-passing-pp_data.patch |   2 +-
>  .../brcm63xx/patches-4.4/575-board_EVG2000.patch   |  62 +
>  target/linux/brcm63xx/profiles/netgear.mk  |  10 ++
>  14 files changed, 259 insertions(+), 5 deletions(-)
>  create mode 100644 target/linux/brcm63xx/dts/evg2000.dts
>  create mode 100644 target/linux/brcm63xx/patches-4.1/575-board_EVG2000.patch
>  create mode 100644 target/linux/brcm63xx/patches-4.4/575-board_EVG2000.patch
>
> diff --git a/target/linux/brcm63xx/base-files/etc/board.d/01_leds 
> b/target/linux/brcm63xx/base-files/etc/board.d/01_leds
> index 8339254..4163214 100755
> --- a/target/linux/brcm63xx/base-files/etc/board.d/01_leds
> +++ b/target/linux/brcm63xx/base-files/etc/board.d/01_leds
> @@ -24,6 +24,13 @@ dgnd3700v1_dgnd3800b)
>   ucidef_set_led_usbdev "usb1" "USB1" "DGND3700v1_3800B:green:usb-back" 
> "1-1"
>   ucidef_set_led_usbdev "usb2" "USB2" "DGND3700v1_3800B:green:usb-front" 
> "1-2"
>   ;;
> +evg2000)
> + ucidef_set_led_netdev "lan" "LAN" "EVG2000:green:lan" "eth0"
> + ucidef_set_led_netdev "wan" "WAN" "EVG2000:green:wan" "eth1"
> + ucidef_set_led_netdev "wlan0" "WIFI" "EVG2000:green:wireless" "wlan0"
> + ucidef_set_led_usbdev "usb1" "USB1" "EVG2000:green:voip1" "1-1"
> + ucidef_set_led_usbdev "usb2" "USB2" "EVG2000:green:voip2" "1-2"
> + ;;
>  fast2704n)
>   ucidef_set_led_netdev "wan" "WAN" "F@ST2704N:green:inet" "eth0.2"
>   ;;
> diff --git a/target/linux/brcm63xx/base-files/etc/board.d/02_network 
> b/target/linux/brcm63xx/base-files/etc/board.d/02_network
> index f96da08..83367c1 100755
> --- a/target/linux/brcm63xx/base-files/etc/board.d/02_network
> +++ b/target/linux/brcm63xx/base-files/etc/board.d/02_network
> @@ -11,6 +11,7 @@ board_config_update
>  case "$(brcm63xx_board_name)" in
>  
>  cvg834g |\
> +evg2000 |\
>  rta770bw |\
>  rta770w |\
>  spw303v |\
> diff --git a/target/linux/brcm63xx/base-files/etc/diag.sh 
> b/target/linux/brcm63xx/base-files/etc/diag.sh
> index b864964..6ac2459 100644
> --- a/target/linux/brcm63xx/base-files/etc/diag.sh
> +++ b/target/linux/brcm63xx/base-files/etc/diag.sh
> @@ -70,6 +70,9 @@ set_state() {
>   dgnd3700v1_dgnd3800b)
>   status_led="DGND3700v1_3800B:green:power"
>   ;;
> + evg2000)
> + status_led="EVG2000:green:power"
> + ;;
>   fast2504n)
>   status_led="fast2504n:green:ok"
>   ;;
> diff --git a/target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc 
> 

Re: [LEDE-DEV] [PATCHv4 1/1] [brcm63xx] Fix the logged CPU variant

[Álvaro Fernández Rojas]

NACK, this doesn't add any funcionality and original firmwares show 
these SoCs as their generic CPU IDs (e.g: 6368 for the 6369).


El 23/5/16 a las 0:46, Xotic750 escribió:

From: Graham Fairweather 

This patch fixes the logged detected CPU ID when an equivalent is used,
like in the case where we have a bcm6369 and configuration for a
bcm6368 is used.
So, it will display 'Detected Broadcom 0x6369 CPU revision b2' instead of
'Detected Broadcom 0x6368 CPU revision b2'.
More info can be found at:
https://forum.openwrt.org/viewtopic.php?id=64621
https://github.com/Xotic750/mirror-lede/tree/fix_cpu_id
Signed-off-by: Graham Fairweather 
---
  .../330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch  | 9 +
  .../330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch  | 9 +
  2 files changed, 18 insertions(+)

diff --git 
a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
 
b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
index 661abf6..23491aa 100644
--- 
a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
+++ 
b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
@@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant 
helper
bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT;
   
   	switch (bcm63xx_cpu_id) {

+@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void)
+   bcm63xx_memory_size = detect_memory_size();
+
+   printk(KERN_INFO "Detected Broadcom 0x%04x CPU revision %02x\n",
+- bcm63xx_cpu_id, bcm63xx_cpu_rev);
++ bcm63xx_cpu_variant, bcm63xx_cpu_rev);
+   printk(KERN_INFO "CPU frequency is %u MHz\n",
+  bcm63xx_cpu_freq / 100);
+   printk(KERN_INFO "%uMB of RAM installed\n",
  --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h
  +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h
  @@ -19,6 +19,7 @@
diff --git 
a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
 
b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
index 661abf6..330a9e6 100644
--- 
a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
+++ 
b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
@@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant 
helper
bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT;
   
   	switch (bcm63xx_cpu_id) {

+@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void)
+   bcm63xx_memory_size = detect_memory_size();
+
+   pr_info("Detected Broadcom 0x%04x CPU revision %02x\n",
+-  bcm63xx_cpu_id, bcm63xx_cpu_rev);
++  bcm63xx_cpu_variant, bcm63xx_cpu_rev);
+   pr_info("CPU frequency is %u MHz\n",
+   bcm63xx_cpu_freq / 100);
+   pr_info("%uMB of RAM installed\n",
  --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h
  +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h
  @@ -19,6 +19,7 @@



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