U-Boot 2009.08 for ZTE F460/F660 v3 and HGG420N v3

Maybe there are some people owning this modem want to hack it, I have ported U-Boot 2009.08 from SG200 opensource code to these two modems.

*Download here*

For ZTE F460/F660 v3(they're compatible):
Github releases
For HGG420N:
Github releases

To flash it to your modem, you need:
Download 'u-boot-xxxx_533_128m_ddr3_nand.bin' and put it to the root directory of an tftp server running on your computer, set your computer's IP address to uboot environment: 'serverip'
Use UART to connect to your modem, keep press 'enter' to interrupt booting and type these commands

tftp u-boot-xxxx_533_128m_ddr3_nand.bin (xxxx should be replaced)
nand erase 0x0 0x100000
nand write 0x2000000 0x0 0x100000

Then reboot, you will enter your new U-Boot

If you damaged your U-Boot or can't enter U-Boot console, follow these steps to use kwboot
kwboot usage

@bodhi,

Any plan on fixing mvneta driver on newer kernel for 88f6560?

8086k,

> Any plan on fixing mvneta driver on newer kernel
> for 88f6560?

Not really, I'm hesitated to get into this activity and then spend all the time I don't have on it :)

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi,

I have improved my C language ability recently. Since I ported new U-Boot for F660 which fixes PCI-E, I have been busy fixing realtek linux driver because RTL8192CE's AP mode seemed to be broken in openwrt compat-wireless. I have also read some mvneta.c commit logs. But have no more spare time to try anything. It's pretty helpful to have newer kernel with ethernet working.

8086k

bodhi,

There is some commits I have found may related to the issue, please try reverting them when you have time :)
commit2
commit1



Edited 1 time(s). Last edit at 10/14/2021 10:30AM by 8086k.

@bodhi

Yeah! I know how to solve the mvneta issue!
In Claudio's patch, there is a hunk adding device tree gmii phy_mode detect for mvneta.

--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -2760,7 +2760,10 @@ static void mvneta_port_power_up(struct
 	if (phy_mode == PHY_INTERFACE_MODE_SGMII)
 		mvneta_port_sgmii_config(pp);
 
-	mvneta_gmac_rgmii_set(pp, 1);
+	if (phy_mode == PHY_INTERFACE_MODE_GMII)
+		mvneta_gmac_rgmii_set(pp, 0);
+	else
+		mvneta_gmac_rgmii_set(pp, 1);
 
 	/* Cancel Port Reset */
 	val = mvreg_read(pp, MVNETA_GMAC_CTRL_2);

In device tree, eth nodes are using

phy-mode = "gmii";

But newer mvneta changed this function and made this init section very messy, because they wanted to add qsgmii support which we don't need for 88f6560.

So we can just revert the two commits above, and add gmii case again in newer mvneta driver by applying the patch hunk above.

This is my opinion, I believe it can solve the issue XD. Please test it on MI424WR-I

8086k

@bodhi,

For your IRQ issue, I have also found two commits causing the problem.
commit2
commit1
I think Avanta just like kirkwood, doesn't support per_cpu interrupts. So these two commits causes the problem. I am thinking how to fix it. Maybe revert as well? :)

Until now, I think the easiest way is change some of the armada3700 if cases to armada370 which used by 88f6560. armada3700 doesn't support per-cpu interrupts and the driver has supported it.

8086k



Edited 2 time(s). Last edit at 10/17/2021 09:01AM by 8086k.