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

INAGAKI Hiroshi musashino.open at gmail.com
Sat Nov 20 07:18:07 PST 2021


Hi Sander,

On 2021/11/14 17:52, Sander Vanheule wrote:
> 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.

I'll add "color"/"function" properties in v2 patch[1].

[1]: 
https://github.com/musashino-build/openwrt/commit/f5f4667a51780d962f792ed5f02d9a68243c58e3

>>> 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?

I'll update the node names to "led-*" in v2 patch[2].

[2]: 
https://github.com/musashino-build/openwrt/commit/80690c1475bb0528932edcb6e52a9e238adf621b

>>>> +                       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.

IMO, KEY_LIGHTS_TOGGLE meanings toggling on/off of light and it's not 
suitable for this button to switch "modes" of port-side LEDs.
I found the code "KEY_MODE", but it's not supported by the 
gpio-button-hotplug driver and I want to keep "BTN_0".

>>>> +               };
>>>> +       };
>>>> +
>>>> +       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.

Okay, I'll drop the default values in v2 patch[3].

[3]: 
https://github.com/musashino-build/openwrt/commit/0969a17088cc0faed0c5f032d8b0d4d693b28b77

>
>>>
>>>> +
>>>> +       /* 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


I'll also update the comments of partitions in the dts in v2 patch[4].

[4]: 
https://github.com/musashino-build/openwrt/commit/474ce12ae2efc3fedf06a8dd9a283291cd1ae961

Regards,
Hiroshi




More information about the openwrt-devel mailing list