Odp: D-Link DWR 118
To samo było w DWR-921. Można było się zestarzeć podczas sysupgrade.
Mam: D-Linki DWR-921, DWR-118, DWR-116, TP-Link WDR-4900 v1, Checkpoint L-50, Linksysy 1900ACS, LB-Link BL-W1200,
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
eko.one.pl → Sprzęt / Hardware → D-Link DWR 118
Strony Poprzednia 1 2 3 4 … 14 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
To samo było w DWR-921. Można było się zestarzeć podczas sysupgrade.
Status zabawy: uruchomiłem port wan. Podłączony jest do portu0, ale domyślnie jest wyłączony, więc zabawa z rejestrami jest niezbędna. Został tylko ten GELAN (który jest podłączony do port4, przynajmniej tak twierdzi oryginalny soft) oraz te 3 ledy.
@Zuzia: zrób zdjęcie obudowy górnej od tego co przyszło do mnie, tak żeby ikony ledów było widać.
Proszę bardzo:
https://zapodaj.net/760487e6b0d00.jpg.html
https://zapodaj.net/815dff6baecca.jpg.html
Dorzucam fotkę zasilacza do kompletu, wydaje mi się, że jest słabszy niż w modelu DWR-116:
https://zapodaj.net/98c3796026513.jpg.html
Dzięki.
@Cezary
Udało Ci się ustalić id tego gigabitowego PHY?
@Zuzia
Zasilacz od 118 ma 18W natomiast od 116 ma 10W. Napięcia są inne.
Nie, wychodzi czy czas generic phy.
Czyli pewnie adres phy!= nr portu.
Na mailu masz rozwiązanie.
Właśnie nie wiem. Oryginalny soft po podłączeniu kabla do gigabitu twierdzi że właśnie port4 został podniesiony, po odłączeniu mówi że jest down. Więc po cichy zakładam że właśnie z 4 mam do czynienia. Ale sprawdzę. Już tyle obrazów zrobiłem że kolejny w niczym nie przeszkadza.
Nie, u mnie cały czas twierdzi:
mdio_bus mdio-bus: MDIO device at address 5 is missing.itd. jeżeli podstawię cokolwiek innego niż 4.
Dwa tematy związane z gigabitem:
1. Jboot nie przełącza portu czwartego w tryb gmac. Rozwiązanie:
diff --git a/target/linux/ramips/files-4.14/drivers/net/ethernet/mtk/gsw_mt7620.c b/target/linux/ramips/files-4.14/drivers/net/ethernet/mtk/gsw_mt7620.c
index 4093f09..75bfb9c 100644
--- a/target/linux/ramips/files-4.14/drivers/net/ethernet/mtk/gsw_mt7620.c
+++ b/target/linux/ramips/files-4.14/drivers/net/ethernet/mtk/gsw_mt7620.c
@@ -169,6 +169,22 @@ static void mt7620_hw_init(struct mt7620_gsw *gsw, struct device_node *np)
_mt7620_mii_write(gsw, 4, 0, 0x3100);
pr_info("gsw: setting port4 to ephy mode\n");
}
+ else if (gsw->port4 == PORT4_EXT) {
+ u32 val = rt_sysc_r32(SYSC_REG_CFG1);
+ pr_err("gsw: %X\n",val);
+ val &= ~(3 << 14);
+ rt_sysc_w32(val, SYSC_REG_CFG1);
+ pr_info("gsw: setting port4 to gmac mode\n");
+ }
+
}Najprawdopodobniej ten sam problem dotyczy DWR-960. Przygotuje soft uwzględniający włączanie portu 4 i 5 na openrouter.
2. PHY ma reset na nóżce 12 (łatwo poznać, bo ostatnia w rzędzie). Do niej podłączona jest ścieżka przez R780, która najpewniej idzie do proca. Istnieje szansa, że włączając odpowiednią IO puści się PHY z resetu i gigabit ruszy.
EDIT:
Jeśli chodzi o wolne SPI, sprawdź czy w dts jest maksymalna prędkość dla tego scalaka ustawiona.
Z resetem też już próbowałem, sprawdzę ten port4.
Dla SPI jest prędkość ustawiona, korzystam z identycznej definicji jak w 116.
Która IO odpowiada za reset tego phy?
Jest jeszcze gorzej:
Mon Apr 16 13:12:53 2018 kern.info kernel: [ 1.246646] libphy: Fixed MDIO Bus: probed
Mon Apr 16 13:12:53 2018 kern.err kernel: [ 1.262360] gsw: 260C50F
Mon Apr 16 13:12:53 2018 kern.info kernel: [ 1.267441] gsw: setting port4 to gmac mode
Mon Apr 16 13:12:53 2018 kern.info kernel: [ 1.275805] mtk_soc_eth 10100000.ethernet eth0 (uninitialized): port 3 link up (100Mbps/Full duplex)
Mon Apr 16 13:12:53 2018 kern.err kernel: [ 1.294024] mtk_soc_eth 10100000.ethernet: generated random MAC address 92:fd:9b:83:98:c6
Mon Apr 16 13:12:53 2018 kern.info kernel: [ 1.310507] libphy: mdio: probed
Mon Apr 16 13:12:53 2018 kern.err kernel: [ 1.317039] mdio_bus mdio-bus: MDIO device at address 4 is missing.Leciałem po wszystkich dostępnych wolnych gpio po kolei.
Reset PHY to nóżna PE_RST. Włączenie pcie i wykrycie 7612 spowoduje włączenie phy gigabitowego.
Mhm, tam jest włączone pcie bo radio przecież jest na 7612 które działa...
Pytanie tylko czy PE_RST jest puszczany po ładowaniu drivera od switcha czy przed. bo jeśli pe_rst jest podnoszony dopiero przy ładowaniu modułu do mt76, to trochę za późno bo driver ethernetowy się już wywalił na braku phy.
Możesz mieć rację. Oryginalny soft raportuje:
Marvel Giga Phy is found
Reset MARVELL phy2
Reset MARVELL phy2 DoneNo właśnie. Da się przeładować driver do switcha na samym końcu ładowania wszystkiego?
Tak, driver da się zbudować jako moduł i załadować później po prostu. Zrobiłem to, na razie nic z tego nie wynika, ale zobaczymy po południu.
http://github.com/jclehner/gpiodump-mt7 … s/tag/v0.1 -> możesz jeszcze na stock sofcie sprawdzić czy to na pewno port 4 w zależności od tego które IO są gpio.
Zatrzymałem się i nie wiem co dalej. 118 ma takie porty RJ45: WAN, GELAN, LAN3, LAN2, LAN1
OpenWrt: w tej chwili działają mi tylko porty WAN, LAN3, LAN2, LAN1, widziane przez swconfig jako
WAN: port0
LAN1: port2
LAN2: port1
LAN3: port3
Działają te lany, działa wan, można się dostać do routera, uzyskuje adres z dhcp na wanie itd.
Nie działa GELAN i co bym zrobił nie widzi go. Wszystkie łatki tu sugerowane nic dobrego nie robią, zwykły zrzut rejestrów nie pokazuje PHY_ID marvella, tak jak by go nie widział.
[ 1.469357] libphy: Fixed MDIO Bus: probed
[ 1.485226] PHY 0x0: 0x3A2940D
[ 1.491578] PHY 0x1: 0x3A2940D
[ 1.497885] PHY 0x2: 0x3A2940D
[ 1.504184] PHY 0x3: 0x3A2940D
[ 1.510491] PHY 0x4: 0x3A2940D
[ 1.516791] PHY 0x5: 0xFFFFFFFF
[ 1.523263] PHY 0x6: 0xFFFFFFFF
[ 1.529744] PHY 0x7: 0xFFFFFFFF
[ 1.536215] PHY 0x8: 0xFFFFFFFF
[ 1.542694] PHY 0x9: 0xFFFFFFFF
[ 1.549173] PHY 0xA: 0xFFFFFFFF
[ 1.555644] PHY 0xB: 0xFFFFFFFF
[ 1.562124] PHY 0xC: 0xFFFFFFFF
[ 1.568603] PHY 0xD: 0xFFFFFFFF
[ 1.575074] PHY 0xE: 0xFFFFFFFF
[ 1.581553] PHY 0xF: 0xFFFFFFFF
[ 1.588033] PHY 0x10: 0xFFFFFFFF
[ 1.594678] PHY 0x11: 0xFFFFFFFF
[ 1.601331] PHY 0x12: 0xFFFFFFFF
[ 1.607991] PHY 0x13: 0xFFFFFFFF
Pewnie jakieś reset chipu jest potrzebny. Ale...
Oryginalny soft: bootlog nie mówi za wiele. Wpięcie kabla w poszczególne porty daje:
WAN: ESW: Link Status Changed - Port0 Link UP
GELAN: ESW: Link Status Changed - Port4 Link UP
LAN3: ESW: Link Status Changed - Port3 Link UP
LAN2: ESW: Link Status Changed - Port1 Link UP
LAN1: ESW: Link Status Changed - Port2 Link UP
Więc jest względnie to sam co w OpenWrt. Znalazłem utils który podaje zawartość rejestrów i mam coś takiego
# switch phy
SPEC defined Register
[Port 0]===============
00: 1140 01: 796D 02: 0141 03: 0DD1 04: 01E1 05: CDE1 06: 000D 07: 2801
08: 4806 09: 0300 10: 3C00 11: 0000 12: 0000 13: 0003 14: 0000 15: 3000
[Port 1]===============
00: 0000 01: 7849 02: 03A2 03: 940D 04: 05E1 05: 0020 06: 0064 07: 2001
08: 0000 09: 0000 10: 0000 11: 0000 12: 0000 13: 0000 14: 0000 15: 0000
[Port 2]===============
00: 0000 01: 7849 02: 03A2 03: 940D 04: 05E1 05: 0020 06: 0064 07: 2001
08: 0000 09: 0000 10: 0000 11: 0000 12: 0000 13: 0000 14: 0000 15: 0000
[Port 3]===============
00: 0000 01: 7849 02: 03A2 03: 940D 04: 05E1 05: 0020 06: 0064 07: 2001
08: 0000 09: 0000 10: 0000 11: 0000 12: 0000 13: 0000 14: 0000 15: 0000
[Port 4]===============
00: 0000 01: 7849 02: 03A2 03: 940D 04: 01E1 05: 0020 06: 0064 07: 2001
08: 0000 09: 0000 10: 0000 11: 0000 12: 0000 13: 0000 14: 0000 15: 0000
Chip w urządzeniu to Marvell 88e1510, wg źródeł ma phyid == 01410dd0, tu zaś na porcie 0 widziane jest coś o phyid 01410dd1. Może jakaś odmiana, ale tak czy siak nie wiem jak spowodować żeby ten phyid był widziany.
Odpowiadając na poprzedniego posta: oryginalny soft:
# ./a
GPIOMODE = 0x0040821d
SUTIF_SHARE_MODE = 0, disabled [default]
WDT_RST_MODE = 2, GPIO
PA_G_GPIO_MODE = 0, normal
ND_SD_GPIO_MODE = 0, NAND
PERST_GPIO_MODE = 0, PERST_N
EPHY_LED_GPIO_MODE = 1, GPIO
WLED_GPIO_MODE = 0, normal
SPI_REFCLK0_MODE = 0, normal
SPI_GPIO_MODE = 0, normal [default]
RGMII2_GPIO_MODE = 0, normal
RGMII1_GPIO_MODE = 1, GPIO [default]
MDIO_GPIO_MODE = 0, normal
UARTL_GPIO_MODE = 0, normal
UARTF_SHARE_MODE = 7, GPIO [default]
I2C_GPIO_MODE = 1, GPIO [default]
# I moje openwrt:
root@OpenWrt:/tmp# ./a 0x0040821d
GPIOMODE = 0x0040821d
SUTIF_SHARE_MODE = 0, disabled [default]
WDT_RST_MODE = 2, GPIO
PA_G_GPIO_MODE = 0, normal
ND_SD_GPIO_MODE = 0, NAND
PERST_GPIO_MODE = 0, PERST_N
EPHY_LED_GPIO_MODE = 1, GPIO
WLED_GPIO_MODE = 0, normal
SPI_REFCLK0_MODE = 0, normal
SPI_GPIO_MODE = 0, normal [default]
RGMII2_GPIO_MODE = 0, normal
RGMII1_GPIO_MODE = 1, GPIO [default]
MDIO_GPIO_MODE = 0, normal
UARTL_GPIO_MODE = 0, normal
UARTF_SHARE_MODE = 7, GPIO [default]
I2C_GPIO_MODE = 1, GPIO [default]
root@OpenWrt:/tmp# D-link wprowadza straszny bałagan. Ale PHYid się zgadza bo ostatnie bity to nr rewizji krzemu.
W OFW port 4 to port 5 w Openwrt.
Kompilowałeś wszystkie drivery ethernetowe mt7620 jako moduły?
Aha, rzecz oczywista dla mnie i nie wspominałem - mt7620 nie ma domyślnie obsługi marvella więc oczywiście zaznaczyłem to dodatkowo w konfigu. Tak, i w postaci modułu i wkompilowane na stałe w kernel.
Aha, rzecz oczywista dla mnie i nie wspominałem - mt7620 nie ma domyślnie obsługi marvella więc oczywiście zaznaczyłem to dodatkowo w konfigu. Tak, i w postaci modułu i wkompilowane na stałe w kernel.
Każdy PHY powinien być w stanie działać jako Generic. Podstawowe rejestry są opisane standardem. Tutaj D-link ewidentnie coś przekombinował. Chociaż do tej pory w kwestii DWR-960 też nie ma sukcesu. Jest kod GPL do 118?
Strony Poprzednia 1 2 3 4 … 14 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
eko.one.pl → Sprzęt / Hardware → D-Link DWR 118
Forum oparte o PunBB, wspierane przez Informer Technologies, Inc