Support for RTL838x based managed switches

The function to initialize I2C on the RTL83xx is

int32 drv_software_i2c_init(uint32 devSCK, uint32 pinSCK, uint32 devSDA, uint32 pinSDA, uint32 dev);

devSCK and devSDA are GPIO device IDs. They can be either the GPIOs of the SoC itself, or of any of a number of RTL8231 GPIO expanders. But in principle the API is so abstracted that it could also be the GPIOs of an RTL8231 expander chip connected to a secondary SoC slaved via SPI to the primary SoC.
Some of this functionality (anything that does not involve a secondary SoC) is available through using the right &gpio reference. This can be &gpio0, which is the SoC itself, or &gpio1, which should be the RTL8231 expander chip.

Hi, i am trying to install openwrt to new LY-RTL8380M 8 ports copper +2 ports sfp board .
it has w25q128fvfg 16 pin 16MB spi flash and 128MB RAM

at the u-boot stage i pressed ctrl + q but no luck it didn't worked
Press ctrl+q to stop autoboot: 1
seems like they disabled keyboard prompts

Could you help me at this point @anon13997276

U-Boot 2011.12.41872 (Jul 09 2014 - 14:33:31)

CPU:500MHz LXB:200MHz MEM:300MHz
DRAM:  128 MB
SPI-F: 1oading 65536B env. variables from offset 0x80Net:   Net Initialization d

Press ctrl+q to stop autoboot:  0 
## Booting image from partition ... 0
## Booting kernel from Legacy Image at b42a0000 ...
   Image Name:   3.0.1
   Created:      2014-12-22  11:09:15 UTC
 ype:   MIPS Linux Kernel Image (gzip compressed)
   Data Size:    5385257 Bytes = 5.1 MB
   Load Address: 80000000                                                       
   Entry Point:  8026b000                                                       
   Verifying Checksum ... OK                                                    
   Uncompressing Kernel Image ..
Starting kernel ...

