Commit Graph

24 Commits

Author SHA1 Message Date
Bjørn Mork
1fb413e657 realtek: build ZyXEL vendor firmware compatible initramfs
Append a device specific version trailer used by the stock
firmware upgrade application to validate firmwares.

The trailer contains a list of ZyXEL firmware version
numbers, which includes a four letter hardware identifier.
The stock web UI requires that the current hardware matches
one of the listed versions, and that the version number is
larger than a model specific minimum value. The minimum
version varies between V1.00 and V2.60 for the currently
known GS1900 models. The number is not used anywhere else
to our knowlege, and has no direct relation to the version
info in the u-image header.  We can therefore use an
arbitrary value larger than V2.60.

The stock firmware upgrade application will only load and
flash the part of the file specified in the u-image header,
regardless of file size.  It can therefore not be used to
flash images with an appended rootfs. There is therefore no
need to include the trailer in other images than the
initramfs. This prevents accidentally bricking by attempts
to flash other images from the stock web UI.

Stock images support all models in the series, listing
all of them in the version trailer.  OpenWrt provide model
specific images.  We therefore only list the single supported
hardware identifier for each image.  This eliminates the risk
of flashing the wrong OpenWrt image from stock web UI.

OpenWrt can be installed from stock firmware in two steps:

   1) flash OpenWrt initramfs image from stock web gui
   2) boot OpenWrt and sysupgrade to a squasfs image

The OpenWrt squashfs image depends on a static partition
map in the DTS.  It can only be installed to the "firmware"
partition.  This partition is labeled "RUNTIME1" in u-boot
and in stock firmware, and is referred to as "image 0" in
the stock flash management tool.  The OpenWrt initramfs
can be installed and run from either partitions. But if
you want to keep stock irmware in the spare system partition,
then you must make sure stock firmware is installed to the
"RUNTIME2" partition referred to as "image 1" in the stock
web UI. And the initial OpenWrt initramfs must be flashed
to "RUNTIME1"/"image 0".

The stock flash management application supports direct
selection of both which partition to flash and which
partition to boot next.  This allows software controlled
"dual-boot" between OpenWrt and stock firmware, without
using console access to u-boot. u-boot use the "bootpartition"
variable stored in the second u-boot environment to select
which of the two system partitions to boot.  This variable
is set by the stock flash management application, by direct
user input.  It can also be set in OpenWrt using e.g

 fw_setsys bootpartition 1

to select "RUNTIME2"/"image 1" as default, assuming a
stock firmware version is installed in that partition.

Signed-off-by: Bjørn Mork <bjorn@mork.no>
2021-01-24 18:12:34 +01:00
Bjørn Mork
ca4832fcac realtek: use vendor-specific magic for ZyXEL
The stock firmware of the ZyXEL GS1900 series use a non-standard
u-image magic.  This is not enforced by the stock u-boot, which is
why we could boot images with the default magic.  The flash
management application of the stock firmware will however verify
the magic, and refuse any image with another value.

Convert to vendor-specific value to get flash management support
in stock firmware, including the ability to upgrade to OpenWrt
directly from stock web UI.

Signed-off-by: Bjørn Mork <bjorn@mork.no>
2021-01-24 18:12:34 +01:00
Adrian Schmutzler
f52081bcf9 treewide: provide global default for SUPPORTED_DEVICES
The majority of our targets provide a default value for the variable
SUPPORTED_DEVICES, which is used in images to check against the
compatible on a running device:

  SUPPORTED_DEVICES := $(subst _,$(comma),$(1))

At the moment, this is implemented in the Device/Default block of
the individual targets or even subtargets. However, since we
standardized device names and compatible in the recent past, almost
all targets are following the same scheme now:

  device/image name:  vendor_model
  compatible:         vendor,model

The equal redundant definitions are a symptom of this process.

Consequently, this patch moves the definition to image.mk making it
a global default. For the few targets not using the scheme above,
SUPPORTED_DEVICES will be defined to a different value in
Device/Default anyway, overwriting the default. In other words:
This change is supposed to be cosmetic.

