Commit Graph

117 Commits

Author SHA1 Message Date
Christian Marangi
7e85c30938
bcm53xx: drop kmod-ledtrig-default-on and kmod-ledtrig-netdev
Drop kmod-ledtrig-default-on and kmod-ledtrig-netdev as the kmod were
dropped and are now enabled by default.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
2024-10-29 00:07:52 +01:00
Matthew Hagan
7ad9988287 bcm53xx: add support for Cisco Meraki MX64/MX65
This commit adds support for the Cisco Meraki MX64 and MX65 devices which
use the Broadcom NSP SoC, which is compatible with the bcm53xx platform.

MX64 Hardware info:
  - CPU: Broadcom BCM58625 Cortex A9 @ 1200Mhz
  - RAM: 2 GB (4 x 4Gb SK Hynix H5TC4G83CFR)
  - Storage: 1 GB (Micron MT29F8G08ABACA)
  - Networking: BCM58625 internal switch (5x 1GbE ports)
  - USB: 1x USB2.0
  - Serial: Internal header

MX65 Hardware info:
  - CPU: Broadcom BCM58625 Cortex A9 @ 1200Mhz
  - RAM: 2 GB (4 x 4Gb SK Hynix H5TC4G83CFR)
  - Storage: 1 GB (Micron MT29F8G08ABACA)
  - Networking: BCM58625 switch (2x 1GbE ports, used for WAN ports 1 & 2)
    2x Qualcomm QCA8337 switches (10x 1GbE ports, used for LAN ports 3-12)
  - PSE: Broadcom BCM59111KMLG connected to LAN ports 11 & 12
  - USB: 1x USB2.0
  - Serial: Internal header

Notes:
  - The Meraki provided GPL source are available at [2].
  - Wireless capability on the MX64W and MX65W exists in the form of 2x
    Broadcom BCM43520KMLG, which is not supported. These devices will work
    otherwise as standard MX64 or MX65 devices.
  - Early MX64 units use an A0 variant of the BCM958625 SoC which lacks
    cache coherency and uses a different "secondary-boot-reg". As a
    consequence a different device tree is needed.
  - Installation of OpenWrt requires changing u-boot to a custom version.
    This is due to the stock u-boot "nand read" command being limited to
    load only 2MB, in spite of the bootkernel1 and bootkernel2 partitions
    both being 3MB in the stock layout. It is also required to allow
    booting via USB, enabling cache coherency and setting up the QCA
    switches and Serdes link on the MX65. The modified sources for U-boot
    are available for the MX64[3] and MX65[4].
  - Initial work on this device used a small bootloader within the OEM
    partition scheme. To allow booting of larger kernels, UBI and bootm
    support has been added, along with ability to store env variables to
    the NAND. The Shmoo and newly created env partitions have been moved
    to the extra space available after the nvram data.
  - Users who installed the previous non-UBI supporting bootloader will
    need to convert to the new one before flashing a compatible image.
    These steps are detailed below.

References:

[1] https://www.broadcom.com/products/embedded-and-networking-processors/c
ommunications/bcm5862x
[2] https://dl.meraki.net/wired-14-39-mx64-20190426.tar.bz2
[3] https://github.com/clayface/U-boot-MX64-20190430_MX64
[4] https://github.com/clayface/U-boot-MX64-20190430_MX65

Installation guide:

Initial installation steps:
  1. Compile or obtain OpenWrt files for the MX64 or MX65, including
     u-boot[3][4], initramfs and sysupgrade images.
  2. A USB disk with DOS partition scheme and primary FAT partition is
     required.
  3. If installing onto an MX64, set up a local web server.
  4. On the device, boot into diagnostic mode by holding reset when
     powering on the device. Continue to hold reset until the orange LED
     begins to flash white. On used units the white flash may be difficult
     to see.
  5. Plug an Ethernet cable into the first LAN port, set the host to
     192.168.1.2 and confirm telnet connectivity to 192.168.1.1.

U-boot installation - MX64 Only:
  1. Newer fw versions require extra steps to support OpenWrt. To check,
     please connect via telnet and run:
        `cat /sys/block/mtdblock0/ro`
     If the result is 1, your mtd0 is locked will need to perform extra
     steps 4 and 5 in this section. If the result is 0 then skip these.

  2. Check which SoC is in use by running the following command:
        `devmem 0x18000000`
     If devmem is not found then try:
        `devmem2 0x18000000`
     If the output begins with anything between "0x3F00-0x3F03" you will
     need to use the A0 release. For any other output, eg "0x3F04" or
     higher, use the regular MX64 image.

  3  Confirm the size of the device's boot(mtd0) partition. In most
     cases it should be 0x100000 or larger. If this is the case, please
     proceed to use the uboot_mx64 image. If the reported size is
     0x80000, please use the uboot_mx64_small image, then follow the
     later guide to change to the larger image.
        `cat /proc/mtd`
     Example output:
        `# cat /proc/mtd
        cat /proc/mtd
        dev:    size   erasesize  name
        mtd0: 00100000 00040000 "boot"
        mtd1: 00080000 00040000 "shmoo"
        mtd2: 00300000 00040000 "bootkernel1"
        mtd3: 00100000 00040000 "nvram"
        mtd4: 00300000 00040000 "bootkernel2"
        mtd5: 3f700000 00040000 "ubi"
        mtd6: 40000000 00040000 "all"`

  4. Set up a webserver to serve the appropriate uboot_mx64 from the
     following location and verify the SHA512:
     https://github.com/clayface/U-boot-MX64-20190430_MX64

  5. (Only if mtd0 is locked) You will also need the mtd-rw.ko kernel
     module to unlock the partition from the same repo. An mtd executable
     is also needed to write the mtd block. Place these on the web server
     as well.

  6. (Only if mtd0 is locked) Use wget to retrieve the files on the MX64:
        `wget http://192.168.1.2/mtd-rw.ko`
        `insmod mtd-rw.ko i_want_a_brick=1`
     and confirm the unlock is set with dmesg
        `mtd-rw: mtd0: setting writeable flag`

  7. Download the appropriate u-boot image according to step 3. If you
     did not need to unlock the mtd0 partition then use dd to write the
     file, with caution:
        `wget http://192.168.1.2/uboot_mx64`
        `dd if=uboot_mx64 of=/dev/mtdblock0`
     If you needed to unlock the mtd0 partition using the mtd-rw module,
     run these commands instead to install u-boot instead:
        `wget http://192.168.1.2/mtd`
        `chmod +x mtd`
        `wget http://192.168.1.2/uboot_mx64`
        `./mtd write uboot_mx64 /dev/mtd0`

  8. Once this has successfully completed, power off the device. If you
     did not need to install the small u-boot image, proceed to
     "OpenWrt Installation". Otherwise proceed to "UBI supporting
     bootloader installation".

