Re: [LEDE-DEV] [PATCH] This patch adds support for the Actiontec R1000H gateway to the brcm63xx targets.

[Rafał Miłecki]

On 23 February 2017 at 23:01, Anthony Sepa  wrote:
> Is there anything I can do to fix it? I can switch to my gmail account? I
> was using my yahoo out of habit. I was posting using git send-mail, is that
> causing the problem? Should I change to just using email?

Well, using GMail will for sure let you post patches easily. Please
note you don't need to change your e-mail used in git commits. Also
using git send-email is perfectly fine.

This is what I use for my git configuration:
git config --global sendemail.smtpserver smtp.gmail.com
git config --global sendemail.smtpserverport 587
git config --global sendemail.smtpencryption tls
git config --global sendemail.smtpuser f...@gmail.com

This allows you easily send patches using
git send-email --no-chain-reply-to \
--from "Foo " \
--to "Bar " \
0001-x.patch

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

Re: [LEDE-DEV] [PATCH] This patch adds support for the Actiontec R1000H gateway to the brcm63xx targets.

[Rafał Miłecki]

On 23 February 2017 at 21:48, David Woodhouse  wrote:
> On Thu, 2017-02-23 at 21:35 +0100, Rafał Miłecki wrote:
>> On 12 February 2017 at 14:48, Anthony Sepa via Lede-dev
>>  wrote:
>> >
>> > 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.
>> You don't need this and I think you were already instructed on other
>> ML not to do so.
>>
>> Just include proper From: as the first e-mail of your e-mail body.
>> Actually git format-patch can even do that for you.
>
> He didn't do that bit. That's the stupid list configuration. Anthony's
> problem was that he was posting from a mail domain with stupid
> settings. The list's stupidity is a reaction to that.
>
> Personally, I think we're better off just *rejecting* posts from people
> with such broken domains. But I only provide the hosting; I'm not
> actively playing BoFH and enforcing my opinions on the list config...

Thanks for the explanation!

-- 
Rafał

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

Re: [LEDE-DEV] [PATCH] This patch adds support for the Actiontec R1000H gateway to the brcm63xx targets.

[David Woodhouse]

On Thu, 2017-02-23 at 21:35 +0100, Rafał Miłecki wrote:
> On 12 February 2017 at 14:48, Anthony Sepa via Lede-dev
>  wrote:
> > 
> > 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.
> You don't need this and I think you were already instructed on other
> ML not to do so.
> 
> Just include proper From: as the first e-mail of your e-mail body.
> Actually git format-patch can even do that for you.

He didn't do that bit. That's the stupid list configuration. Anthony's
problem was that he was posting from a mail domain with stupid
settings. The list's stupidity is a reaction to that.

Personally, I think we're better off just *rejecting* posts from people
with such broken domains. But I only provide the hosting; I'm not
actively playing BoFH and enforcing my opinions on the list config...

smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] This patch adds support for the Actiontec R1000H gateway to the brcm63xx targets.

[Rafał Miłecki]

On 12 February 2017 at 14:48, Anthony Sepa via Lede-dev
 wrote:
> 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.

You don't need this and I think you were already instructed on other
ML not to do so.

Just include proper From: as the first e-mail of your e-mail body.
Actually git format-patch can even do that for you.

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

Re: [LEDE-DEV] [PATCH] This patch adds support for the Actiontec R1000H gateway to the brcm63xx targets.

[Jonas Gorski]

Hi,

please don't drop the mailing list.

On 18 February 2017 at 21:41, Anthony Sepa  wrote:
>
>
> On Fri, Feb 17, 2017 at 10:07 AM Jonas Gorski 
> wrote:
>>
>> Hi,
>>
>> Please Cc me for brcm63xx patches, this makes it easier for me to
>> apply them (especially if they get mangled by patchwork).
>>
>> On 12 February 2017 at 14:48, Anthony Sepa via Lede-dev
>>  wrote:
>> > 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.
>> >
>> > -- Forwarded message --
>> > From: Anthony Sepa 
>> > To: lede-dev@lists.infradead.org
>> > Cc: Anthony Sepa 
>> > Date: Sun, 12 Feb 2017 09:45:06 -0400
>> > Subject: [PATCH] This patch adds support for the Actiontec R1000H
>> > gateway to the brcm63xx targets.
>>
>> Please use "[PATCH] brcm63xx: " as the subject.
>>
>> > SOC: Broadcom BCM6368 (2 * Broadcom BMIPS4350 V3.1 / 400 MHz)
>> > Flash size: 32MB (split 16/16 dual boot)
>>
>> You usually can use all 32MB and force it to not dual boot by giving
>> it large enough images (>= 16MB).
>
>
> What is the preferred path to take when creating a build for a dual boot
> device? Is it better to try and preserve the dual boot functionality or
> ignore it? From a user point of view the second partition can be saved with
> the factory firmware for ease of restoring to the old firmware. But it is a
> time bomb waiting to happen, because as soon as LEDE updates the primary
> partition the CFE may decide to boot the secondary as being "newer". See my
> comments later about setting the ram to 32MB.

