Le 06/01/2013 21:45, Gabor Juhos a écrit : > 2013.01.06. 21:08 keltezéssel, Michel Stempin írta: >> >> >> Le 06/01/2013 19:57, Gabor Juhos a écrit : >>> 2013.01.05. 14:53 keltezéssel, Michel Stempin írta: >>>> Here is the result of the same command on a genuine TL-WR703N with the >>>> newest factory firmware "3.14.4 build 120925 rel 33144n" (aka "Ver; 1.7"), >>>> thanks to Uncle_Vernon on the forum: >>>> >>>> U-Boot 1.1.4 (Sep 25 2012 - 09:04:47) >>>> >>>> AP121 (ar9330) U-boot >>>> >>>> <...> >>>> >>>> hornet> md.l 0xb8070000 1 >>>> b8070000: 00000190 .... >>>> hornet> >>> >>> Ok, this means that the description of the original patch is wrong, because >>> the >>> patch turns off the PHY_SWAP bit and it leaves the PYH_ADDR_SWAP bit set. >> >> Yes: my original patch description is wrong: older firmwares left both bits >> reset, newest firmware sets both bits. >> >>> >>> In theory, a simple >>> >>> ath79_setup_ar933x_phy4_switch(false, false); >>> >>> line should be enough to make it working, and the >>> >>> ath79_eth0_data.phy_mask = BIT(0); >>> >>> line should be dropped from the patch. >> >> But it looks like the default for id 0 in ath79_register_eth(id) is to set >> bit 4 in mask, which is wrong if we swap PHY 0 and 4, is it? > > Erm, the 'false, false' in the phy4_switch call above ensures that we don't > swap > the phy address. It was 'false, true' in the original patch.
Oh, yes, so BIT(0) is only required if 'false, true' is used, all right! >>>> I prefered to have this test performed on a stock v1.7 device rather than >>>> on my modified v1.6, just in case there is an unexpected hardware change >>>> between the 2 versions. >>>> >>>> So it looks like both PHYs and MACs are swapped in v1.7 U-Boot, while this >>>> wasn't the case in previous versions. >>>> >>>> >From what I understand, it looks like the newest U-Boot is routing the >>>> >Ethernet port 4 (the only one that is physically connected) through the >>>> >eth1 switch, rather than eth0? >>>> >>>> I don't see a reason for doing this: does it benefit from the GMII speed >>>> over simple MII, or is it to enable the switch QoS capabilities? Do you >>>> see any other reason? >>> >>> No, it makes no sense at all. The GE1 interface is always connected to MAC0 >>> of >>> the built-in switch via GMII interface regardless of the state of the >>> PHY_SWAP/PHY_ADDR_SWAP bits. >> >> Yes, I agree that GE1 interface is always connected to MAC0 according to >> AR9331 datasheet figure 2-3. >> >> Here is my understanding, correct me if I am wrong (this is quite >> possible!): >> >> On TL-WR703, the single physical Ethernet port is always connected to port >> 4, like in TL-MR3020/TL-MR3040/TL-MR11U. > > Yes, the RJ45 socket is connected to PHY4 of the internal switch. This is > fixed > by the board design. > >> If both PHY_SWAP and PYH_ADDR_SWAP are reset as with older firmware, the >> physical Ethernet is addressed as PHY4 and is routed directly to the CPU MAC5 >> through MII interface GE0 and PHY mask should be set to BIT(4). >> With newer firmware, both PHY_SWAP and PYH_ADDR_SWAP are set, so the >> physical Ethernet is addressed as PHY0 and is routed to the switch MAC1, >> then MAC0, then >> through GMII interface GE1 and PHY mask should be set to BIT(0). >> >> So basically, in older config, the Ethernet is routed directly to CPU's MAC5 >> using GE0 MII interface, while it is now routed through the switch using GE1 >> GMII interface. Is it correct? > > First of all, the built-in switch has no MAC5 interface, the datasheet is > simply > wrong about that IMHO. An MII (or GMII) interface connects a MAC to a PHY or a MAC to a MAC in Reversed MII configuration, so actually, I think there is a MAC indeed on the CPU side of GE0, which I guess they called MAC5, and I bet for MAC6 for the one on the CPU side of GE1... But I agree that the datasheet is not clear about it, and it is not mentioned anywhere else. > With regard to the SWAP bits: > > If the PHY_SWAP bit is '0', then the MAC1 of the internal switch is connected > to > PHY0 and GE0 interface of the SoC is connected to PHY4. If the bit is '1', > then > the MAC1 of the switch is connected to PHY4 instead of PHY0 and the GE0 > interface of the SoC is connected to PHY0 instad of PHY4. The GE1 interface of > the SoC is always connected to MAC0 of the switch. > > If PHY_ADDR_SWAP bit is zero, then PHY0 of the switch can be accessed at PHY > address 0 and PHY4 of the switch can be accessed at phy address 4. If the bit > is > set then PHY0 can be accessed at phy address 4, and PHY4 can be accessed at > phy > address 0. > >> >> The exact same patch that I proposed, consisting of the >> >> ath79_setup_ar933x_phy4_switch(false, true); >> >> line and the >> >> ath79_eth0_data.phy_mask = BIT(0); >> >> line is already applied in mach-tl-mr3020.c for TL-MR3020 routers and into >> mach-tl-mr11u.c for TL-MR3040/TL-MR11U routers, which have the exact same CPU >> and hardware configuration. > > Yes, I know that these changes were applied to other board files, but that > does > not mean that the changes were correct. > >> As I understand it, this patch restores the connection of external port 4 to >> PHY0/MAC5 using the direct GE0 MII interface, and connects PHY4/MAC1 in the >> switch. > > > The original patch clears the PHY_SWAP bit and sets the PHY_ADDR_SWAP bit. So > MAC1 of the siwtch will be connected to PHY0 and GE0 will be connected to > PHY4. > Because the PHY_ADDR_SWAP bit is still set, the PHY4 of the switch uses phy > address 0 and that is the reason why you had to change the default phy_mask as > well. The connection type of GE0 and GE1 interfaces are not changed by the > patch. So basically if I understand you correctly, both configs with: - PHY_SWAP=false, PHY_ADDR_SWAP=true, phy_mask=BIT(0) on one hand and - PHY_SWAP=false, PHY_ADDR_SWAP=false, phy_mask=BIT(4) (default) on the other hand are equivalent? Then what do you suggest: - apply the more complex TL-MR3020/TL-MR3040/TL-MR11U existing patch to TL-WR703N for consistency as I originally proposed - apply your simpler solution to all - or just apply your solution to TL-WR703N only and not being consistent with others? Anyway, thank you for these explanations! -Michel _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