U-boot installation - MX65 Only:
  1. Obtain telnet access to the MX65.

  2. Confirm the size of the device's boot(mtd0) partition. In most
     cases it should be 0x100000 or larger. If this is the case, please
     proceed to use the uboot_mx65 image. If the reported size is
     0x80000, please use the uboot_mx65_small image, then follow the
     later guide to change to the larger image.
	`cat /proc/mtd`

  3. Prepare a USB drive formatted to FAT. Download the appropriate
     uboot_mx65 to the USB drive from the following location and verify
     the SHA512:
        https://github.com/clayface/U-boot-MX64-20190430_MX65

  3. Once you have telnet access to the MX65, plug in the USB disk and
     run the following commands, with caution. The USB disk should
     automount but if it does not, you will need to power off and on
     again with reset held. Depending on step 2, use the uboot_mx65 or
     uboot_mx65_small image accordingly:
        `cd /tmp/media/sda1`
        `dd if=uboot_mx65 of=/dev/mtdblock0`

  4. Once this has successfully completed, power off the device. If you
     did not need to install the small u-boot image, proceed to
     "OpenWrt Installation". Otherwise proceed to "UBI supporting
     bootloader installation".

UBI supporting bootloader installation:
  These steps need to be followed if the older u-boot image was
  installed, either because the Meraki diagnostic partition scheme used
  0x80000 as the mtd0 size, or because you installed the u-boot provided
  while OpenWrt support was still under development. If using OpenWrt,
  please make a backup before proceeding.

  1. Obtain the relevant image from the MX64(A0) or MX65 u-boot repo:
        `openwrt-bcm5862x-generic-meraki_XXXX-initramfs-kernel.bin`

  2. With the USB drive already inserted, power on the device while
     holding the reset button. A white/orange flashing pattern will
     occur shortly after power on. Let go of the reset button. The
     device is now booting into OpenWrt initramfs stored on the USB
     disk.

  3. Connect by SSH to 192.168.1.1 and flash the embedded u-boot image,
     changing X as appropriate:
        `mtd write /root/uboot_mx6X /dev/mtd0`
     You do not need to reboot as this image can handle "Kernel-in-UBI"
     OpenWrt installation.

  4. You can proceed to obtain and flash the appropriate OpenWrt image
     at "OpenWrt Installation" Step 3.

  5. Reboot will take significantly longer due to Shmoo calibration. In
     case the device does not come online after several minute, power-
     cycle the device and see if it boots. If you see an orange/white
     flashing pattern, this indicates UBI booting was not successful and
     you will need to copy a new bcm53xx image to a USB disk before
     booting it and attempting to install OpenWrt again - refer to
     "OpenWrt Installation" step 1. Do not attempt to reflash u-boot in
     this scenario.

OpenWrt Installation:
  1. Having obtained an OpenWrt image, please copy the file
        `openwrt-bcm53xx-generic-meraki_XXXX-initramfs.bin`
     to the base directory of a FAT formatted USB drive using DOS
     partition scheme ,where XXXX is mx64, mx64_a0 or mx65 depending on
     which device you have.

  2. With the USB drive already inserted, power on the device. Boot time
     will be longer than usual while Shmoo calibration takes place. A
     different white/orange flashing pattern will eventually occur to
     indicate device is now booting into OpenWrt initramfs stored on the
     USB disk.

  3. Ensuring Ethernet is plugged into a LAN port with IP set in the
     192.168.1.0/24 subnet excluding 192.168.1.1, use SCP to copy the
     sysupgrade file to 192.168.1.1:/tmp, eg:
        `scp openwrt-bcm53xx-generic-meraki_XXXX-squashfs.sysupgrade.bin\
        192.168.1.1:/tmp`

  4. Connect by SSH to 192.168.1.1 and run sysupgrade:
        `sysupgrade \
        /tmp/openwrt-bcm53xx-generic-meraki_XXXX-squashfs.sysupgrade.bin`

  5. OpenWrt should now be installed on the device.

Signed-off-by: Matthew Hagan <mnhagan88@gmail.com>