This can be used as a global measure to get the current compatible
with: $(firstword $(SUPPORTED_DEVICES))
(Though this is not precisely an achievement of this commit.)

Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2021-01-23 12:45:21 +01:00
Bjørn Mork
ff7709d223 kernel: mtdsplit_uimage: replace "netgear, uimage" parser
The "netgear,uimage" parser can be replaced by the generic
parser using device specific openwrt,ih-magic and
openwrt,ih-type properties.

Device tree properties for the following devices have not
been set, as they have been dropped from OpenWrt with the
removal of the ar71xx target:

 FW_MAGIC_WNR2000V1     0x32303031
 FW_MAGIC_WNR2000V4     0x32303034
 FW_MAGIC_WNR1000V2_VC  0x31303030
 FW_MAGIC_WPN824N       0x31313030

Tested-by: Sander Vanheule <sander@svanheule.net>  # WNDR3700v2
Tested-by: Stijn Segers <foss@volatilesystems.org> # WNDR3700v1
Signed-off-by: Bjørn Mork <bjorn@mork.no>
2021-01-22 21:03:11 +01:00
Bjørn Mork
647fdafcc5 kernel: mtdsplit_uimage: replace "allnet, uimage" parser
Convert users to the generic "openwrt,uimage" using device specific
"openwrt,ih-magic" properties, and remove "allnet,uimage".

Signed-off-by: Bjørn Mork <bjorn@mork.no>
2021-01-22 21:03:11 +01:00
John Audia
4ebec0b3e2 kernel: bump 5.4 to 5.4.87
All modification by update_kernel.sh.

Build system: x86_64
Build-tested: ipq806x/R7800, bcm27xx/bcm2711
Run-tested: ipq806x/R7800

No dmesg regressions, everything functional

Compile-tested [*]: ath79/{generic,tiny}, ipq40xx, octeon,
                    ramips/mt7621, realtek, x86/64.
Run-tested [*]:     ramips/mt7621 (DIR-878 A1, R6800, RT-AC57U),
                    octeon (EdgeRouter Lite).

Signed-off-by: John Audia <graysky@archlinux.us>
Tested-by: Stijn Segers <foss@volatilesystems.org> [*]
2021-01-08 21:09:17 +01:00
Stijn Segers
c4bfe68c83 realtek: add support for ZyXEL GS1900-8HP v1 and v2
The ZyXEL GS1900-8HP is an 8 port gigabit switch with PoE+ support.
There are two versions on the market (v1 & v2) which share similar
specs (same flash size and flash layout, same RAM size, same PoE+ power
envelope) but have a different case and board layout that they each
share with other GS1900 siblings.

The v1 seems to share its PCB and case with non-PoE GS1900-8; as such,
adding support for the GS1900-8 would probably be trivial. The v2 seems
to share its casing and platform with its already supported bigger
brother, the GS1900-10HP - its board looks the same, except for two
holes where the GS1900-10 has its SFP ports.

Like their 10 port sibling, both devices have a dual firmware layout.
Both GS1900-8HP boards have the same 70W PoE+ power budget. In order to
manipulate the PoE+, one needs the rtl83xx-poe package [1].

After careful consideration it was decided to go with separate images
for each version.

Specifications (v1)
-------------------
* SoC:       Realtek RTL8380M 500 MHz MIPS 4KEc
* Flash:     Macronix MX25L12835F 16 MiB
* RAM:       Nanya NT5TU128M8HE-AC 128 MiB DDR2 SDRAM
* Ethernet:  8x 10/100/1000 Mbit
* PoE+:      Broadcom BCM59111KMLG (IEEE 802.3at-2009 compliant, 2x)
* UART:      1 serial header with populated standard pin connector on the
             left side of the PCB, towards the bottom. Pins are labeled:
             + VCC (3.3V)
             + TX
             + RX
             + GND

