[PATCH 3/3] realtek: add support for Panasonic Switch-M8eG PN28080K
INAGAKI Hiroshi
musashino.open at gmail.com
Sat Nov 13 21:32:00 PST 2021
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>;
>> + };
>> + };
>> +
>> + 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
>
>
>> +
>> + /* 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
>
>> + reg = <0x75>;
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> +
>> + /*
>> + * GPIO14 (IO1_6): Shift Register RESET (port LED)
>> + * - Switch-M8eG PN28080K: 3x 74HC164
>> + * - Switch-M24eG PN28240K: 6x 74HC164
>> + * - Switch-M48eG PN28480K: 12x 74HC164
>> + */
>> + portled_sregister_reset {
>> + gpio-hog;
>> + gpios = <14 GPIO_ACTIVE_HIGH>;
>> + output-high;
>> + line-name = "portled-sregister-reset";
>> + };
>> + };
>> + };
> [...]
>
>> +&spi0 {
>> + status = "okay";
>> +
>> + flash at 0 {
>> + compatible = "jedec,spi-nor";
>> + reg = <0>;
>> + spi-max-frequency = <10000000>;
>> +
>> + partitions {
>> + compatible = "fixed-partitions";
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> +
>> + partition at 0 {
>> + label = "u-boot";
>> + reg = <0x0 0x80000>;
>> + read-only;
>> + };
>> +
>> + partition at 80000 {
>> + label = "u-boot-env";
>> + reg = <0x80000 0x10000>;
>> + };
>> +
>> + partition at 90000 {
>> + label = "u-boot-env2";
>> + reg = <0x90000 0x10000>;
>> + };
>> +
>> + partition at a0000 {
>> + label = "sysinfo";
>> + reg = <0xa0000 0x60000>;
>> + read-only;
>> + };
>> +
>> + /*
>> + * 0x100000 - 0x1DFFFFF
>> + * Filesystem area for runtime images and
>> + * configuration files in stock firmware
>> + */
>> +
>> + /*
>> + * re-created filesystem area, 2x stock images
>> + * are included with checksum files
>> + */
> Can you merge both comments? Now it first seemed to me that you were describing a missing
> area first, followed by some partitions.
Indeed, I'll update the comments in v2 patch.
>
>> + partition at 100000 {
>> + label = "fs_reserved";
>> + reg = <0x100000 0xd00000>;
>> + };
>> +
>> + /* free area for OpenWrt */
> You can drop this comments as far as I'm concerned. The label and compatible should be
> enough for an OpenWrt developer to recognise it for what it is.
OK, I'll do.
>
>> + partition at e00000 {
>> + compatible = "denx,uimage";
>> + label = "firmware";
>> + reg = <0xe00000 0x1000000>;
>> + };
> Best,
> Sander
Regards,
Hiroshi
More information about the openwrt-devel
mailing list