[ Rebase kernel configuration for 6.6,
  fix failsafe by making kmod-eeprom-at24 and kmod-dsa-qca8k built-in,
  resolve conflicts,
  add LED aliases,
  fix eth0 MAC address at probe ]

TODO:
- fix multiple LED colors not applied despite aliases - due to custom
  /etc/diag.sh
- fix race condition between preinit and probing of the DSA tree,
  causing no network interface available in failsafe mode (in general
  case - to allow moving drivers back to modules)

Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/16634
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2024-10-22 00:39:32 +02:00
Lech Perczak
a69eaf8079 bcm53xx: enable CONFIG_I2C_BCM_IPROC
This is required for the AT24 EEPROM holding MAC address on Meraki
devices to probe before preinit starts, so all network devices can be
available at the preinit network setup starts

Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/16634
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2024-10-22 00:39:32 +02:00
Lech Perczak
64424c2427 bcm53xx: enable CONFIG_EEPROM_AT24
Meraki MX6x devices use them to store MAC address, so it is required to be
built-in for networking to probe properly, before preinit network setup
happens, which in turn is required for proper failsafe mode access.
Enable CONFIG_EEPROM_AT24 for the target.

Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/16634
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2024-10-22 00:39:32 +02:00
Mieczyslaw Nalewaj
5eb8b7793d bcm53xx: drop 6.1 support
Drop config and files for Linux 6.1.

Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Link: https://github.com/openwrt/openwrt/pull/16103
Signed-off-by: Robert Marko <robimarko@gmail.com>
2024-09-09 14:29:58 +02:00
Mieczyslaw Nalewaj
6babd1cc12 bcm53xx: drop 5.15 support
Drop config and files for Linux 5.15.

Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Link: https://github.com/openwrt/openwrt/pull/16103
Signed-off-by: Robert Marko <robimarko@gmail.com>
2024-09-09 14:29:58 +02:00
Rafał Miłecki
f0d8ce4f48 bcm53xx: add testing support for kernel 6.6
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
2024-03-28 00:06:26 +01:00
Rani Hod
802a5f5cb4 bcm53xx: build a single device per profile
So far every build of a single bcm53xx Target Profile (it means: when
NOT using CONFIG_TARGET_MULTI_PROFILE) resulted in all target devices
images being built. Now it only builds the one matching selected
profile.

Fixes: #13572

Suggested-by: Jonas Gorski <jonas.gorski@gmail.com>
Signed-off-by: Rani Hod <rani.hod@gmail.com>
[rmilecki: update commit subject + body & move PROFILES line]
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
2023-10-13 07:32:22 +02:00
Linus Walleij
ef76b6ff3e bcm53xx: Add support for D-Link DIR-890L
The DIR-890L is very similar to DIR-885L, but has both USB2
and USB3. The signature for the wrgac36 board was copied from
DD-Wrt.

The DIR-890L bootstrap will only load the first 2 MB after
the SEAMA header in the NAND flash, uncompress it with LZMA
and execute it. Since the compressed kernel will not fit in
2 MB we have a problem. Solve this by putting a LZMA
compressed U-Boot into the first 128 KB of the flash
followed by the kernel. The bootstrap will then uncompress
and execute U-Boot and then we let U-Boot read the kernel
from flash and execute it.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2023-08-28 08:13:39 +02:00
Arınç ÜNAL
2214bab350 bcm53xx: add support for ASUS RT-AC3100
ASUS RT-AC3100 is ASUS RT-AC88U without the external switch.

OpenWrt forum users effortless and ktmakwana have confirmed that there are
revisions with either 4366b1 or 4366c0 wireless chips.