Specifications (v2)
-------------------
* SoC:       Realtek RTL8380M 500 MHz MIPS 4KEc
* Flash:     Macronix MX25L12835F 16 MiB
* RAM:       Samsung K4B1G0846G 128 MiB DDR3 SDRAM
* Ethernet:  8x 10/100/1000 Mbit
* PoE+:      Broadcom BCM59121B0KMLG (IEEE 802.3at-2009 compliant)
* UART:      1 angled serial header with populated standard pin connector
             accessible from outside through the ventilation slits on the
             side. Pins from top to bottom are clearly marked on the PCB:
             + VCC (3.3V)
             + TX
             + RX
             + GND

Serial connection parameters for both devices: 115200 8N1.

Installation
------------
Instructions are identical to those for the GS1900-10HP and apply both
to the GS1900-8HP v1 and v2 as well.

* Configure your client with a static 192.168.1.x IP (e.g. 192.168.1.10).
* Set up a TFTP server on your client and make it serve the initramfs
  image.
* Connect serial, power up the switch, interrupt U-boot by hitting the
  space bar, and enable the network:
  > rtk network on
* Since the GS1900-10HP is a dual-partition device, you want to keep the
  OEM firmware on the backup partition for the time being. OpenWrt can
  only boot off the first partition anyway (hardcoded in the DTS). To
  make sure we are manipulating the first partition, issue the following
  commands:
  > setsys bootpartition 0
  > savesys
* Download the image onto the device and boot from it:
  > tftpboot 0x84f00000 192.168.1.10:openwrt-realtek-generic-zyxel_gs1900-8hp-v{1,2}-initramfs-kernel.bin
  > bootm
* Once OpenWrt has booted, scp the sysupgrade image to /tmp and flash it:
  > sysupgrade /tmp//tmp/openwrt-realtek-generic-zyxel_gs1900-8hp-v{1,2}-squashfs-sysupgrade.bin

Signed-off-by: Stijn Segers <foss@volatilesystems.org>
[merge PoE case, keep device definitions separate, change all those
hashes in the commit message to something else so they don't get
removed when changing the commit ...]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2021-01-08 20:48:22 +01:00
Adrian Schmutzler
40ea2fea4f realtek: remove model prefix from LED label for ZyXEL GS1900
This is used as fixed status LED, so no migration is needed.

Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2021-01-08 20:39:02 +01:00
Stijn Segers
0542cb6a2b realtek: introduce shared DTSI for GS1900 series
The ZyXEL GS1900-8HP v1, v2 and GS1900-10HP are all built on a similar
Realtek RTL8380M platform. Create a common DTSI in preparation for
GS1900-8HP support, and switch to the macros defined in rtl838x.dtsi.

Signed-off-by: Stijn Segers <foss@volatilesystems.org>
[drop redundant includes, use &mdio directly, do not replace SFP
ports]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2021-01-08 20:39:02 +01:00
Stijn Segers
e1f5ffa48c realtek: ZyXEL: spell as done by manufacturer
ZyXEL spells its own name all uppercase with just the Y lowercase. Adapt
the realtek target to follow this (other OpenWrt targets already do so).

Signed-off-by: Stijn Segers <foss@volatilesystems.org>
2021-01-07 19:51:50 +01:00
Stijn Segers
5bdf50d13b realtek: move memory node to device DTS
Move the memory out of the rtl838x.dtsi and into the device family DTSI
or device DTS if applicable. This aligns with upstream practice.

Signed-off-by: Stijn Segers <foss@volatilesystems.org>
[add missing block for dgs-1210-10p, move block below chosen node]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2021-01-07 19:51:50 +01:00
Adrian Schmutzler
5f958cb21f realtek: remove duplicate '/dts-v1/;' identifier
The identifier is already present in rtl838x.dtsi, and adding it
twice is not only redundant but actually wrong.

Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2021-01-07 19:51:50 +01:00
Stijn Segers
ac16e6b2ea realtek: set PoE power budget for ZyXEL GS1900-10HP
As per the manufacturer's specifications, set the GS1900-10HP PoE power
budget to 77W.

