[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