Therefore, include firmware for 4366b1 along with 4366c0. This way, all
hardware revisions of the router will be supported by having brcmfmac use
the firmware file for the wireless chip it detects.

Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
2023-08-19 11:03:11 +02:00
Davide Fioravanti
f1136fe1fd bcm53xx: add Wavlink Quantum DAX/WL-WN538A8 as alt name
As already documented in the wiki (https://openwrt.org/toh/wavlink/quantum_dax_wn538a8),
this router is based on the Phicomm K3. Just the flashing method is different

Signed-off-by: Davide Fioravanti <pantanastyle@gmail.com>
2023-06-25 11:05:34 +02:00
Christian Lamparter
ec4d63ffb3 nu801: add kmod-leds-uleds to MR26 + MR18
support for MR18 and MR26 was developped before
the userspace nu801 was integrated with x86's
MX100 into OpenWrt. The initial nu801 + kmod-leds-uleds
caused build-bot errors.

The solution that worked for the MX100 was to include
the kmod-leds-uleds to the device platform module.
Thankfully, the MR26 and MR18 can just add the uleds
package to the DEVICE_PACKAGES variable.

Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
2023-05-18 16:17:52 +02:00
Linus Walleij
4d903a5009 bcm53xx: Add support for D-Link DWL-8610AP
The D-Link DWL-8610AP is a pretty straight-forward BC53016
device, D-Link has invented a firmware package format which
is a tar file, and we implement this for the factory image.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2023-02-26 22:22:48 +01:00
Rosen Penev
2630e5063d treewide: replace wpad-basic-wolfssl default
The newly merged mbedtls backend is smaller and has fewer ABI related
issues than the wolfSSL one.

Signed-off-by: Rosen Penev <rosenp@gmail.com>
2023-02-04 02:35:03 +01:00
Arınç ÜNAL
2b9bb5b187 bcm53xx: enable Broadcom 4366b1 firmware for Asus RT-AC88U
On some of the hardware revisions of Asus RT-AC88U, brcmfmac detects the
4366b1 wireless chip and tries to load the firmware file which doesn't
exist because it's not included in the image.

Therefore, include firmware for 4366b1 along with 4366c0. This way, all
hardware revisions of the router will be supported by having brcmfmac use
the firmware file for the wireless chip it detects.

Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
2022-10-21 08:50:51 +02:00
Christian Lamparter
e37ba80633 bcm53xx: add support for Meraki MR26
Meraki MR26 is an EOL wireless access point featuring a
PoE ethernet port and two dual-band 3x3 MIMO 802.11n
radios and 1x1 dual-band WIFI dedicated to scanning.

Thank you Amir for the unit and PSU.

Hardware info:
SOC   : Broadcom BCM53015A1KFEBG (dual-core Cortex-A9 CPU at 800 MHz)
RAM   : SK hynix Inc. H5TQ1G63EFR, 1 Gbit DDR3 SDRAM = 128 MiB
NAND  : Spansion S34ML01G100TF100, 1 Gbit SLC NAND Flash = 128 MiB
ETH   : 1 GBit Ethernet Port - PoE
WIFI1 : Broadcom BCM43431KMLG, BCM43431 802.11 abgn
WIFI1 : Broadcom BCM43431KMLG, BCM43431 802.11 abgn
WIFI3 : Broadcom BCM43428 abgn (1x1:1 - id: 43428)
BUTTON: one reset button
LEDS  : RGB-LED
MISC  : Atmel AT24C64 8KiB EEPROM (i2c - seems empty)
      : Ti INA219 26V, 12-bit, i2c output current/voltage/power monitor
      : TPS23754, High Power/High Efficiency PoE Interface+DC/DC Controller

SERIAL:
	WARNING: The serial port needs a TTL/RS-232 3V3 level converter!
	The Serial setting is 115200-8-N-1. The board has a populated
	right angle 1x4 0.1" pinheader.
	The pinout is: VCC (next to J3, has little white arrow), RX, TX, GND.

This flashing procedure for the MR26 was tested with firmware:
    "22-143410M-gf25cbf5a-asa".
    U-Boot 2012.10-00063-g83f9fe4 (Jun 04 2014 - 21:22:39)

A guide how to open up the device is available on the wiki:
<https://openwrt.org/toh/meraki/mr26>

Notes:
 - The WIFI do work to a degree. Limited to 802.11bg in the 2.4GHz band.
 - the WIFI macs are made up.

0. Create a separate Ethernet LAN which can't have access to the internet.
   Ideally use 192.168.1.2 for your PC. The new OpenWrt firmware will setup
   the network via DHCP Discovery, so make sure your PC is running
   a DHCP-Server (i.e.: dnsmasq)
   '# dnsmasq -i eth# -F 192.168.1.5,192.168.1.50
   Download the openwrt-meraki-mr26 initramfs file from openwrt.org and
   rename it to something simple like mr26.bin. Then put it into the tftp's
   server directory.

1. Disassemble the MR26 device by removing all screws (4 screws are located
   under the 4 rubber feets!) and prying open the plastic covers without
   breaking the plastic retention clips. Once inside, remove the plastic
   back casing. Be careful, there some "hidden" retention clips on both
   sides of the LAN port, you need a light to see those. Next, you want to
   remove all the screws on the outer metal shielding to get to the PCB.
   It's not necessary to remove the antennas!

2. Connect the serial cable to the serial header and Ethernet patch cable
   to the device.

4. Before connecting the power, get ready flood the serial console program
   with the magic:   xyzzy  . This is necessary in order to get into the
   u-boot prompt. Once Ready: connect power cable.

5. If you don't get the "u-boot>" prompt within the first few seconds,
   you have to disconnect and reconnect the power cable and try again.

6. In the u-boot prompt enter:

   setenv ipaddr 192.168.1.4
   setenv serverip 192.168.1.2
   tftpboot ${meraki_loadaddr} mr26.bin; bootm

   this will boot a in-ram-only OpenWrt image.

7. Once it booted use sysupgrade to permanently install OpenWrt.
   To do this: Download the latest sysupgrade.bin file and move
   it to the device. Then use sysupgrade *sysupgrade.bin to install it.

    WARNING: DO NOT DELETE the "storage" ubi volume!

Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
2022-07-15 15:21:44 +02:00
Arınç ÜNAL
5c1b1918ab bcm53xx: remove BROKEN flag from Asus RT-AC88U
The image builds and works fine on Asus RT-AC88U. Therefore, remove the
BROKEN flag from the makefile.

Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
2022-06-07 16:16:56 +02:00
SHIMAMOTO Takayoshi
fc94c0d203 bcm53xx: add switch ports for Buffalo WZR-900DHP & re-enable it
Specify the switch ports in the DTS file.
Re-enable it after it was disabled by commit e9672b1a8f ("bcm53xx: switch to the
upstream DSA-based b53 driver").

Signed-off-by: SHIMAMOTO Takayoshi <takayoshi.shimamoto.360@gmail.com>
[rmilecki: reword commit & drop unneeded whitespace change]
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
2022-03-30 16:20:50 +02:00
Arınç ÜNAL
72b9b721d7 bcm53xx: add support for Asus RT-AC88U
Asus RT-AC88U is an AC3100 router featuring 9 Ethernet ports over the
integrated Broadcom and the external Realtek switch.

Hardware info:
* Processor: Broadcom BCM4709C0KFEBG dual-core @ 1.4 GHz
* Switch: BCM53012 in BCM4709C0KFEBG & external RTL8365MB
* DDR3 RAM: 512 MB
* Flash: 128 MB (ESMT F59L1G81LA-25T)
* 2.4GHz: BCM4366 4×4 2.4/5G single chip 802.11ac SoC
* 5GHz: BCM4366 4×4 2.4/5G single chip 802.11ac SoC
* Ports: 8 Ports, 1 WAN Ports

Flashing instructions:
* Boot to CFE Recovery Mode by holding the reset button while power-on.
* Connect to the router with an ethernet cable.
* Set IPv4 address of the computer to 192.168.1.2 subnet 255.255.255.0.
* Head to http://192.168.1.1.
* Reset NVRAM.
* Upload the OpenWrt image.

CFE bootloader may reject flashing the image due to image integrity check.
In that case, follow the instructions below.

* Rename the OpenWrt image as firmware.trx.
* Run a TFTP server and make it serve the firmware.trx file.
* Run the URL below on a browser or curl.
  http://192.168.1.1/do.htm?cmd=flash+-noheader+192.168.1.2:firmware.trx+flash0.trx

Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
[rmilecki: mark BROKEN until we sort out nvram & CFE recovery]
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
2022-03-29 16:10:07 +02:00
Christian Lamparter
6102f883ce bcm53xx: MR32: replace i2c-gpio with SoC's i2c
During review of the MR32, Florian Fainelli pointed out that the
SoC has a real I2C-controller. Furthermore, the connected pins
(SDA and SCL) would line up perfectly for use. This patch swaps
out the the bitbanged i2c-gpio with the real deal.

Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
2021-10-30 15:00:22 +02:00
Rafał Miłecki
e9672b1a8f bcm53xx: switch to the upstream DSA-based b53 driver
1. Drop swconfig
2. Simplify network setup
3. Verify network config
4. Disable Buffalo WZR-900DHP for now - it misses ports definition

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Reviewed-By: Christian Lamparter <chunkeey@gmail.com>
2021-10-21 17:38:17 +02:00
Rafał Miłecki
287257d676 bcm53xx: enable Linksys EA6300 & EA9200 builds
Both should be supported since:
1. Adding NVMEM driver for NVRAM
2. Using NVRAM info for determining active firmware partition

Linksys EA9500 uses very similar design and works fine.

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
2021-10-18 16:09:36 +02:00
Damien Mascord
fd67908647 scripts: mkits.sh: Allow legacy @ mode for dts creation
commit 5ec60cbe9d ("scripts: mkits.sh: replace @ with - in nodes")
broke support for Meraki MR32 and this patch makes the replacement
configurable allowing for specifying the @ or - or whatever character
that is desired to retain backwards compatibility with existing devices.

For example, this patch includes the fix for the Meraki MR32 in
target/linux/bcm53xx/image for meraki_mr32:

  DEVICE_DTS_DELIMITER := @
  DEVICE_DTS_CONFIG := config@1

Fixes: 5ec60cbe9d ("scripts: mkits.sh: replace @ with - in nodes")
Signed-off-by: Damien Mascord <tusker@tusker.org>
[Added tags, checkpatch.pl fixes, noted that this is for old stuff]
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
2021-09-23 20:49:32 +02:00
Vivek Unune
209c5918b5 bcm53xx: enhance support for Linksys EA9500
1. Add leds and configs
2. Add network configs
3. Add script to clear partial boot flag
4. Hack to use port 5 as cpu port as port 8 connected to eth2
   wont pass any frames
5. Enable EA9500 image generation

Hardware Info:

- Processor - Broadcom BCM4709C0KFEBG dual-core @ 1.4 GHz
- Switch - BCM53012 in BCM4709C0KFEBG & external BCM53125
- DDR3 RAM - 256 MB
- Flash - 128 MB (Toshiba TC58BVG0S3HTA00)
- 2.4GHz - BCM4366 4×4 2.4/5G single chip 802.11ac SoC
- Power Amp - Skyworks SE2623L 2.4 GHz power amp (x4)
- 5GHz x 2 - BCM4366 4×4 2.4/5G single chip 802.11ac SoC
- Power Amp - PLX Technology PEX8603 3-lane, 3-port PCIe switch
- Ports - 8 Ports, 1 WAN Ports
- Antennas - 8 Antennas
- Serial Port - @j6 [GND,TX,RX] (VCC NC) 115200 8n1

Flashing Instructions:

1. Connect a USB-TTL table to J6 on the router as well as a
   ethernet cable to a lan port and your PC.
2. Power-on the router.
3. Use putty or a serial port program to view the terminal.
   Hit Ctrl+C and interrupt the CFE terminal terminal.
4. Setup a TFTP server on your local machine at setup you
   local IP to 192.168.1.2
5. Start the TFTP Server
6. Run following commands at the CFE terminal

   flash -noheader 192.168.1.2:/openwrt.trx nflash0.trx
   flash -noheader 192.168.1.2:/openwrt.trx nflash0.trx2
   nvram set bootpartition=0 && nvram set partialboots=0 && nvram commit

7. Reboot router to be presented by OpenWrt

Note: Only installation method via serial cable is supported at the moment.
The trx firmware has to be flashed to both the partitions using following
commands from CFE prompt. This will cover US and Non-US variants.

Signed-off-by: Vivek Unune <npcomplete13@gmail.com>
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
2021-04-01 08:58:14 +02:00
Adrian Schmutzler
ef2cb8572b treewide: rename IMAGE_PREFIX/IMAGE_NAME to DEVICE_IMG_*
We so far had two variables IMG_PREFIX and IMAGE_PREFIX with
different content. Since these names are obviously quite
confusing, this patch renames the latter to DEVICE_IMG_PREFIX,
as it's a device-dependent variable, while IMG_PREFIX is only
(sub)target-dependent.

For consistency, also rename IMAGE_NAME to DEVICE_IMG_NAME, as
that's a device-dependent variable as well.

Cc: Paul Spooren <mail@aparcar.org>
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2021-02-25 18:11:06 +01:00
Adrian Schmutzler
598b29585e target: use SPDX license identifiers on Makefiles
Use SPDX license tags to allow machines to check licenses.

Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2021-02-10 15:47:18 +01:00
Adrian Schmutzler
4571ef48d8 bcm53xx: use default SUPPORTED_DEVICES for Meraki MR32
Since the new global SUPPORTED_DEVICES are now available in bcm53xx
as well, we do not need to specify an explicit value for the MR32
anymore.

Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2021-01-23 23:42:47 +01:00
Moritz Warning
d69ec61f7d bcm53xx: use correct case for TP-Link in DEVICE_VENDOR
Adjust spelling of vendor names to what is used in other places.

Signed-off-by: Moritz Warning <moritzwarning@web.de>
[improve commit title/message]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2020-12-19 19:42:00 +01:00
Christian Lamparter
c29f6121fd bcm53xx: MR32: fix DEVICE_VENODR typo
DEVICE_VENDOR was misspelled as DEVICE_VENODR.

Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
2020-12-13 17:16:36 +01:00
Christian Lamparter
0e4092cbad bcm53xx: add Cisco Meraki MR32
This patch adds support for Cisco Meraki MR32.
The unit was donated by Chris Blake. Thank you!

WARNING:
Only the 1x1:1 abgn Air Marshal WIPS wifi is currently supported by b43:
 b43-phy2: Found PHY: Analog 9, Type 4 (N), Revision 16
 b43-phy2: Found Radio: Manuf 0x17F, ID 0x2057, Revision 9, Version 1
 b43-phy2: Loading firmware version 784.2 (2012-08-15 21:35:19)
 and only as 802.11ABG!

while WIFI1 and WIFI2 (both BCM4352) are not:
 b43-phy0: Broadcom 4352 WLAN found (core revision 42)
 b43-phy0 ERROR: FOUND UNSUPPORTED PHY (Analog 12, Type 11 (AC), Revision 1)

Hardware Highlights:

SoC:	Broadcom BCM53016A1 (1 GHz, 2 cores)
RAM:	128 MiB
NAND:	128 MiB Spansion S34ML01G2 (~114 MiB useable)
ETH:	1GBit Ethernet Port - PoE
WIFI1:	Broadcom BCM43520 an+ac (2x2:2 - id: 0x4352)
WIFI2:	Broadcom BCM43520 bgn (2x2:2 - id: 0x4352)
WIFI3:	Broadcom BCM43428 abgn (1x1:1 - id: 43428)

BLE:	Broadcom BCM20732 (ttyS1)
LEDS:   1 x Programmable RGB Status LED (driven by a PWM)
	1 x White LED (GPIO)
	1 x Orange LED Fault Indicator (GPIO)
	2 x LAN Activity / Speed LEDs (On the RJ45 Port)
BUTTON: one Reset button
MISC:   AT24C64 8KiB EEPROM (i2c - stores Ethernet MAC + Serial#!)
	ina219 hardware monitor (i2c)
	Kensington Lock

SERIAL:
	WARNING: The serial port needs a TTL/RS-232 3V3 level converter!
	The Serial setting is 115200-8-N-1. The board has a populated
	right angle 1x4 0.1" pinheader.
	The pinout is: VCC, RX, TX, GND. (Use a multimeter)

Flashing needs a serial adaptor (due to the lack of a working dropbear on
the original firmware).

This flashing procedure for the MR32 was tested with firmware:
"r23-149867:150252-aacharya".

0. Create a seperate Ethernet LAN which does not have access to the internet.
   Ideally use 192.168.1.2 for your PC. Make sure to reserve 192.168.1.1 it
   will be used later on by the OpenWrt firmware. The original Meraki firmware
   will likely try to setup the network via DHCP Discovery, so make sure your
   PC is running a DHCP-Server (i.e.: dnsmasq)
   '# dnsmasq -i eth# -F 192.168.1.5,192.168.1.50
   Furthermore, the PC needs a supported ssh/http/ftp server in order to
   retrieve the initramfs + dtb file

1. Disassemble the MR32 device by removing all screws (4 screws are located
   under the 4 rubber feets!) and prying open the plastic covers without
   breaking the plastic retention clips. Once inside, remove all the screws
   on the outer metal shielding to get to the PCB. It's not necessary to
   remove the antennas!

2. Connect the serial cable to the serial header.

3. Partially reassemble the outer metal shielding to ensure that the SoC
   has a proper heat sink.

4. Connect the Ethernet patch cable to the device and the power cable.

5. Wait for the device to boot and enter the root shell.
   (rooting is not discussed in detail here please refer to
   Chris Blake - "pwning the meraki mr18" blog post:
   <https://servernetworktech.com/2016/02/pwning-the-meraki-mr18/>
   (The same method works with the MR32's r23-149867:150252-aacharya)

   Wait for the MR32 to enter the "<Meraki>" prompt and enter:
   <Meraki> odm serial_num read
   (Verify that it matches what's on the S/N Sticker on the back!)
   <Meraki> odm serial_num write Q2XX-XXXX-XXXV
   <Meraki> odm serial_num read
   (Verify that the S/N has changed - and the LED start to flash)

   now to flash the firmware:
   <Meraki> odm firmware part.safe "http://192.168.1.2/mr32-initramfs.bin"

Once OpenWrt booted use sysupgrade to permanently install
OpenWrt. To do this: Download the latest sysupgrade.bin file
for the MR32 to the device and use sysupgrade *sysupgrade.bin
to install it.

WARNING: DO NOT DELETE the "storage" ubi volume!

To flash later MR32 Firmwares like r25-201804051805-G885d6d78-dhow-rel
requires in-circut-i2c tools to access the I2C EEPROM AT24C64 next to
the SoC. The idea is pretty much the same as from Step 5 from above:
Change the serial number to Q2XXXXXXXXXV (should be around 0x7c), then
attach a serial cable, ethernet (but make sure the device can't reach
the internet!) hit "s" (the small s!) during boot to enter the root-shell
and add the following commands to the /storage/config there:

serial_allow_odm true
serial_access_enabled true
serial_access_check false
valid_config true

and then hit exit to let it finish booting.

Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
2020-09-25 19:32:34 +02:00
Petr Štetiar
a14f5bb4bd treewide: use wpad-basic-wolfssl as default
In order to support SAE/WPA3-Personal in default images. Replace almost
all occurencies of wpad-basic and wpad-mini with wpad-basic-wolfssl for
consistency. Keep out ar71xx from the list as it won't be in the next
release and would only make backports harder.

Build-tested (build-bot settings):
ath79: generic, ramips: mt7620/mt76x8/rt305x, lantiq: xrx200/xway,
sunxi: a53

Signed-off-by: Petr Štetiar <ynezz@true.cz>
[rebase, extend commit message]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2020-08-20 14:19:39 +02:00
Adrian Schmutzler
683bcbdce1 bcm53xx: use vendor_model scheme for device/image names
Most targets have been updated to consistently use the vendor_model
scheme for device definitions and thus, image names.

Apply this to bcm53xx as well. This does _not_ apply any other
specific naming changes.

Cc: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2020-08-12 11:08:05 +02:00
Petr Štetiar
e9f7923a1d treewide: mark devices as BROKEN instead of commenting out
This adds the newly introduced BROKEN flag to a bunch of devices
that previously just had TARGET_DEVICES commented out. By this, we
can select them in make menuconfig when BROKEN developer config option
is selected, instead of having to edit the code.

In contrast to DEFAULT := n, this is meant to cover devices that
don't boot or don't compile at all.

ath25: np25g, wpe53g
  both disabled during kernel bump 3.18->4.4 without reason given
  f89a20a89a ("ath25: update kernel from 3.18 to 4.4")

bcm53xx: linksys-ea6300-v1, linksys-ea9200, linksys-ea9500
  broken due to insufficient/broken TRX support
  55ff15cfd5 ("bcm53xx: disable building Linksys EA6300 V1 image")
  cd0f9900a4 ("bcm53xx: parepare for building more Linksys images")

bcm63xx: tplink-archer-c5-v2, tplink-archer-c9-v1
  disabled when kernel 5.4 support was added, probably broken
  50c6938b95 ("bcm53xx: add v5.4 support")

Signed-off-by: Petr Štetiar <ynezz@true.cz>
[limit to subset of devices, use BROKEN, adjust commit message/title]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2020-07-30 21:49:22 +02:00
Petr Štetiar
504000d520 treewide: use DEFAULT := n to disable non-broken devices
This uses DEFAULT := n on a bunch of devices that previously were
"disabled" by commenting out TARGET_DEVICES. This will allow to
build them without having to modify the code, but they will not
be selected for default build or buildbots.

The change is applied to all devices that are not "broken", but suffer
from image site limitations or similar, or have been added in the past
but never confirmed to run on the device properly:

at91: at91-q5xr5:
  kernel image too big
  31aeae0774 ("at91: do not build image for at91-q5xr5")

bcm47xx: asus-rt-ac66u:
  disabled since it was added in 2015
  69aefc771f ("brcm47xx: build images for Asus devices")

bcm47xx: netgear-wndr3400-vcna, netgear-wnr3500u, netgear-wnr3500-v2-vc
  added disabled in 2012, but never confirmed to work on devices
  5dec9dd3b2 ("brcm47xx: add code to generate images for some netgear
    devices")

bcm53xx: netgear-r8500
  added disabled: "start working on Netgear R8500"
  3b76c7cf0b ("bcm53xx: start working on Netgear R8500")

Signed-off-by: Petr Štetiar <ynezz@true.cz>
[limit to subset of devices, adjust commit message/title]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2020-07-30 21:48:38 +02:00
Dan Haab
c459a6bf48 bcm53xx: add support for Luxul FullMAC WiFi devices
This prepares support for models XAP-1610 and XWR-3150. Flashing
requires using Luxul firmware version:
1) 8.1.0 or newer for XAP-1610
2) 6.4.0 or newer for XWR-3150
and uploading firmware using "Firmware Update" web UI page.

Signed-off-by: Dan Haab <dan.haab@legrand.com>
2020-04-07 15:27:52 +02:00
Rafał Miłecki
0493d57e04 bcm53xx: fix ASUS firmwares to use vendor format
Image building process was missing "asus-trx" step which resulted in raw
TRX files (without ASUS footer with device id).

Fixes: 0b9de8daa7 ("bcm53xx: add profiles for all other (SoftMAC) devices")
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
2020-03-02 22:06:02 +01:00
John Crispin
50c6938b95 bcm53xx: add v5.4 support
Signed-off-by: John Crispin <john@phrozen.org>
2020-02-28 17:50:46 +01:00
Dan Haab
1d47f81581 bcm53xx: build images for Luxul ABR-4500 and XBR-4500 routers
Luxul ABR-4500 and XBR-4500 devices are wired routers with 5 Ethernet
ports and 1 USB 3.0 port. Flashing requires using Luxul firmware 6.4.0
or newer and uploading firmware using "Firmware Update" web UI page.

Signed-off-by: Dan Haab <dan.haab@legrand.com>
2020-02-07 09:31:22 +01:00
Moritz Warning
3bef16bb30 bcm53xx: split up DEVICE_TITLE
DEVICE_TITLE is split up into DEVICE_VENDOR, DEVICE_MODEL and DEVICE_VARIANT

Signed-off-by: Moritz Warning <moritzwarning@web.de>
2019-08-02 22:45:02 +02:00
Hao Dong
62dadcb86c bcm53xx: add support for Phicomm K3
Hardware specifications:

- CPU: Broadcom BCM4709C0 @1.4GHz (Dual-Core ARM)
- RAM: 512 MB (DDR3)
- Flash: 128 MB (NAND)
- LAN ports: 3, LAN speed: 10/100/1000
- WAN ports: 1, WAN speed: 10/100/1000
- 2.4G: BCM4366 4x4 MIMO 1000Mbps -- Skyworks SE2623L 2.4GHz Power Amplifier (x4)
- 5G: BCM4366 4x4 MIMO 2167Mbps -- RFMD RFPA5542 5GHz Power Amplifier Module (x4)
- USB: 1x USB 3.0 port
- 1x LED, 1x reset button, 1x power switch
- 1x system status touch screen

Flash:

- Enter CFE
- Upload the trx file
- Reboot

Signed-off-by: Hao Dong <halbertdong@gmail.com>
2019-01-20 23:34:44 +01:00
Rafał Miłecki
4472df23da bcm53xx: include WiFi firmware for devices with 4366C0
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
2018-12-17 12:51:06 +01:00
Mathias Kresin
80c61c161a treewide: use wpad-basic for not small flash targets
Add out of the box support for 802.11r and 802.11w to all targets not
suffering from small flash.

Signed-off-by: Mathias Kresin <dev@kresin.me>

Mathias did all the heavy lifting on this, but I'm the one who should
get shouted at for committing.

Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
2018-10-16 15:07:41 +01:00
Rene Kjellerup
53be2d2a4e bcm53xx: added basic dts for linksys ea6500v2
only thing not working is the b43 5GHz wifi band as upstream
kernel
doesn't supporthe 0x4360 chip so far

Signed-off-by: Rene Kjellerup <rk.katana.steel@gmail.com>
2018-10-07 02:12:06 +02:00
Rafał Miłecki
c3d9109fad bcm53xx: drop not ready support for Luxul devices
Support for these devices isn't ready yet and it was only accidentally
pushed in the commit 0da9303e5b ("mac80211: backport "brcmfmac:
cleanup and some rework" from 4.17").

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
2018-06-18 08:46:23 +02:00
Rafał Miłecki
0da9303e5b mac80211: backport "brcmfmac: cleanup and some rework" from 4.17
It was described by Arend as:

> This series is intended for 4.17 and includes following:
>
>  * rework bus layer attach code.
>  * remove duplicate variable declaration.

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
2018-06-17 22:46:29 +02:00
Rafał Miłecki
370ce1fb48 bcm53xx: use otrx for creating TRX images
The advantage is that we don't have to specify max TRX size anymore and
otrx doesn't allocate a buffer of that size. It saves us allocating
32 MiB for every image we generate.

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
2017-11-17 11:43:33 +01:00
Florian Fainelli
7f0a32e21c bcm53xx: Fix SmartRG SR400AC initramfs image
The SmartRG SR400AC CFE does not accept a TRX image, just a normal
binary image.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
2017-10-23 18:39:29 -07:00
Rafał Miłecki
c00fbaf670 bcm53xx: include wpad-mini only on devices with (supported) wireless
Don't include wpad-mini when it's useless just like we don't include
useless wireless drivers.

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
2017-06-08 22:25:00 +02:00
Rafał Miłecki
0a05fbd135 bcm53xx: add support for TP-LINK Archer C5 V2
This model also contains few partitions non-discoverable partitions we
need to "protect". Othen than that it uses non-deprecated serial entry
in DTS that doesn't work with LEDE so we need to workaround it as well.

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
2017-05-21 18:31:38 +02:00
Rafał Miłecki
2ebfdabfbd bcm53xx: put kernel into TRX when building initramfs images
Many (most?) devices can't boot raw kernel using tftp and probably none
allows flashing it. It's way more usable to have TRX with kernel
containing initrams as such an image can be actually flashed.

An exception are Buffalo devices which have recovery mode with support
for booting kernels over TFTP. For them keep building default images.

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
2017-03-27 10:41:36 +02:00