[FS#986] ARV752DPW missing default switch config

[LEDE Bugs]

The following task has a new comment added:

FS#986 - ARV752DPW missing default switch config
User who did this - Mathias Kresin (mkresin)

----------
> So when OpenWRT was started by a broken bootloader, OpenWRT had no network connectivity.

This ticket isn't really the right place for tracking this issue but anyway.

I gave the ARV752DPW u-boot from the OpenWrt wiki a try on my ARV7506PW11 and it works. I was able to use tftp as well as the http recovery interface.

But I can confirm that there is an issue with u-boot and the switch chip. I managed to get the switch into a state where it can not be found by u-boot (and later on not by LEDE) two times. Unfortunately I'm not able to trigger/reproduce the bug.

The rtl8306 switch chip has a pin to hold the chip in reset. For the ARV7506PW11 and most likely for the ARV752DPW as well the pin is connected to GPIO 19 of the danube SoC. During boot, u-boot toogles the pin to reset the switch (vlan) config:


searching for rtl8306 switch ... found
Reset Hard
Done


If the rtl8306 can not be found by u-boot the (hard) reset isn't done any more.


Net:
searching for rtl8306 switch ... failed


As soon as I set the direction of the GPIO connected to the reset pin to "out", the switch comes back to live:


root at LEDE:/# echo 499 > /sys/class/gpio/export
root at LEDE:/# echo out > /sys/class/gpio/gpio499/direction
root at LEDE:/# [  193.245095] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[  193.253203] br-lan: port 1(eth0.1) entered forwarding state
[  193.257427] br-lan: port 1(eth0.1) entered forwarding state
[  193.266290] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
[  195.260755] br-lan: port 1(eth0.1) entered forwarding state


I've no idea why it fails nor why the direction change brings the switch back to live (GPIO value of 1 usually releases the reset on my board).

Judging based on the output, the hard reset limbo is only done if the switch can be found/identified. It could be some kind of interaction with the LEDE driver where an important register has a bad value and locks the chips. It might be that the reset limbo fails (due to a race condition/missing wait) and the rtl8306 chip stucks in reset. Albeit, for the later case I would expect that forcing the switch into reset from LEDE would trigger the bug as well, which it doesn't.

Nevertheless we should take care of this issue. As long as I'm not able to reproduce/trigger the issue I can not be really helpful.

One way to fix the switch state could be to add a device tree binding for the rtl8306 with a gpio-reset property. The GPIO referenced by the gpio-reset property can be pull during early driver load to release a possible reset. The same property can be used to issue an hard reset on driver load instead of resetting the vlan config only.

Maybe you are able to trigger the bug reliable and check the gpio registers and so on, to get a clue what is real issue here.
----------

More information can be found at the following URL:
https://bugs.lede-project.org/index.php?do=details&task_id=986#comment3377