Signed-off-by: Stijn Segers <foss@volatilesystems.org>
2021-01-07 19:51:50 +01:00
Birger Koblitz
89f71ebb35 realtek: fix build issues
This fixes the build problems for the REALTEK target by adding a proper
configuration option for the phy module.

Signed-off-by: Birger Koblitz <mail@birger-koblitz.de>
2021-01-05 22:43:40 +01:00
Sander Vanheule
f4b687d1f0 realtek: use kernel defined halt
If _machine_hang is not defined on MIPS, the kernel will check if the
CPU can enter a more power efficient sleep mode. Since the realtek
platform supports mips32_r2, this should issue a WAIT instruction
instead of a trivial infinite loop.

Signed-off-by: Sander Vanheule <sander@svanheule.net>
2020-12-22 19:11:50 +01:00
Rafał Mikrut
561bfc96f9 realtek: Add missing case in switch statement
Cppcheck shows here duplicated break.

Code `state->speed = SPEED_1000;` will be never executed because above
it there is break statement.

Almost identical statement is placed in another realtek driver
18a53d43d6/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/dsa.c (L286-L294)

Signed-off-by: Rafał Mikrut <mikrutrafal@protonmail.com>
2020-12-11 13:48:24 +01:00
Rafał Mikrut
848d668427 realtek: Fix self assignment
Cppcheck shows self initialization error, which is an obvious bug.

Basing on logic of similar fragment below I assigned to this variable,
value `RTL838X_LED_GLB_CTRL` which I think is proper.

Signed-off-by: Rafał Mikrut <mikrutrafal@protonmail.com>
2020-12-11 13:48:24 +01:00
John Audia
3f165fa7cc kernel: bump 5.4 to 5.4.82
Removed since included upstream and could be reverse-applied by quilt:
  backport-5.4/315-v5.10-usbnet-ipeth-fix-connectivity-with-ios-14.patch

Remaining modifications made by update_kernel.sh

Build system: x86_64
Build-tested: ipq806x/R7800, ath79/generic, bcm27xx/bcm2711
Run-tested: ipq806x/R7800

No dmesg regressions, everything functional

Signed-off-by: John Audia <graysky@archlinux.us>
Tested-by: Curtis Deptuck <curtdept@me.com> [build/run x86_64]
2020-12-09 17:05:40 +01:00
John Crispin
9aabd934a9 realtek: fix SFP ports on the dlink 10port switch
Signed-off-by: John Crispin <john@phrozen.org>
2020-12-02 10:43:45 +01:00
John Crispin
cfbda66279 realtek: add zyxel_gs1900-10hp support
Signed-off-by: John Crispin <john@phrozen.org>
2020-12-02 07:54:14 +01:00
John Crispin
1dc5d56ca0 realtek: cleanup package selection
Signed-off-by: John Crispin <john@phrozen.org>
2020-12-02 07:53:52 +01:00
John Crispin
9aa4490502 realtek: clean up board.json generation
In this new setup the switch is treated as wan, lan1.100 is used as
our mgmt vlan.

The board mac is applied to eth0, switch and switch.1

The board mac is assigned with the LA bit set to all lan ports while
incrementing it.

Signed-off-by: John Crispin <john@phrozen.org>
2020-12-02 07:53:21 +01:00
Kevin Darbyshire-Bryant
4420ddaa58 kernel: clean up patch fuzz
Recent kernel bumps & target patch refactors have left some patch fuzz
around.  Refreshed kernel patches using update_kernel script.

Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
2020-11-26 17:32:43 +00:00
John Crispin
2b88563ee5 realtek: update the tree to the latest refactored version
* rename the target to realtek
* add refactored DSA driver
* add latest gpio driver
* lots of arch cleanups
* new irq driver
* additional boards

Signed-off-by: Bert Vermeulen <bert@biot.com>
Signed-off-by: Birger Koblitz <mail@birger-koblitz.de>
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: John Crispin <john@phrozen.org>
2020-11-26 13:29:27 +01:00