[PATCH 3/3] realtek: add support for Panasonic Switch-M8eG PN28080K

Sander Vanheule sander at svanheule.net
Sun Nov 14 00:52:32 PST 2021


Hi Hiroshi,

On Sun, 2021-11-14 at 14:32 +0900, INAGAKI Hiroshi wrote:
> Hi Sander,
> 
> Thank you for your review.
> 
> On 2021/11/13 7:46, Sander Vanheule wrote:
> > Hi Hiroshi,
> > 
> > On Sun, 2021-10-03 at 15:53 +0900, INAGAKI Hiroshi wrote:
> > > Panasonic M8eG PN28080K is a 8 + 1 port gigabit switch, based on
> > > RTL8380M.
> > > 
> > > Specification:
> > > 
> > > - SoC           : Realtek RTL8380M
> > > - RAM           : DDR3 128 MiB (Winbond W631GG8KB-15)
> > > - Flash         : SPI-NOR 32 MiB (Macronix MX25L25635FMI-10G)
> > > - Ethernet      : 10/100/1000 Mbps x8 + 1
> > >    - port 1-8    : TP, RTL8218B (SoC)
> > >    - port 9      : SFP, RTL8380M (SoC)
> > > - LEDs/Keys     : 7x / 1x
> > > - UART          : RS-232 port on the front panel (connector: RJ-45)
> > >    - 3:TX, 4:GND, 5:GND, 6:RX (pin number: RJ-45)
> > >    - 9600n8
> > > - Power         : 100-240 VAC, 50/60 Hz, 0.5 A
> > >    - Plug        : IEC 60320-C13
> > > - Stock OS      : VxWorks based
> > > 
> > > Flash instruction using initramfs image:
> > Looks quite convoluted. Kudos on working this out!
> Thank you!
> 
> > > 1.  Prepare the TFTP server with the IP address 192.168.1.111
> > > 2.  Rename the OpenWrt initramfs image to "0101A8C0.img" and place it to
> > >      the TFTP directory
> > > 3.  Download the official upgrading firmware (ex: pn28080k_v30000.rom)
> > >      and place it to the TFTP directory
> > > 4.  Boot M8eG and interrupt the U-Boot with Ctrl + C keys
> > > 5.  Execute the following commands and boot with the OpenWrt initramfs
> > >      image
> > > 
> > >      rtk network on
> > >      tftpboot 0x81000000
> > >      bootm
> > > 
> > > 6.  Backup mtdblock files to the computer by scp or anything and reboot
> > > 7.  Interrupt the U-Boot and execute the following commands to re-create
> > >      filesystem in the flash
> > > 
> > >      ffsmount c:/
> > >      ffsfmt c:/
> > > 
> > >      this step takes a long time, about ~ 4 mins
> > > 
> > > 8.  Execute the following commands to put the official images to the
> > >      filesystem
> > > 
> > >      updatert <official image>
> > > 
> > >      example:
> > > 
> > >        updatert pn28080k_v30000.rom
> > > 
> > >      this step takes about ~ 40 secs
> > > 
> > > 9.  Set the environment variables of the U-Boot by the following commands
> > > 
> > >      setenv loadaddr 0xb4e00000
> > >      setenv bootcmd bootm
> > >      saveenv
> > > 
> > > 10: Download the OpenWrt initramfs image and boot with it
> > > 
> > >      tftpboot 0x81000000 0101A8C0.img
> > >      bootm
> > > 
> > > 11: On the initramfs image, download the sysupgrade image and perform
> > >      sysupgrade with it
> > > 
> > >      sysupgrade <imagename>
> > > 
> > > 12: Wait ~ 120 seconds to complete flashing
> > > 
> > > Note:
> > > 
> > > - "Switch-M8eG" is a model name, and "PN28080K" is a model number.
> > >    Switch-M8eG has an another (old) model number ("PN28080"), it's not a
> > >    Realtek based hardware.
> > > 
> > > - Switch-M8eG has a "POWER" LED (Green), but it's not connected to any
> > >    GPIO pin.
> > > 
> > > - The U-Boot checks the runtime images in the flash when booting and
> > >    fails to execute anything in "bootcmd" variable if the images are not
> > >    exsisting.
> > > 
> > > - A filesystem is formed in the flash (0x100000-0x1DFFFFF) on the stock
> > >    firmware and it includes the stock images, configuration files and
> > >    checksum files. It's unknown format, can't be managed on the OpenWrt.
> > >    To get the enough space for OpenWrt, move the filesystem to the head
> > >    of "fs_reserved" partition by execution of "ffsfmt" and "updatert".
> > > 
> > > Back to the stock firmware:
> > > 
> > > 1. Delete "loadaddr" variable and set "bootcmd" to the original value
> > > 
> > >     on U-Boot:
> > > 
> > >       setenv loadaddr
> > >       setenv bootcmd 'bootm 0x81000000'
> > > 
> > >     on OpenWrt:
> > > 
> > >       fw_setenv loadaddr
> > >       fw_setenv bootcmd 'bootm 0x81000000'
> > > 
> > > 2. Perform reset or reboot
> > > 
> > >    on U-Boot:
> > > 
> > >      reset
> > > 
> > >    on OpenWrt:
> > > 
> > >      reboot
> > > 
> > > Signed-off-by: INAGAKI Hiroshi <musashino.open at gmail.com>
> > > ---
> > [...]
> > 
> > > diff --git a/target/linux/realtek/dts-5.10/rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi
> > > b/target/linux/realtek/dts-5.10/rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi
> > > new file mode 100644
> > > index 0000000000..d41213f1fd
> > > --- /dev/null
> > > +++ b/target/linux/realtek/dts-5.10/rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi
> > > @@ -0,0 +1,216 @@
> > > +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> > > +
> > > +#include <dt-bindings/input/input.h>
> > > +#include <dt-bindings/gpio/gpio.h>
> > > +
> > > +/ {
> > > +       chosen {
> > > +               bootargs = "console=ttyS0,9600";
> > > +       };
> > > +
> > > +       memory at 0 {
> > > +               device_type = "memory";
> > > +               reg = <0x0 0x8000000>;
> > > +       };
> > > +
> > > +       leds: leds {
> > > +               compatible = "gpio-leds";
> > > +
> > > +               any_collision {
> > > +                       label = "amber:any_col";
> > Should we start using 'function' and 'color' on 5.10 instead of (or in addition to)
> > 'label'? The functions are non-standard, but the #DEFINE-s in led-common.h are only
> > strings anyway.
> As you said in your additional email, the replacement breaks led-* 
> aliases.
> I think it's possible to add "color"/"function" properties as a 
> preparation without replacement.
> 
> > Speaking of following the dt-bindings... I'm aware that you've already discussed the
> > node
> > names with Adrian, but leds-gpio.yaml currently specifies that child node names shall
> > match "(^led-[0-9a-f]$|led)". Adrian, what do you think about following the spec?
> > 
> > > +                       gpios = <&gpio2 0 GPIO_ACTIVE_LOW>;
> > > +               };
> > > +
> > > +               giga {
> > > +                       label = "green:giga";
> > > +                       gpios = <&gpio2 8 GPIO_ACTIVE_LOW>;
> > > +               };
> > > +
> > > +               100m {
> > > +                       label = "green:100m";
> > > +                       gpios = <&gpio2 9 GPIO_ACTIVE_LOW>;
> > > +               };
> > > +
> > > +               full_duplex {
> > > +                       label = "green:full";
> > > +                       gpios = <&gpio2 10 GPIO_ACTIVE_LOW>;
> > > +               };
> > > +
> > > +               loop_history {
> > > +                       label = "green:loop_history";
> > > +                       gpios = <&gpio2 11 GPIO_ACTIVE_LOW>;
> > > +               };
> > > +       };
> > > +
> > > +       keys {
> > > +               compatible = "gpio-keys-polled";
> > > +               poll-interval = <20>;
> > > +
> > > +               led_mode {
> > > +                       label = "led-mode";
> > > +                       gpios = <&gpio2 15 GPIO_ACTIVE_LOW>;
> > > +                       linux,code = <BTN_0>;

Not all LED-buttons do this, but you could use KEY_LIGHTS_TOGGLE instead of BTN_0. I don't
know what the maintainers' preferences are for this though, but at least KEY_LIGHT_TOGGLE
is used exclusively for LED toggle buttons. BTN_0 is used for all sorts of things, so (or
since) it doesn't have a clear meaning.

> > > +               };
> > > +       };
> > > +
> > > +       gpio-restart {
> > > +               compatible = "gpio-restart";
> > > +               gpios = <&gpio2 3 GPIO_ACTIVE_HIGH>;
> > > +               active-delay = <100>;
> > > +               inactive-delay = <100>;
> > > +               wait-delay = <3000>;
> > > +       };
> > As noted in my other mail, this currently only has the effect of grabbing the GPIO pin.
> > Once _machine_restart is removed, you may have to increase the priority beyond the
> > default
> > of 128, otherwise it's not guaranteed this reboot method will be used.
> I see, I'll keep in mind.
> BTW, the driver seems to use "129" as priority by default[1].
> 
> [1]: 
> https://elixir.bootlin.com/linux/v5.10.78/source/drivers/power/reset/gpio-restart.c#L75

Then the documentation in Documentation/devicetree/bindings/power/reset/gpio-restart.txt
is wrong! That states 128 as the default value. If it's 129 by default, that's OK for me.

The -delay properties also don't appear to be required, looking at the driver source.
Since you're using the default values, I think you can drop them.


> > 
> > 
> > > +
> > > +       /* Switch-M*eG PN28xx0K has no RTL8231 chip */
> > > +       /delete-node/ rtl8231-gpio;
> > > +
> > > +       i2c_gpio_0: i2c-gpio-0 {
> > > +               compatible = "i2c-gpio";
> > > +               i2c-gpio,delay-us = <2>;
> > > +               #address-cells = <1>;
> > > +               #size-cells = <0>;
> > > +
> > > +               gpio1: gpio at 20 {
> > > +                       compatible = "nxp,pca9555";
> > > +                       reg = <0x20>;
> > > +                       gpio-controller;
> > > +                       #gpio-cells = <2>;
> > > +               };
> > > +
> > > +               gpio2: gpio at 75 {
> > > +                       compatible = "nxp,pca9539";
> > The #INT pin of this chip doens't happen to be wired up? If it is, I would expect you
> > could cascade the interrupts through &gpio0.
> Until now, I didn't know the pin number. When I checked it again, I 
> found it (and PCA9545's one), I'll add it in v2 patch[2].
> 
> 
> [2]: 
> https://github.com/musashino-build/openwrt/commit/597ce282a2633ae70a95972a775e770f2dc9f237

Good to hear they connected the interrups, even though Realtek's SDK doesn't implement
GPIO interrupts for RTL83xx.

Best,
Sander




More information about the openwrt-devel mailing list