Dual booting isn't supported, the system/code is expecting to boot
from the first image offset.

Generally CFE works this way:

on boot:

check image tag on image0 offset
check image tag on image1 offset

if any is invalid, boot the other (or none if no valid available)
else boot the one based on the configuration (oldest, newest)

on flashing:

if the image is smaller than the dual image size => override oldest image
if the image is larger than the dual image size => flash at image0 offset

With setting FLASH_MB to the actual flash size, LEDE will create an
image that is larger than the dual image size, thus force CFE to
always flash to image0/boot from there.

>> > RAM size: 64MB
>> > Wireless: BCM432x 802.11a/b/g/n(pci)
>> > Ethernet: Broadcom BCM53115
>> > USB: 1 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.
>>
>> Currently MDIO connected switches/devices aren't supported yet.
>
>
> I noticed. Are they supported in the 4.9 kernel? I have a buildroot
> environment using the 4.9 kernel and I was trying to figure out how to
> create a proper DTS file to get the switch working. But the documentation
> was hard to follow and in some cases had the wrong syntax so I gave up.

No they aren't. This has a few extra dependencies before this can be done.

>>
>>
>> >  - 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.
>>
>> You probably just need to supply an sprom, see how other boards use
>> .use_fallback_sprom = 1 etc.
>
>
> This was a left over from the template I was trying to follow. The
> wl-broadcom and b43 drivers work great.

Okay, even better.

(snip)