Linux version 2.6.19 (root@localhost.localdomain) (gcc version 3.4.4 mipssde-6.03.00-20051020) #27 PREEMPT Mon Dec 22 11:09:10 CST 2014
CPU revision is: 00019070
Determined physical RAM map:
 memory: 04000000 @ 00000000 (ued physical RAM map:
 memory: 04000000 @ 00000000 (usable)
Built 1 zonelists.  Total pages: 16256
Kernel command line: console=ttyS0em=64M
Primary instruction cache 16kB, physically tagy, linesize 16 bytes.
Primary data cache 16kB, 2-way, linesize 16 bytes.
Synthesized TLB refill handler (20  handler fastpath (32 instructions).
Synthesized TLB store handler fastpath (32 instructions).
Synthesized TLB modify handler fastpath (31 instructions).
PID hasntries: 256 (order: 8, 1024 bytes)
Dentry ca2 (order: 3, 327682, 16384 bytes)
Memory: 58008k/6553ble (2056k kernel code, 7464k reserved, 415k data, 4344k init, Mount-cache hash table entries: 512
Checking for 'wait' instruction...  available.
NET: Registered protocol family 16
NET: Registered protocol family 2
IP route cache hash table entries: 512 (order: -1, 2048 bytes)
TCP established hash table entries: 2048 (order: 1, 8192 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tabtablished 2048 bind 1024)
TCP reno registered
squashfs:3.3 (2007/10/31) Phillip Lougher
squashfs: LZMA suppplax.org by jro
JFFS2 version 2.2. (NAND) (C) 2001-2006 Red Hat, Inc.
io scheduler noop registered
io schy registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 ports, IRQ sharing disabled
serial8250: ttyO 0x0 (irq = 31) is a 16550A
loop: loaded (max 8 devicesCreating 7 MTD partitions on "Total SPI FLASH":
0x00000000-0x00080000 : "LOADER"000-0x00090000 : "BDINFO"
0x00090000-0x000a0000 : "SYSINFO"
0x000a000000 : "JF00-0x002a0000 : "JFFS2 LOG"
0x002a0000-0x009RUNTIME"
0x00950000-0x0100UNTIME2"
TCP cubic registered
NET: Registered protocol family 1
NET: Registerel family 10
IPv6 over IPv4 tunneling driver
Press any key to continue
**unregister the packet Phandle

>> CAN'T GO FURTHER

İ have solved the problem with hex editing spi flash dump and stopped boot then wrote https://downloads.openwrt.org/releases/21.02.2/targets/realtek/generic/openwrt-21.02.2-realtek-generic-d-link_dgs-1210-10p-initramfs-kernel.bin image to ram and it works well.
But when i install on spi flash it gives me error like this:

RTL838x# # bootm
## Booting kernel from Legacy Image at b4100000 ...
   Image Name:   MIPS OpenWrt Linux-5.4.179
   Created:      2022-02-16  20:29:10 UTC
   Image Type:   MIPS Linux Kernel Image (gzip compressed)
   Data Size:    2820328 Bytes = 2.7 MB
   Load Address: 80000000
   Entry Point:  80000400
   Verifying Checksum ... Bad Data CRC
ERROR: can't get kernel image!

any help would be appreciated ...

here is SPI Flash partition table

root@OpenWrt:/# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00080000 00010000 "u-boot"
mtd1: 00040000 00010000 "u-boot-env"
mtd2: 00040000 00010000 "u-boot-env2"
mtd3: 00d80000 00010000 "firmware"
mtd4: 00180000 00010000 "kernel2"
mtd5: 00000000 00010000 "sysinfo"
mtd6: 00000000 00010000 "rootfs2"
mtd7: 00000000 00010000 "jffs2"

This sounds as if the checksum in the header of the image for the actual image data is not what u-boot on your device expects. It could be that a different algorithm is used or that a seed is used with the normal crc algorithm. The first thing you should do is compare the header of the original image or a firmware update image with the one produced by you in openwrt. You can use the mkimage tool to check the checksums. The u-boot sources under tools contain the header description.
You will probably then need to analyzer how the u- boot on you router calculates the checksum. Load the flash image of u-boot into ghidra load address is b4000000 which is the same as 84000000. Find the reference in the code to the error string. Figure out how the algorithm works or at least disable the checksum check. @obi is a magician with ghidra, maybe he can help.

1 Like

Hi , I want to use port mac binding, but I do not know configure which registers or tables. Anybody could give me a hint, thanks a lot!

Many thanks @anon13997276 i have solved

Blockquote
Verifying Checksum ... Bad Data CRC
ERROR: can't get kernel image!

problem another way and i will explain today when i'm available.
have a nice day

[SOLUTION]

First i recognized that "ERROR: can't get kernel image!" problem caused by sysupgrade process on ramfs.

After long time u-boot inspection i have found "update_linux" env varriable from u-boot environments

update_linux=tftp $(freemem) $(file_linux);sf probe 0;sf erase $(flashoffset_linux) $(ssize_linux);sf write $(fileaddr) $(flashoffset_linux) $(ssize_linux)

this gave me a way to i can boot "openwrt sysupgrade.bin" with help of

RTL838x# # run update_linux command

then it worked well

Using rtl8380#0 device
TFTP from server 192.168.1.111; our IP address is 192.168.1.1
Filename 'vmlinux.bix'.
Load address: 0x81000000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         ###########################################################
done
Bytes transferred = 5634312 (55f908 hex)
II: Erasing 7012352 bytes from 002a0000... 100%
II: Writting 7012352 bytes to 002a0000... 100%
RTL838x# #

Thanks for your interest and work on RTL838x @anon13997276

1 Like

tnx...

i did some further analysis and tries,

I believe I found the 3 I2C Devices (all on gpio1)
sda/scl pins:
1/2
22/23
11/12

when running

i2cdetect -y BUS

on the first 3, no addresses are found, and the iteration concludes within < 2 seconds

Now i tried (learned from various sources) further settings to identify the I2C where the LM63 is attached to.

I tried

sda/scl pins:
32/31
31/32
31/30
30/31

whatever i try,
when running i2cdetect on the 4th bus, also no addresses are found, but the iteration takes about 1,5 minutes.

I wonder, if this of any help?

Hi Alfa, i have a similar switch (dgs-1210-24p)... i assume you run the switch 24/7? did you ever encounter any heat problems? i assume the cooling fans are also off?

mine are all-time off when booted by openwrt, and i try to get them running because i have the concern that the swithc eventually will overheat

Well, thats the issue I also have.
You can use a multimer or logic analyzer and you will see that one of the I2C pins on the LM63 package itself is floating, like its missing a pull-up.

But if you just use it as a GPIO then it can be toggled just fine.

have you tried to modify the DTS to also set GPIO_PULL_UP for that pin?

btw: what is the fastest way to apply an updated DTS (or DTB) to the kernel?

i am rebuilding and reflashing the whole image, but wonder if there is a faster way?

Hi, i have used dgs-1210-28p F2 revision (realtek ic) for a long time with all ports default vlan conf.
It has passive cooling.There were no cooler fan on it and it has normal heat during switching process.
Did you try to enable fan controller if there is a way..

I dont think those GPIO-s on RTL8231 have an internal Pull-up.
You can just edit the DTS directly in the build_dir

tnx.. this is clear, but how do i get the resulting dtb onto the board?

at the moment i do

  • fiddle with DTS
  • make -j15 world
  • flash resulting sysupgrade-image

The same way, but this way only the changes get rebuilt

With this dts entry

        i2c6: i2c-gpio-6 {
                compatible = "i2c-gpio";
                sda-gpios = <&gpio1 32 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN )>;
                scl-gpios = <&gpio1 31 (GPIO_ACTIVE_HIGH)>;
                i2c-gpio,scl-output-only;
                i2c-gpio,scl-open-drain;
                i2c-gpio,delay-us = <2>;
                #address-cells = <1>;
                #size-cells = <0>;
        };

i get fast response on i2cdetect, but unfortunatley it showing every address on the bus, reading any value through i2cget returns "0x0"

so most likely no proceeding :frowning:

Cause, it cannot fix the issue of the pin floating

You mean that is a system design issue? Or how would the stock firmware go about it?

Looks like it, no idea what the stock FW does about it because the whole LM63 configuration is missing from GPL.
Even in the stock FW, it sometimes fails finding the LM63 and only after a reboot it will succeed configuring it for the fans to work

1 Like

The datasheet actually claims that there should be internal pull-ups available. At least on certain pins but dependent on resp. mode configured. Rather confusing really.

The pins that have internal pull-up/down resistors, are the bootstrapping pins. Basically to make sure the device will power on in a certain default state (MIIM/MDIO device with address 0x1f). These pull-ups do work, since I relied on them when testing my RTL8231 driver on a modified board (pull-down or floating address pin). 75kΩ is quite a weak pull-up though; any current draw over 17µA and you won't meet the high-level threshold anymore.