0 Overview
In the QSDK platform, the version I have contacted that can support the MIPS architecture is based on the Openwrt AA version; although the CC version can already support AR8035 well, the AA version itself does not support it, so people continue to A patch method is required, and the firmware development platform is generally unified, thereby reducing the workload of firmware maintenance.
After a brief look, if the at803x in the CC version is directly downgraded to adapt to the AA version, the workload of the modification is still relatively large, and I am afraid of trouble, so I can only find another way, after a lot of searching on Baidu/Google , found that Matus Ujhelyi's at803x is the easiest to implement, as long as the unused wol function is cut off, there are only a few lines of the remaining code; then check the existing ar80xx.c, it can successfully drive AR8033; moreover, From the driver's point of view, the difference between 8033 and 8035 is not big. Therefore, it is appropriate to combine ar80xx with at803x to form a new at803x with a minimum code amount to meet this requirement.
1 Specific implementation
First download a copy of Matus Ujhely's earliest at803x driver, you can directly go to Baidu to find "at803x.c"; then copy the existing ar80xx.c and ar80xx.h as at803x.c and at803x.h respectively; Copy at803x_enable_rx_delay and at803x_enable_tx_delay in at803x.c downloaded from the Internet to the new at803x.c, in ar803x_config_init of the new at803x.c, force enable "RGMII mode", at803x_enable_rx_delay and at803x_enable_tx_delay; in ar803x_read_status The configuration value of the register when 10M/100M/1000M is configured in athr_phy_speed in /common/athrsf1_phy.c can be configured to the corresponding register through the phy_write function. Next, modify the Kconfig file, add the AT803X_PHY option after the AR80XX_PHY option; add the obj-$(CONFIG_AR80XX_PHY) precompiled instruction in the Makefile; finally, modify the phy_id to 0x004dd072. If the phy_id is wrong, the PHY cannot be driven.
In addition, according to the general method of driving AR8035 with the CC version on the Internet, close the registration code of eth1 in mach-db120.c; then, modify the phy_mask value of the correct eth0. If it is AR9344, it supports up to 5 Ports, that is, BIT(0)-BIT(4). If the serial port print information cannot be determined when uboot starts, please make sure that your uboot can drive the 8035 normally, directly modify the print information in athr_auto_neg in athrsf1_phy.c, and printf the "Neg Success" statement directly, In this way, you know which Port it is, so you can determine which BIT (?) it is. If the BIT (?) selection is incorrect, the network port still cannot be connected, and the serial port will not be printed when plugging and unplugging the network cable. Therefore, if there is really no way, enable BIT(0) to BIT(4), compile 5 firmwares, and there will always be one firmware that can be successfully driven.
2 Conclusion
Using this method, the amount of change is very small, and the 8035 can be driven normally; the serial port printing is normal when plugging and unplugging the network cable; the 100M/1000M negotiation is normal (no 10M port verification); the flow is normal; the stability is normal. Thus, the original firmware can be migrated to the QSDK platform with confidence.