[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