[LEDE-DEV] [PATCH] This patch adds support for the Actiontec R1000H gateway to the brcm63xx targets.
Jonas Gorski
jonas.gorski at gmail.com
Sun Feb 19 04:30:25 PST 2017
Hi,
please don't drop the mailing list.
On 18 February 2017 at 21:41, Anthony Sepa <anthonysepa at yahoo.ca> wrote:
>
>
> On Fri, Feb 17, 2017 at 10:07 AM Jonas Gorski <jonas.gorski at gmail.com>
> 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
>> <lede-dev at lists.infradead.org> 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 <anthonysepa at yahoo.ca>
>> > To: lede-dev at lists.infradead.org
>> > Cc: Anthony Sepa <anthonysepa at yahoo.ca>
>> > 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: <foo>" 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)
>> > +
>> > +&pflash {
>> > + status = "ok";
>> > +
>> > + linux,part-probe = "bcm63xxpart";
>> > +
>> > + CFE at 0 {
>> > + reg = <0x000000 0x020000>;
>>
>> 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 at 20000 {
>> > + reg = <0x020000 0x07e0000>;
>> > + };
>> > + ubi_dev at 800000 {
>> > + reg = <0x0800000 0x0800000>;
>> > + };
>>
>> Same again, what's up with the ubi?
>>
>>
>> > + factory at 1000000 {
>> > + reg = <0x1000000 0x0fe0000>;
>> > + };
>>
>> 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 download the original firmware from the
manufacturer website, or it is included with the device on a CD. And
since LEDE doesn't support dual booting, I see no real point in
keeping it.
So please drop it and allow using the full flash.
>>
>> > + nvram at 1fe0000 {
>> > + reg = <0x1fe0000 0x20000>;
>> > + };
>> > +};
>> > 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
>>
>> In your patch notes you say, 32, here you say 8. So how much is it?
>
>
> From my look at the code this is more for padding the file to a minimum of
> FLASH_MB / 2. So, if I change this to 32MB the system creates a large 16MB
> file full of nothingness. Along with the problems of such a large file, the
> system will create a JFFS in the space that the CFE thinks is a static
> squashfs and on the second boot the CFE will CRC check it and fail. I hadn't
> thought of this until now and I tested it.
>
> In fact I need this (/2) to be smaller than the actual squashfs. If for any
> reason the squashfs ends up being smaller than this (/2) then the CFE will
> refuse to load the image on the second boot.
>
> I removed it to allow for the default (4) but if the default ever gets
> changed to something too big the images will fail. So I added it back as
> FLASH_MB := 4 since it is required to be small.
Look at target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc -
this will fixup the image tag on first boot and set the rootfs size to
0, effectively disabling the crc check from CFE.
This should make it work even when using large images.
>> > + IMAGE_OFFSET := 0x20000
>> > + DEVICE_PACKAGES := \
>> > + $(USB2_PACKAGES)
>> > +endef
>> > +TARGET_DEVICES += R1000H
>> > +
>> > ### ADB ###
>> > define Device/A4001N
>> > $(Device/bcm63xx)
>> > diff --git a/target/linux/brcm63xx/patches-4.4/578-board_R1000H.patch
>> > b/target/linux/brcm63xx/patches-4.4/578-board_R1000H.patch
>> > new file mode 100644
>> > index 0000000..c9c919a
>> > --- /dev/null
>> > +++ b/target/linux/brcm63xx/patches-4.4/578-board_R1000H.patch
>> > @@ -0,0 +1,63 @@
>> > +--- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
>> > ++++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c
>> > +@@ -2200,6 +2200,44 @@
>> > + .type = SPROM_BCM4318,
>> > + .pci_bus = 0,
>> > + .pci_dev = 1,
>> > ++ },
>> > ++};
>> > ++
>> > ++static struct board_info __initdata board_R1000H = {
>> > ++ .name = "R1000H",
>> > ++ .expected_cpu_id = 0x6368,
>> > ++
>> > ++ .has_uart0 = 1,
>> > ++ .has_uart1 = 1,
>> > ++ .has_pci = 1,
>> > ++ .has_ohci0 = 1,
>> > ++ .has_ehci0 = 1,
>> > ++ .has_usbd = 1,
>> > ++ .usbd = {
>> > ++ .use_fullspeed = 0,
>> > ++ .port_no = 0,
>> > ++ },
>>
>> I don't see any usb device port. Did I miss it? If not, please drop
>> the .has_usbd etc.
>
>
> Yeah, there is a USB port.
I see an USB *host* (Type A) port, but I do not see a USB *device*
(Type B) port.
>
>>
>> > ++
>> > ++ .has_enetsw = 1,
>> > ++ .enetsw = {
>> > ++ .used_ports = {
>> > ++ [4] = {
>> > ++ .used = 1,
>> > ++ .phy_id = 0xff,
>> > ++ .bypass_link = 1,
>> > ++ .force_speed = 1000,
>> > ++ .force_duplex_full = 1,
>> > ++ .name = "RGMII",
>> > ++ },
>> > ++ [5] = {
>> > ++ .used = 1,
>> > ++ .phy_id = 0xff,
>> > ++ .bypass_link = 1,
>> > ++ .force_speed = 1000,
>> > ++ .force_duplex_full = 1,
>> > ++ .name = "RGMII",
>> > ++ },
>>
>> Does it really use both ports. Is one the wan port? is it the cable
>> port? Anyways, you should give them unique names.
>>
>
> The stock firmware has:
> {bp_ucPhyType0, .u.uc = BP_ENET_EXTERNAL_SWITCH},
> {bp_ucPhyAddress, .u.uc = 0x0},
> {bp_usConfigType, .u.us = BP_ENET_CONFIG_MMAP},
> {bp_ulPortMap, .u.ul = 0x20}, 32
> {bp_ulPhyId5, .u.ul = 0xff},
> {bp_ucPhyType1, .u.uc = BP_ENET_EXTERNAL_SWITCH},
> {bp_ucPhyAddress, .u.uc = 0x0},
> {bp_usConfigType, .u.us = BP_ENET_CONFIG_MDIO_PSEUDO_PHY},
> {bp_ulPortMap, .u.ul = 0x3f}, 63
> {bp_ulPhyId0, .u.ul = 0x00},
> {bp_ulPhyId1, .u.ul = 0x01},
> {bp_ulPhyId2, .u.ul = 0x02},
> {bp_ulPhyId3, .u.ul = 0x03},
> {bp_ulPhyId4, .u.ul = 0x04},
> {bp_ulPhyId5, .u.ul = 0x11},
>
> I'm not sure how to properly map this to the DTS, and if I have only one
> port the logic somewhere stops the information from getting to the b53
> driver.
>
> It looks to me like there are two switches a MMAP (bcm63xx) and MDIO (which
> is the 53115). The second is not supported. But I'd like the information to
> be in the file for later when it becomes supported. Plus as mentioned if I
> leave only the port5 MMAP switch the system will never register it with b53
> driver. Does it matter?
The internal switch isn't registered if there is only one external
port, because then it is basically a simple ethernet device. A two
port switch would be basically just a vlan filter device, so it's
easier to just pass everything through. Also, like in your case, if
there is an external switch behind the single port, it is less
confusing if there is only one switch visible to the system
(eventually).
Looking at the stock firmware code, you only want port 5, and port 4
isn't used at all.
And it seems the cable port is connected to the RGMII port (5) of the
external switch.
(snip rest)
Regards
Jonas
More information about the Lede-dev
mailing list