>> > +
>> > + {
>> > +   status = "ok";
>> > +
>> > +   linux,part-probe = "bcm63xxpart";
>> > +
>> > +   CFE@0 {
>> > +   reg = <0x00 0x02>;
>>
>> Please make this partition read-only.
>
>
> Sure. But how does someone update the CFE? For example the CFE parameters
> are here. In my CFE the parameter "p=" is used to switch booted partitions,
> etc.

This is currently not supported in LEDE, so no point in having it writable.

>>
>> > +   };
>> > +   linux@2 {
>> > +   reg = <0x02 0x07e>;
>> > +   };
>> > +   ubi_dev@80 {
>> > +   reg = <0x080 0x080>;
>> > +   };
>>
>> Same again, what's up with the ubi?
>>
>>
>> > +   factory@100 {
>> > +   reg = <0x100 0x0fe>;
>> > +   };
>>
>> So this is the second image? As mentioned above, you should be able to
>> use the full flash, unless actiontec did something strange.
>
>
> I used the second partition for a Buildroot environment because I wanted to
> test the 4.9 kernel. I left the second partition so people could save the
> original firmware on the device. That and using the CFE parameters allows
> switching between images.

Usually you can just 

Re: [LEDE-DEV] [PATCH] This patch adds support for the Actiontec R1000H gateway to the brcm63xx targets.

[Jonas Gorski]

Hi,

Please Cc me for brcm63xx patches, this makes it easier for me to
apply them (especially if they get mangled by patchwork).

On 12 February 2017 at 14:48, Anthony Sepa via Lede-dev
 wrote:
> 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.
>
> -- Forwarded message --
> From: Anthony Sepa 
> To: lede-dev@lists.infradead.org
> Cc: Anthony Sepa 
> Date: Sun, 12 Feb 2017 09:45:06 -0400
> Subject: [PATCH] This patch adds support for the Actiontec R1000H gateway to 
> the brcm63xx targets.

Please use "[PATCH] brcm63xx: " as the subject.

> SOC: Broadcom BCM6368 (2 * Broadcom BMIPS4350 V3.1 / 400 MHz)
> Flash size: 32MB (split 16/16 dual boot)

You usually can use all 32MB and force it to not dual boot by giving
it large enough images (>= 16MB).

> RAM size: 64MB
> Wireless: BCM432x 802.11a/b/g/n(pci)
> Ethernet: Broadcom BCM53115
> USB: 1 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.

Currently MDIO connected switches/devices aren't supported yet.

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

You probably just need to supply an sprom, see how other boards use
.use_fallback_sprom = 1 etc.

> The factory build uses a newer broadcom-wl driver.
>  - No support for the cable port
>
> More info on the device and the research can be found at:
> http://www.actiontec.com/212.html
>
> Same FCC ID as:
> https://wikidevi.com/wiki/Actiontec_V1000H_(Telus)
>
> Signed-off-by: Anthony Sepa 
> ---
>  target/linux/brcm63xx/dts/r1000h.dts   | 89 
> ++
>  target/linux/brcm63xx/image/bcm63xx.mk | 16 
>  .../brcm63xx/patches-4.4/578-board_R1000H.patch| 63 +++
>  3 files changed, 168 insertions(+)
>  create mode 100644 target/linux/brcm63xx/dts/r1000h.dts
>  create mode 100644 target/linux/brcm63xx/patches-4.4/578-board_R1000H.patch
>
> diff --git a/target/linux/brcm63xx/dts/r1000h.dts 
> b/target/linux/brcm63xx/dts/r1000h.dts
> new file mode 100644
> index 000..a3a8073
> --- /dev/null
> +++ b/target/linux/brcm63xx/dts/r1000h.dts
> @@ -0,0 +1,89 @@
> +/dts-v1/;
> +
> +#include "bcm6368.dtsi"
> +
> +#include 
> +
> +/ {
> +   model = "Actiontec R1000H";
> +   compatible = "actiontec,r1000h", "brcm,bcm6368";
> +
> +   chosen {
> +   bootargs = "root=/dev/mtdblock2 rootfstype=squashfs 
> ubi.mtd=ubi_dev noinitrd console=ttyS0,115200";

What's up with the ubi partiton? Where does this come from?

> +   };
> +
> +   gpio-keys-polled {
> +   compatible = "gpio-keys-polled";
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   poll-interval = <20>;
> +   debounce-interval = <60>;
> +
> +   reset {
> +   label = "reset";
> +   gpios = < 2 1>;
> +   linux,code = ;
> +   };

Please add an empty line between nodes (I know that many boards don't,
I plan to fix it eventually).

> +   wps {
> +   label = "wps";
> +   gpios = < 3 1>;
> +   linux,code = ;
> +   };
> +   };
> +
> +   gpio-leds {
> +   compatible = "gpio-leds";
> +
> +   inet_green {
> +   label = "R1000H:green:inet";
> +   gpios = < 5 0>;
> +   };

Same here etc.

> +   usb_green {
> +   label = "R1000H:green:usb";
> +   gpios = < 21 1>;
> +   };
> +   power_green {
> +   label = "R1000H:green:power";
> +   gpios = < 22 0>;
> +   default-state = "on";
> +   };
> +   wps_green {
> +   label = "R1000H:green:wps";
> +   gpios = < 23 1>;
> +   };
> +   power_red {
> +   label = "R1000H:red:power";
> +   gpios = < 24 0>;
> +   };
> +   wps_red {
> +   label = "R1000H:red:wps";
> +   gpios = < 30 1>;
> +   };
> +   inet_red {
> +   label = "R1000H:red:inet";
> +   gpios = < 31 0>;
> +   };
> +   };
> +};
> +
> + {
> +   status = "ok";
> +
> +

[LEDE-DEV] [PATCH] This patch adds support for the Actiontec R1000H gateway to the brcm63xx targets.

[Anthony Sepa 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 ---
SOC: Broadcom BCM6368 (2 * Broadcom BMIPS4350 V3.1 / 400 MHz)
Flash size: 32MB (split 16/16 dual boot)
RAM size: 64MB
Wireless: BCM432x 802.11a/b/g/n(pci)
Ethernet: Broadcom BCM53115
USB: 1 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 cable port

More info on the device and the research can be found at:
http://www.actiontec.com/212.html

Same FCC ID as:
https://wikidevi.com/wiki/Actiontec_V1000H_(Telus)

Signed-off-by: Anthony Sepa 
---
 target/linux/brcm63xx/dts/r1000h.dts   | 89 ++
 target/linux/brcm63xx/image/bcm63xx.mk | 16 
 .../brcm63xx/patches-4.4/578-board_R1000H.patch| 63 +++
 3 files changed, 168 insertions(+)
 create mode 100644 target/linux/brcm63xx/dts/r1000h.dts
 create mode 100644 target/linux/brcm63xx/patches-4.4/578-board_R1000H.patch

diff --git a/target/linux/brcm63xx/dts/r1000h.dts 
b/target/linux/brcm63xx/dts/r1000h.dts
new file mode 100644
index 000..a3a8073
--- /dev/null
+++ b/target/linux/brcm63xx/dts/r1000h.dts
@@ -0,0 +1,89 @@
+/dts-v1/;
+
+#include "bcm6368.dtsi"
+
+#include 
+
+/ {
+   model = "Actiontec R1000H";
+   compatible = "actiontec,r1000h", "brcm,bcm6368";
+
+   chosen {
+   bootargs = "root=/dev/mtdblock2 rootfstype=squashfs 
ubi.mtd=ubi_dev noinitrd console=ttyS0,115200";
+   };
+
+   gpio-keys-polled {
+   compatible = "gpio-keys-polled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   poll-interval = <20>;
+   debounce-interval = <60>;
+
+   reset {
+   label = "reset";
+   gpios = < 2 1>;
+   linux,code = ;
+   };
+   wps {
+   label = "wps";
+   gpios = < 3 1>;
+   linux,code = ;
+   };
+   };
+
+   gpio-leds {
+   compatible = "gpio-leds";
+
+   inet_green {
+   label = "R1000H:green:inet";
+   gpios = < 5 0>;
+   };
+   usb_green {
+   label = "R1000H:green:usb";
+   gpios = < 21 1>;
+   };
+   power_green {
+   label = "R1000H:green:power";
+   gpios = < 22 0>;
+   default-state = "on";
+   };
+   wps_green {
+   label = "R1000H:green:wps";
+   gpios = < 23 1>;
+   };
+   power_red {
+   label = "R1000H:red:power";
+   gpios = < 24 0>;
+   };
+   wps_red {
+   label = "R1000H:red:wps";
+   gpios = < 30 1>;
+   };
+   inet_red {
+   label = "R1000H:red:inet";
+   gpios = < 31 0>;
+   };
+   };
+};
+
+ {
+   status = "ok";
+
+   linux,part-probe = "bcm63xxpart";
+
+   CFE@0 {
+   reg = <0x00 0x02>;
+   };
+   linux@2 {
+   reg = <0x02 0x07e>;
+   };
+   ubi_dev@80 {
+   reg = <0x080 0x080>;
+   };
+   factory@100 {
+   reg = <0x100 0x0fe>;
+   };
+   nvram@1fe {
+   reg = <0x1fe 0x2>;
+   };
+};
diff --git a/target/linux/brcm63xx/image/bcm63xx.mk 
b/target/linux/brcm63xx/image/bcm63xx.mk
index 0749c29..947259b 100644
--- a/target/linux/brcm63xx/image/bcm63xx.mk
+++ b/target/linux/brcm63xx/image/bcm63xx.mk
@@ -1,3 +1,4 @@
+
 #
 # BCM33XX/BCM63XX Profiles
 #
@@ -174,6 +175,21 @@ define Device/96368MVWG-generic
 endef
 TARGET_DEVICES += 96368MVWG-generic
 
+### Actiontec ###
+define Device/R1000H
+  $(Device/bcm63xx)
+  FILESYSTEMS := squashfs
+  DEVICE_TITLE := Actiontec R1000H
+  DEVICE_DTS := r1000h
+  CFE_BOARD_ID := 96368MVWG
+  CFE_CHIP_ID := 6368
+  FLASH_MB := 8
+  IMAGE_OFFSET := 0x2
+  DEVICE_PACKAGES := \
+$(USB2_PACKAGES)
+endef
+TARGET_DEVICES += R1000H
+
 ### ADB ###
 define Device/A4001N
   $(Device/bcm63xx)
diff --git