Yeah, that's what it looked like in your initial speed test. I assume it could be a bad cable. Why was it not reflected in the link speed reported by ethtool?
The flow control output should be a lot longer than just the one line. Anyway, pause frames are on by default causing the extreme latency results you saw.
1 Like
100 Mbps negotiated was my first thought as well, but yeah, weirdly enough ethtool didn't show it.
Sounds like you already found the culprit was outside the switch, but yes, I use out of the box settings except for the configuration as I described it.
Admittedly I am new to ethtool and do not know why 1000Mb/s was shown instead of 100Mb/s. Does ethtool -d show the speed capability of the devices connected to the switch rather than reporting the actual speed of the connection?
Thanks again all who have been assisting with troubleshooting. I've been learning some interesting things along the way too.
In ethtool -d does not show the speed (ethtool [ FLAGS ] -d|--register-dump DEVNAME Do a register dump). I've used -d with tr command in order to remove newline characters from the output, hence, making the output a table instead of a list.
for i in $(seq 1 8); do echo -n lan$i; ethtool lan$i|grep 'Link detected'|tr -d '\n'; ethtool lan$i|grep 'Speed'; done
The value shown next to Speed is the current link speed, at least it should be.
1 Like
Hi community,
can someone help me with creating a custom firmware (customized DTS) for a Zyxel GS-1900-8HPv1 ?
Over here, in another thread svanheule suggested "disabling gpio1 in the DTS should leave the GPIO chip alone. Maybe that's a good thing to test first".
I refer to the git issue https://github.com/openwrt/openwrt/issues/9534, my switch immediately resets after the following line once it's booted from OpenWrt.
[ 0.798769] rtl8231_init called, MDIO bus ID: 0
Here is the verification of the MDIO bus ID as requested in the issue:
RTL838x# md.l 0xbb00a09c
bb00a09c: 0000000c 00019000 0003e800 0007d000 ................
bb00a0ac: 00000000 00000000 00000000 00000000 ................
bb00a0bc: 00000000 00000000 00000000 00000000 ................
bb00a0cc: 00000000 00000000 00000000 00000000 ................
bb00a0dc: 00699041 00000180 00000000 00000000 .i.A............
bb00a0ec: 00000000 00000000 00000000 00000000 ................
bb00a0fc: 00000000 000480a8 00d71eec 00d71eec ................
bb00a10c: 00d71eec 00d71eec 00d71eec 00d71eec ................
bb00a11c: 00d71eec 00d71eec 00d71eec 00d71eec ................
bb00a12c: 00d71eec 00d71eec 00d71eec 00d71eec ................
bb00a13c: 00d71eec 00d71eec 00d71eec 00d71eec ................
bb00a14c: 00d71eec 00d71eec 00d71eec 00d71eec ................
bb00a15c: 00d71eec 00d71eec 00d71eec 00d71eec ................
bb00a16c: 00d71eec 00d71eec 00d71eec 00ffffff ................
bb00a17c: 0000ff00 00000000 00000000 00000000 ................
bb00a18c: 05000000 00000000 00220000 00000000 ........."......
RTL838x# rtk network on
Enable network
Force port28 link up 1G
Please wait for PHY init-time ...
RTL838x# md.l 0xbb00a09c
bb00a09c: 0000000c 00019000 0003e800 0007d000 ................
bb00a0ac: 00000000 00000000 00000000 00000000 ................
bb00a0bc: 00000000 00000000 00000000 00000000 ................
bb00a0cc: 00000000 00000000 00000000 00000000 ................
bb00a0dc: 00699041 00000180 00000000 00000000 .i.A............
bb00a0ec: 00000000 00000000 00000000 00000000 ................
bb00a0fc: 00000000 000480a8 00d71eec 00d71eec ................
bb00a10c: 00d71eec 00d71eec 00d71eec 00d71eec ................
bb00a11c: 00d71eec 00d71eec 00d71eec 00d71eec ................
bb00a12c: 00d71eec 00d71eec 00d71eec 00d71eec ................
bb00a13c: 00d71eec 00d71eec 00d71eec 00d71eec ................
bb00a14c: 00d71eec 00d71eec 00d71eec 00d71eec ................
bb00a15c: 00d71eec 00d71eec 00d71eec 00d71eec ................
bb00a16c: 00d71eec 00d71eec 0006192f 00ffffff .........../....
bb00a17c: 0000ff00 00000000 00000000 00000000 ................
bb00a18c: 05000000 00000000 00220000 00000000 ........."......
Here is the bootloader output, as requested in the issue:
U-Boot 2011.12.39239-svn41394 (Jul 24 2013 - 09:34:28)
Board: RTL838x CPU:500MHz LXB:200MHz MEM:300MHz
DRAM: 128 MB
SPI-F: 1x16 MB
Loading 1024B env. variables from offset 0x40000
Switch Model: ZyXEL_GS1900_8HP (Port Count: 8)
Switch Chip: RTL8382M
How can it be that different Gs1900-8HPv1 behave so differently? What is different about them ? The U-boot loader ? I also have an SPI flasher at hand.
Many thanks,
Christian
I reckon disabling this line in the DTS, then compile an image:
Every hardware nodes in the dts files for referring to the gpio1 module must also be comment marked or deleted or a fatal build error will occur if the definition is missing.
But removing the gpio chip is like blowing up the problem with a big bang!?
And most other things (pretty much everything) will stop working in some way.
1 Like
reset {
label = "reset";
gpios = <&gpio1 3 GPIO_ACTIVE_LOW>;
linux,code = <KEY_RESTART>;
};
};
If it automatically resets when initializing the gpio1, start by changing gpio_active_low to gpio_active_high and check that the reset is actually still connected to that pin.
Or build a file without the reset function to see if it stop reseting at initialization. If it stop then there is highly probable wrong pin number or active low or high that is wrong.
1 Like
Thanks, I must say I never built an image by myself. Will try now by going through the docs and report back later 
This specific gpio chip is used on pretty much every switch device we have in this project and it doesn’t change hardware input or output status anywhere else just by initialization.
But if the active high/low is wrong it will see an false active input at initialization and start a reset.
The other thing if the actual pin number has changed over time or is wrong from the beginning it could actually be a communication line pin or something else and then it will wreck havoc when the data flow enters the reset pin.
linux,code = <KEY_RESTART>;
Comment out this line would leave the reset pin hardware definition but it will neutralize the actual function in linux that start the reset process. Meaning if you push the button the system see it but nothing should actually happen, this would be true also for the boot initialization.
I would at least start there to verify the actual dts content because dts files only defines the hardware mounted on the PCB, it really doesn’t do anything with the hardware.
The rest of the work is done in software and drivers.
Are you using a master release build or 21.02 or 22.03?
1 Like
I would at least start there to verify the actual dts content
How can I do this via u-boot commands ?
Are you using a master release build or 21.02 or 22.03?
Tried different ones from 21.02 on till 22.03. All the same behaviour.
Where do I get a pre-built master release build if not from releases( https://downloads.openwrt.org/releases/) or snapshots (https://downloads.openwrt.org/snapshots/targets/) ?
You will need to dig in to the developer guide (specifically the adding hardware support parts and probing input and output) in the user manual section on the homepage and learn how to build the image by your self.
I would recommend doing this with master images so the latest bug fixes in software and drivers are included.
And learn how to load the initramfs image to do the test installations without using up the flash memory.
But this job with dts files is pretty much a detective work. Change one line at a time in the dts and build it, run it and observe the changes.
If you neutralize the complete gpio1 in one go and “something changes”, well that chip is so central in the hardware buildup that a lot of things will change but then what?
This fault is so small that the solution lies in the details around the reset function.
If you connect by serial and watch the boot process, does it say reboot after the gpio1 initialization when it reboots?
does it say
rebootafter the gpio1 initialization when it reboots?
no, it's a unwanted reset, it just reboots
And learn how to load the initramfs image to do the test installations without using up the flash memory.
yep, I don't even want to flash the images for this. Just load it via tftp and directly boot
Hmm, I wonder if this device dts is missing the gpio-reset block some devices have that send out a reset signal from the gpio1 when doing a software reset. And if that pin is not pre-defined to the right potential it could start a reset when initialization occurs🤔
This reset output would trigger all the reset pins on all hardware chip and that wouldn’t leave any reset trace in the log.
If the reset button had been pushed fast it should have printed reboot and rebooted. The alternative is a long push to activate the real software reset.
If this is the case a build without the gpio1 that makes the problem go away would be a proof of concept but then we need to find the reset output pin.
Is it momentarily right away at initialization or after a couple of seconds?
Is it momentarily right away at initialization or after a couple of seconds?
it resets immediately, there is not even half a second till the bootloader starts again
[ 0.850000] Probing RTL8231 GPIOs
[ 0.860000] rtl8231_init called, MDIO bus ID: 0
^@^@II: Copied Preloader data from 0x9fc00000(15356B) to 0x9f000000.
II: Cleared Preloader BSS section at 0x9f003bfc(0B).
I doubt it is triggered by a false reset key push then because a quick push gives a reboot message once the key is released after a quick push.
Alternative a long push gives a software reset but then you need to have the key input for many seconds.
So I belive at this point we are missing this general reset function
gpio-restart {
compatible = "gpio-restart";
gpios = <&gpio1 34 GPIO_ACTIVE_LOW>;
open-source;
for this device dts, the question is probably more what pin the connection is on this device. Because this is the only function on this gpio chip we have found in these switch project that can reset the system without a warning and without a delay.
Or this is a bug in the software somewhere else.