Re: [OpenWrt-Devel] ar934x+ar8327v4
On Wed, Dec 10, 2014 at 04:25:08PM +0100, John Crispin wrote: > > ath79_eth0_pll_data.pll_1000 = 0x6f00; > > > > Fixes my rb-2011uias-2hnd as well. I now have all ten ethernet > > ports working, the 5 x 10/100 *and* the 5 x Gigabit. > > > > Thanks very much David. > > > > ... and I look forward to a patch with the proper value. > > > > Can test etc. as needed. I even have a faster machine I'm just > > starting to configure as my desktop Linux box (where I do the > > build) so it won't take me so long to build. > > > > > the register layout is as follows for the top 8 bit > > 31TX_INVERT - Decides whether to select the inversion of the GTX > clock after the delay line > 30GIGE_QUAD - Decides whether to allow a 2 ns shift (clock in the > middle of a data transfer) to the GTX clock. This bit is only > effective when bit 25 is set. > 29:28 RX_DELAY - The delay buffers in the Rx clock path to adjust > against the edge/middle- aligned RGMII inputs > 27:26 TX_DELAY - Delay line for the GTX clock that goes along with the > data > 25GIGE- Set only after a 1000 Mbps connection has been negotiated > 24OFFSET_PHASE - Used to select if the start is from the positive or > negative phase (or whether to have a 180 degree change in addition to > the phase-delay in [11:8]. > > can you try to see if only setting the bits 29:26 is enough or if any > of the other bits need to be set ? if that does not work it has to be > 30, 25 or 24 > I'm away from home now (just got to test the 0x6f00 before I left) I'll be home on Friday evening and will test fewer bits then. -- Chris Green ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
That sounds like the way to go, if we can grab that information from boot. I can't wait to see how this is done! -- Davey On Wed, Dec 10, 2014 at 1:06 PM, John Crispin wrote: > Hi, > > felix just pointed out that we could simply read the settings inside the > kernel head after boot and see what the bootloader used. > > i'll try to cook a patch tomorrow that you can use to test this. > > John > > On 10/12/2014 20:06, John Crispin wrote: >> >> >> On 10/12/2014 20:02, David Hutchison wrote: >>> I confirmed 0x3e00 works, we can toggle bit 25 as well :) >>> >>> I left in the AR934X_ETH_CFG_RXD_DELAY >>> >>> However ar71xx_regs.h does not contain AR934X_ETH_CFG_TXD_DELAY >>> definition. AR934X_ETH_CFG_RXD_DELAY is set to BIT(14). I can add the >>> AR934X_ETH_CFG_TXD_DELAY definition to the ar71xx_regs.h file if you >>> know what BIT() value that would be. I am guessing it would be >>> BIT(15), I definitely want to confirm :) >>> >>> Do you think that is necessary, or should we leave it with >>> AR934X_ETH_CFG_RXD_DELAY only? >> >> >> it is bit 18, however it is not used anywhere and it is a shot into the >> dark. lets only use RXD for now and i will ping QCA and ask them to tell >> me what the bit actually does. >> >> do you feel like sending a patch with your fixes ? :-D >> >> John >> >> >>> >>> -- Davey >>> >>> On Wed, Dec 10, 2014 at 11:36 AM, John Crispin wrote: On 10/12/2014 18:27, David Hutchison wrote: > Hello John, > > Thank you for the prompt response. It looks like it works with > 29:26 set: > > ath79_eth0_pll_data.pll_1000 = 0x3c00; > > I think we found a solution :) > looking at the other routerboards bit 25 is always set does 0x3e00 work ? > Since we are now toggling RX/TX Delays. Should we also change > > ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_RGMII_GMAC0 | > AR934X_ETH_CFG_SW_ONLY_MODE); > > to > > ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_RGMII_GMAC0 | > AR934X_ETH_CFG_RXD_DELAY | AR934X_ETH_CFG_SW_ONLY_MODE); > i would even go for TX_DELAY and RX_DELAY not sure though, the datasheet says "enable delay" as a description :) i think setting 0x3e00 and adding AR934X_ETH_CFG_RXD_DELAY | AR934X_ETH_CFG_TXD_DELAY looks right. please see if the ethernet work with those 2 fixes applied John > It seems to work in both modes ( the pll_1000 was the real problem > ). I just want to insure consistency. Thanks again for the > information from the datasheet. > > -- Davey > > On Wed, Dec 10, 2014 at 8:25 AM, John Crispin > wrote: >> >> >> On 10/12/2014 14:44, Chris Green wrote: >>> On Wed, Dec 10, 2014 at 10:23:12AM +, Chris Green wrote: On Wed, Dec 10, 2014 at 09:59:29AM +0100, John Crispin wrote: > > > On 10/12/2014 09:29, David Hutchison wrote: >> I am once again just guessing with 0x6f00, so I am >> sure this is wrong. I would love to learn if you could >> give me insight :-) >> >> I would also love to make a patch for both the 951G and >> the rb2011 (gigabit switch version). I don't have packet >> loss anymore! :-) > > nice work ! > > i will track down someone with a datasheet today so that > we know what the register actually does :) > Excellent, I will try patching this on my RB2011 (to 0x6f00) and see if it works for me too. >>> Eureka! :-) >>> >>> Changing the line in mach-rb2011.c from:- >>> >>> ath79_eth0_pll_data.pll_1000 = 0x0600; >>> >>> to:- >>> >>> ath79_eth0_pll_data.pll_1000 = 0x6f00; >>> >>> Fixes my rb-2011uias-2hnd as well. I now have all ten >>> ethernet ports working, the 5 x 10/100 *and* the 5 x Gigabit. >>> >>> Thanks very much David. >>> >>> ... and I look forward to a patch with the proper value. >>> >>> Can test etc. as needed. I even have a faster machine I'm >>> just starting to configure as my desktop Linux box (where I do >>> the build) so it won't take me so long to build. >>> >> >> >> the register layout is as follows for the top 8 bit >> >> 31 TX_INVERT - Decides whether to select the inversion of >> the GTX clock after the delay line 30 GIGE_QUAD - Decides >> whether to allow a 2 ns shift (clock in the middle of a data >> transfer) to the GTX clock. This bit is only effective when bit >> 25 is set. 29:28 RX_DELAY - The delay buffers in the Rx clock >> path to adjust against the edge/middle- aligned RGMII inputs >> 27:26 TX_DELAY - Delay line for the GTX clock that goes along >> with the data 25 GIGE- Set only after a 1000 Mbps >> connection has bee
Re: [OpenWrt-Devel] ar934x+ar8327v4
Hi, felix just pointed out that we could simply read the settings inside the kernel head after boot and see what the bootloader used. i'll try to cook a patch tomorrow that you can use to test this. John On 10/12/2014 20:06, John Crispin wrote: > > > On 10/12/2014 20:02, David Hutchison wrote: >> I confirmed 0x3e00 works, we can toggle bit 25 as well :) >> >> I left in the AR934X_ETH_CFG_RXD_DELAY >> >> However ar71xx_regs.h does not contain AR934X_ETH_CFG_TXD_DELAY >> definition. AR934X_ETH_CFG_RXD_DELAY is set to BIT(14). I can add the >> AR934X_ETH_CFG_TXD_DELAY definition to the ar71xx_regs.h file if you >> know what BIT() value that would be. I am guessing it would be >> BIT(15), I definitely want to confirm :) >> >> Do you think that is necessary, or should we leave it with >> AR934X_ETH_CFG_RXD_DELAY only? > > > it is bit 18, however it is not used anywhere and it is a shot into the > dark. lets only use RXD for now and i will ping QCA and ask them to tell > me what the bit actually does. > > do you feel like sending a patch with your fixes ? :-D > > John > > >> >> -- Davey >> >> On Wed, Dec 10, 2014 at 11:36 AM, John Crispin wrote: >>> >>> >>> On 10/12/2014 18:27, David Hutchison wrote: Hello John, Thank you for the prompt response. It looks like it works with 29:26 set: ath79_eth0_pll_data.pll_1000 = 0x3c00; I think we found a solution :) >>> >>> looking at the other routerboards bit 25 is always set does 0x3e00 >>> work ? >>> >>> Since we are now toggling RX/TX Delays. Should we also change ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_RGMII_GMAC0 | AR934X_ETH_CFG_SW_ONLY_MODE); to ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_RGMII_GMAC0 | AR934X_ETH_CFG_RXD_DELAY | AR934X_ETH_CFG_SW_ONLY_MODE); >>> >>> i would even go for TX_DELAY and RX_DELAY >>> >>> not sure though, the datasheet says "enable delay" as a description :) >>> >>> i think setting 0x3e00 and adding AR934X_ETH_CFG_RXD_DELAY | >>> AR934X_ETH_CFG_TXD_DELAY looks right. please see if the ethernet work >>> with those 2 fixes applied >>> >>> John >>> >>> >>> >>> >>> It seems to work in both modes ( the pll_1000 was the real problem ). I just want to insure consistency. Thanks again for the information from the datasheet. -- Davey On Wed, Dec 10, 2014 at 8:25 AM, John Crispin wrote: > > > On 10/12/2014 14:44, Chris Green wrote: >> On Wed, Dec 10, 2014 at 10:23:12AM +, Chris Green wrote: >>> On Wed, Dec 10, 2014 at 09:59:29AM +0100, John Crispin >>> wrote: On 10/12/2014 09:29, David Hutchison wrote: > I am once again just guessing with 0x6f00, so I am > sure this is wrong. I would love to learn if you could > give me insight :-) > > I would also love to make a patch for both the 951G and > the rb2011 (gigabit switch version). I don't have packet > loss anymore! :-) nice work ! i will track down someone with a datasheet today so that we know what the register actually does :) >>> Excellent, I will try patching this on my RB2011 (to >>> 0x6f00) and see if it works for me too. >>> >> Eureka! :-) >> >> Changing the line in mach-rb2011.c from:- >> >> ath79_eth0_pll_data.pll_1000 = 0x0600; >> >> to:- >> >> ath79_eth0_pll_data.pll_1000 = 0x6f00; >> >> Fixes my rb-2011uias-2hnd as well. I now have all ten >> ethernet ports working, the 5 x 10/100 *and* the 5 x Gigabit. >> >> Thanks very much David. >> >> ... and I look forward to a patch with the proper value. >> >> Can test etc. as needed. I even have a faster machine I'm >> just starting to configure as my desktop Linux box (where I do >> the build) so it won't take me so long to build. >> > > > the register layout is as follows for the top 8 bit > > 31 TX_INVERT - Decides whether to select the inversion of > the GTX clock after the delay line 30 GIGE_QUAD - Decides > whether to allow a 2 ns shift (clock in the middle of a data > transfer) to the GTX clock. This bit is only effective when bit > 25 is set. 29:28 RX_DELAY - The delay buffers in the Rx clock > path to adjust against the edge/middle- aligned RGMII inputs > 27:26 TX_DELAY - Delay line for the GTX clock that goes along > with the data 25 GIGE- Set only after a 1000 Mbps > connection has been negotiated 24 OFFSET_PHASE - Used to > select if the start is from the positive or negative phase (or > whether to have a 180 degree change in addition to the > phase-delay in [11:8]. > > can you try to see if only setting the bits 29:26 is enough or if > any of the other bits need to be set ?
Re: [OpenWrt-Devel] ar934x+ar8327v4
On 10/12/2014 20:02, David Hutchison wrote: > I confirmed 0x3e00 works, we can toggle bit 25 as well :) > > I left in the AR934X_ETH_CFG_RXD_DELAY > > However ar71xx_regs.h does not contain AR934X_ETH_CFG_TXD_DELAY > definition. AR934X_ETH_CFG_RXD_DELAY is set to BIT(14). I can add the > AR934X_ETH_CFG_TXD_DELAY definition to the ar71xx_regs.h file if you > know what BIT() value that would be. I am guessing it would be > BIT(15), I definitely want to confirm :) > > Do you think that is necessary, or should we leave it with > AR934X_ETH_CFG_RXD_DELAY only? it is bit 18, however it is not used anywhere and it is a shot into the dark. lets only use RXD for now and i will ping QCA and ask them to tell me what the bit actually does. do you feel like sending a patch with your fixes ? :-D John > > -- Davey > > On Wed, Dec 10, 2014 at 11:36 AM, John Crispin wrote: >> >> >> On 10/12/2014 18:27, David Hutchison wrote: >>> Hello John, >>> >>> Thank you for the prompt response. It looks like it works with >>> 29:26 set: >>> >>> ath79_eth0_pll_data.pll_1000 = 0x3c00; >>> >>> I think we found a solution :) >>> >> >> looking at the other routerboards bit 25 is always set does 0x3e00 >> work ? >> >> >>> Since we are now toggling RX/TX Delays. Should we also change >>> >>> ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_RGMII_GMAC0 | >>> AR934X_ETH_CFG_SW_ONLY_MODE); >>> >>> to >>> >>> ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_RGMII_GMAC0 | >>> AR934X_ETH_CFG_RXD_DELAY | AR934X_ETH_CFG_SW_ONLY_MODE); >>> >> >> i would even go for TX_DELAY and RX_DELAY >> >> not sure though, the datasheet says "enable delay" as a description :) >> >> i think setting 0x3e00 and adding AR934X_ETH_CFG_RXD_DELAY | >> AR934X_ETH_CFG_TXD_DELAY looks right. please see if the ethernet work >> with those 2 fixes applied >> >> John >> >> >> >> >> >>> It seems to work in both modes ( the pll_1000 was the real problem >>> ). I just want to insure consistency. Thanks again for the >>> information from the datasheet. >>> >>> -- Davey >>> >>> On Wed, Dec 10, 2014 at 8:25 AM, John Crispin >>> wrote: On 10/12/2014 14:44, Chris Green wrote: > On Wed, Dec 10, 2014 at 10:23:12AM +, Chris Green wrote: >> On Wed, Dec 10, 2014 at 09:59:29AM +0100, John Crispin >> wrote: >>> >>> >>> On 10/12/2014 09:29, David Hutchison wrote: I am once again just guessing with 0x6f00, so I am sure this is wrong. I would love to learn if you could give me insight :-) I would also love to make a patch for both the 951G and the rb2011 (gigabit switch version). I don't have packet loss anymore! :-) >>> >>> nice work ! >>> >>> i will track down someone with a datasheet today so that >>> we know what the register actually does :) >>> >> Excellent, I will try patching this on my RB2011 (to >> 0x6f00) and see if it works for me too. >> > Eureka! :-) > > Changing the line in mach-rb2011.c from:- > > ath79_eth0_pll_data.pll_1000 = 0x0600; > > to:- > > ath79_eth0_pll_data.pll_1000 = 0x6f00; > > Fixes my rb-2011uias-2hnd as well. I now have all ten > ethernet ports working, the 5 x 10/100 *and* the 5 x Gigabit. > > Thanks very much David. > > ... and I look forward to a patch with the proper value. > > Can test etc. as needed. I even have a faster machine I'm > just starting to configure as my desktop Linux box (where I do > the build) so it won't take me so long to build. > the register layout is as follows for the top 8 bit 31 TX_INVERT - Decides whether to select the inversion of the GTX clock after the delay line 30 GIGE_QUAD - Decides whether to allow a 2 ns shift (clock in the middle of a data transfer) to the GTX clock. This bit is only effective when bit 25 is set. 29:28 RX_DELAY - The delay buffers in the Rx clock path to adjust against the edge/middle- aligned RGMII inputs 27:26 TX_DELAY - Delay line for the GTX clock that goes along with the data 25 GIGE- Set only after a 1000 Mbps connection has been negotiated 24 OFFSET_PHASE - Used to select if the start is from the positive or negative phase (or whether to have a 180 degree change in addition to the phase-delay in [11:8]. can you try to see if only setting the bits 29:26 is enough or if any of the other bits need to be set ? if that does not work it has to be 30, 25 or 24 John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >>> ___ openwrt-devel >>> mailing list openwrt-devel@lists.openwrt.org >>> https://lists.openwrt.org/cgi-bin/mailm
Re: [OpenWrt-Devel] ar934x+ar8327v4
I confirmed 0x3e00 works, we can toggle bit 25 as well :) I left in the AR934X_ETH_CFG_RXD_DELAY However ar71xx_regs.h does not contain AR934X_ETH_CFG_TXD_DELAY definition. AR934X_ETH_CFG_RXD_DELAY is set to BIT(14). I can add the AR934X_ETH_CFG_TXD_DELAY definition to the ar71xx_regs.h file if you know what BIT() value that would be. I am guessing it would be BIT(15), I definitely want to confirm :) Do you think that is necessary, or should we leave it with AR934X_ETH_CFG_RXD_DELAY only? -- Davey On Wed, Dec 10, 2014 at 11:36 AM, John Crispin wrote: > > > On 10/12/2014 18:27, David Hutchison wrote: >> Hello John, >> >> Thank you for the prompt response. It looks like it works with >> 29:26 set: >> >> ath79_eth0_pll_data.pll_1000 = 0x3c00; >> >> I think we found a solution :) >> > > looking at the other routerboards bit 25 is always set does 0x3e00 > work ? > > >> Since we are now toggling RX/TX Delays. Should we also change >> >> ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_RGMII_GMAC0 | >> AR934X_ETH_CFG_SW_ONLY_MODE); >> >> to >> >> ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_RGMII_GMAC0 | >> AR934X_ETH_CFG_RXD_DELAY | AR934X_ETH_CFG_SW_ONLY_MODE); >> > > i would even go for TX_DELAY and RX_DELAY > > not sure though, the datasheet says "enable delay" as a description :) > > i think setting 0x3e00 and adding AR934X_ETH_CFG_RXD_DELAY | > AR934X_ETH_CFG_TXD_DELAY looks right. please see if the ethernet work > with those 2 fixes applied > > John > > > > > >> It seems to work in both modes ( the pll_1000 was the real problem >> ). I just want to insure consistency. Thanks again for the >> information from the datasheet. >> >> -- Davey >> >> On Wed, Dec 10, 2014 at 8:25 AM, John Crispin >> wrote: >>> >>> >>> On 10/12/2014 14:44, Chris Green wrote: On Wed, Dec 10, 2014 at 10:23:12AM +, Chris Green wrote: > On Wed, Dec 10, 2014 at 09:59:29AM +0100, John Crispin > wrote: >> >> >> On 10/12/2014 09:29, David Hutchison wrote: >>> I am once again just guessing with 0x6f00, so I am >>> sure this is wrong. I would love to learn if you could >>> give me insight :-) >>> >>> I would also love to make a patch for both the 951G and >>> the rb2011 (gigabit switch version). I don't have packet >>> loss anymore! :-) >> >> nice work ! >> >> i will track down someone with a datasheet today so that >> we know what the register actually does :) >> > Excellent, I will try patching this on my RB2011 (to > 0x6f00) and see if it works for me too. > Eureka! :-) Changing the line in mach-rb2011.c from:- ath79_eth0_pll_data.pll_1000 = 0x0600; to:- ath79_eth0_pll_data.pll_1000 = 0x6f00; Fixes my rb-2011uias-2hnd as well. I now have all ten ethernet ports working, the 5 x 10/100 *and* the 5 x Gigabit. Thanks very much David. ... and I look forward to a patch with the proper value. Can test etc. as needed. I even have a faster machine I'm just starting to configure as my desktop Linux box (where I do the build) so it won't take me so long to build. >>> >>> >>> the register layout is as follows for the top 8 bit >>> >>> 31 TX_INVERT - Decides whether to select the inversion of >>> the GTX clock after the delay line 30 GIGE_QUAD - Decides >>> whether to allow a 2 ns shift (clock in the middle of a data >>> transfer) to the GTX clock. This bit is only effective when bit >>> 25 is set. 29:28 RX_DELAY - The delay buffers in the Rx clock >>> path to adjust against the edge/middle- aligned RGMII inputs >>> 27:26 TX_DELAY - Delay line for the GTX clock that goes along >>> with the data 25 GIGE- Set only after a 1000 Mbps >>> connection has been negotiated 24 OFFSET_PHASE - Used to >>> select if the start is from the positive or negative phase (or >>> whether to have a 180 degree change in addition to the >>> phase-delay in [11:8]. >>> >>> can you try to see if only setting the bits 29:26 is enough or if >>> any of the other bits need to be set ? if that does not work it >>> has to be 30, 25 or 24 >>> >>> John ___ >>> openwrt-devel mailing list openwrt-devel@lists.openwrt.org >>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >> ___ openwrt-devel >> mailing list openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >> > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
On 10/12/2014 18:27, David Hutchison wrote: > Hello John, > > Thank you for the prompt response. It looks like it works with > 29:26 set: > > ath79_eth0_pll_data.pll_1000 = 0x3c00; > > I think we found a solution :) > looking at the other routerboards bit 25 is always set does 0x3e00 work ? > Since we are now toggling RX/TX Delays. Should we also change > > ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_RGMII_GMAC0 | > AR934X_ETH_CFG_SW_ONLY_MODE); > > to > > ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_RGMII_GMAC0 | > AR934X_ETH_CFG_RXD_DELAY | AR934X_ETH_CFG_SW_ONLY_MODE); > i would even go for TX_DELAY and RX_DELAY not sure though, the datasheet says "enable delay" as a description :) i think setting 0x3e00 and adding AR934X_ETH_CFG_RXD_DELAY | AR934X_ETH_CFG_TXD_DELAY looks right. please see if the ethernet work with those 2 fixes applied John > It seems to work in both modes ( the pll_1000 was the real problem > ). I just want to insure consistency. Thanks again for the > information from the datasheet. > > -- Davey > > On Wed, Dec 10, 2014 at 8:25 AM, John Crispin > wrote: >> >> >> On 10/12/2014 14:44, Chris Green wrote: >>> On Wed, Dec 10, 2014 at 10:23:12AM +, Chris Green wrote: On Wed, Dec 10, 2014 at 09:59:29AM +0100, John Crispin wrote: > > > On 10/12/2014 09:29, David Hutchison wrote: >> I am once again just guessing with 0x6f00, so I am >> sure this is wrong. I would love to learn if you could >> give me insight :-) >> >> I would also love to make a patch for both the 951G and >> the rb2011 (gigabit switch version). I don't have packet >> loss anymore! :-) > > nice work ! > > i will track down someone with a datasheet today so that > we know what the register actually does :) > Excellent, I will try patching this on my RB2011 (to 0x6f00) and see if it works for me too. >>> Eureka! :-) >>> >>> Changing the line in mach-rb2011.c from:- >>> >>> ath79_eth0_pll_data.pll_1000 = 0x0600; >>> >>> to:- >>> >>> ath79_eth0_pll_data.pll_1000 = 0x6f00; >>> >>> Fixes my rb-2011uias-2hnd as well. I now have all ten >>> ethernet ports working, the 5 x 10/100 *and* the 5 x Gigabit. >>> >>> Thanks very much David. >>> >>> ... and I look forward to a patch with the proper value. >>> >>> Can test etc. as needed. I even have a faster machine I'm >>> just starting to configure as my desktop Linux box (where I do >>> the build) so it won't take me so long to build. >>> >> >> >> the register layout is as follows for the top 8 bit >> >> 31 TX_INVERT - Decides whether to select the inversion of >> the GTX clock after the delay line 30 GIGE_QUAD - Decides >> whether to allow a 2 ns shift (clock in the middle of a data >> transfer) to the GTX clock. This bit is only effective when bit >> 25 is set. 29:28 RX_DELAY - The delay buffers in the Rx clock >> path to adjust against the edge/middle- aligned RGMII inputs >> 27:26 TX_DELAY - Delay line for the GTX clock that goes along >> with the data 25 GIGE- Set only after a 1000 Mbps >> connection has been negotiated 24 OFFSET_PHASE - Used to >> select if the start is from the positive or negative phase (or >> whether to have a 180 degree change in addition to the >> phase-delay in [11:8]. >> >> can you try to see if only setting the bits 29:26 is enough or if >> any of the other bits need to be set ? if that does not work it >> has to be 30, 25 or 24 >> >> John ___ >> openwrt-devel mailing list openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > ___ openwrt-devel > mailing list openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
Hello John, Thank you for the prompt response. It looks like it works with 29:26 set: ath79_eth0_pll_data.pll_1000 = 0x3c00; I think we found a solution :) Since we are now toggling RX/TX Delays. Should we also change ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_RGMII_GMAC0 | AR934X_ETH_CFG_SW_ONLY_MODE); to ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_RGMII_GMAC0 | AR934X_ETH_CFG_RXD_DELAY | AR934X_ETH_CFG_SW_ONLY_MODE); It seems to work in both modes ( the pll_1000 was the real problem ). I just want to insure consistency. Thanks again for the information from the datasheet. -- Davey On Wed, Dec 10, 2014 at 8:25 AM, John Crispin wrote: > > > On 10/12/2014 14:44, Chris Green wrote: >> On Wed, Dec 10, 2014 at 10:23:12AM +, Chris Green wrote: >>> On Wed, Dec 10, 2014 at 09:59:29AM +0100, John Crispin wrote: On 10/12/2014 09:29, David Hutchison wrote: > I am once again just guessing with 0x6f00, so I am sure > this is wrong. I would love to learn if you could give me > insight :-) > > I would also love to make a patch for both the 951G and the > rb2011 (gigabit switch version). I don't have packet loss > anymore! :-) nice work ! i will track down someone with a datasheet today so that we know what the register actually does :) >>> Excellent, I will try patching this on my RB2011 (to 0x6f00) >>> and see if it works for me too. >>> >> Eureka! :-) >> >> Changing the line in mach-rb2011.c from:- >> >> ath79_eth0_pll_data.pll_1000 = 0x0600; >> >> to:- >> >> ath79_eth0_pll_data.pll_1000 = 0x6f00; >> >> Fixes my rb-2011uias-2hnd as well. I now have all ten ethernet >> ports working, the 5 x 10/100 *and* the 5 x Gigabit. >> >> Thanks very much David. >> >> ... and I look forward to a patch with the proper value. >> >> Can test etc. as needed. I even have a faster machine I'm just >> starting to configure as my desktop Linux box (where I do the >> build) so it won't take me so long to build. >> > > > the register layout is as follows for the top 8 bit > > 31 TX_INVERT - Decides whether to select the inversion of the GTX > clock after the delay line > 30 GIGE_QUAD - Decides whether to allow a 2 ns shift (clock in the > middle of a data transfer) to the GTX clock. This bit is only > effective when bit 25 is set. > 29:28 RX_DELAY - The delay buffers in the Rx clock path to adjust > against the edge/middle- aligned RGMII inputs > 27:26 TX_DELAY - Delay line for the GTX clock that goes along with the > data > 25 GIGE- Set only after a 1000 Mbps connection has been negotiated > 24 OFFSET_PHASE - Used to select if the start is from the positive or > negative phase (or whether to have a 180 degree change in addition to > the phase-delay in [11:8]. > > can you try to see if only setting the bits 29:26 is enough or if any > of the other bits need to be set ? if that does not work it has to be > 30, 25 or 24 > > John > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
On 10/12/2014 14:44, Chris Green wrote: > On Wed, Dec 10, 2014 at 10:23:12AM +, Chris Green wrote: >> On Wed, Dec 10, 2014 at 09:59:29AM +0100, John Crispin wrote: >>> >>> >>> On 10/12/2014 09:29, David Hutchison wrote: I am once again just guessing with 0x6f00, so I am sure this is wrong. I would love to learn if you could give me insight :-) I would also love to make a patch for both the 951G and the rb2011 (gigabit switch version). I don't have packet loss anymore! :-) >>> >>> nice work ! >>> >>> i will track down someone with a datasheet today so that we >>> know what the register actually does :) >>> >> Excellent, I will try patching this on my RB2011 (to 0x6f00) >> and see if it works for me too. >> > Eureka! :-) > > Changing the line in mach-rb2011.c from:- > > ath79_eth0_pll_data.pll_1000 = 0x0600; > > to:- > > ath79_eth0_pll_data.pll_1000 = 0x6f00; > > Fixes my rb-2011uias-2hnd as well. I now have all ten ethernet > ports working, the 5 x 10/100 *and* the 5 x Gigabit. > > Thanks very much David. > > ... and I look forward to a patch with the proper value. > > Can test etc. as needed. I even have a faster machine I'm just > starting to configure as my desktop Linux box (where I do the > build) so it won't take me so long to build. > the register layout is as follows for the top 8 bit 31 TX_INVERT - Decides whether to select the inversion of the GTX clock after the delay line 30 GIGE_QUAD - Decides whether to allow a 2 ns shift (clock in the middle of a data transfer) to the GTX clock. This bit is only effective when bit 25 is set. 29:28 RX_DELAY - The delay buffers in the Rx clock path to adjust against the edge/middle- aligned RGMII inputs 27:26 TX_DELAY - Delay line for the GTX clock that goes along with the data 25 GIGE- Set only after a 1000 Mbps connection has been negotiated 24 OFFSET_PHASE - Used to select if the start is from the positive or negative phase (or whether to have a 180 degree change in addition to the phase-delay in [11:8]. can you try to see if only setting the bits 29:26 is enough or if any of the other bits need to be set ? if that does not work it has to be 30, 25 or 24 John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
On Wed, Dec 10, 2014 at 10:23:12AM +, Chris Green wrote: > On Wed, Dec 10, 2014 at 09:59:29AM +0100, John Crispin wrote: > > > > > > On 10/12/2014 09:29, David Hutchison wrote: > > > I am once again just guessing with 0x6f00, so I am sure this is wrong. > > > I would love to learn if you could give me insight :-) > > > > > > I would also love to make a patch for both the 951G and the rb2011 > > > (gigabit switch version). I don't have packet loss anymore! :-) > > > > nice work ! > > > > i will track down someone with a datasheet today so that we know what > > the register actually does :) > > > Excellent, I will try patching this on my RB2011 (to 0x6f00) and > see if it works for me too. > Eureka! :-) Changing the line in mach-rb2011.c from:- ath79_eth0_pll_data.pll_1000 = 0x0600; to:- ath79_eth0_pll_data.pll_1000 = 0x6f00; Fixes my rb-2011uias-2hnd as well. I now have all ten ethernet ports working, the 5 x 10/100 *and* the 5 x Gigabit. Thanks very much David. ... and I look forward to a patch with the proper value. Can test etc. as needed. I even have a faster machine I'm just starting to configure as my desktop Linux box (where I do the build) so it won't take me so long to build. -- Chris Green ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
On Wed, Dec 10, 2014 at 09:59:29AM +0100, John Crispin wrote: > > > On 10/12/2014 09:29, David Hutchison wrote: > > I am once again just guessing with 0x6f00, so I am sure this is wrong. > > I would love to learn if you could give me insight :-) > > > > I would also love to make a patch for both the 951G and the rb2011 > > (gigabit switch version). I don't have packet loss anymore! :-) > > nice work ! > > i will track down someone with a datasheet today so that we know what > the register actually does :) > Excellent, I will try patching this on my RB2011 (to 0x6f00) and see if it works for me too. -- Chris Green ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
On 10/12/2014 09:29, David Hutchison wrote: > I am once again just guessing with 0x6f00, so I am sure this is wrong. > I would love to learn if you could give me insight :-) > > I would also love to make a patch for both the 951G and the rb2011 > (gigabit switch version). I don't have packet loss anymore! :-) nice work ! i will track down someone with a datasheet today so that we know what the register actually does :) John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
I decided to try and toggle all of the bits by setting ath79_eth0_pll_data.pll_1000=0x6f00 and it seems to be flowing Ok: root@OpenWrt:/# arp -n IP address HW type Flags HW addressMask Device root@OpenWrt:/# brctl delif br-lan eth0 [ 30.20] device eth0 left promiscuous mode [ 30.20] br-lan: port 1(eth0) entered disabled state root@OpenWrt:/# ifconfig eth0 10.128.41.249 netmask 255.255.255.0 up root@OpenWrt:/# ping 10.128.41.1 PING 10.128.41.1 (10.128.41.1): 56 data bytes 64 bytes from 10.128.41.1: seq=0 ttl=64 time=1.596 ms 64 bytes from 10.128.41.1: seq=1 ttl=64 time=0.673 ms 64 bytes from 10.128.41.1: seq=2 ttl=64 time=0.603 ms 64 bytes from 10.128.41.1: seq=3 ttl=64 time=0.595 ms 64 bytes from 10.128.41.1: seq=4 ttl=64 time=0.610 ms 64 bytes from 10.128.41.1: seq=5 ttl=64 time=0.606 ms 64 bytes from 10.128.41.1: seq=6 ttl=64 time=0.628 ms 64 bytes from 10.128.41.1: seq=7 ttl=64 time=0.559 ms 64 bytes from 10.128.41.1: seq=8 ttl=64 time=0.641 ms 64 bytes from 10.128.41.1: seq=9 ttl=64 time=0.593 ms 64 bytes from 10.128.41.1: seq=10 ttl=64 time=0.603 ms 64 bytes from 10.128.41.1: seq=11 ttl=64 time=0.596 ms 64 bytes from 10.128.41.1: seq=12 ttl=64 time=0.596 ms 64 bytes from 10.128.41.1: seq=13 ttl=64 time=0.596 ms 64 bytes from 10.128.41.1: seq=14 ttl=64 time=0.642 ms 64 bytes from 10.128.41.1: seq=15 ttl=64 time=0.590 ms 64 bytes from 10.128.41.1: seq=16 ttl=64 time=0.836 ms ^C --- 10.128.41.1 ping statistics --- 17 packets transmitted, 17 packets received, 0% packet loss round-trip min/avg/max = 0.559/0.680/1.596 ms root@OpenWrt:/# arp -n IP address HW type Flags HW addressMask Device 10.128.41.1 0x1 0x2 d4:ca:6d:77:2b:3d *eth0 I am once again just guessing with 0x6f00, so I am sure this is wrong. I would love to learn if you could give me insight :-) I would also love to make a patch for both the 951G and the rb2011 (gigabit switch version). I don't have packet loss anymore! :-) -- Davey On Wed, Dec 10, 2014 at 1:00 AM, David Hutchison wrote: > Hello, > > I have made some progress narrowing down the issue. It seems the > ath79_eth0_pll_data.pll_1000 is not configured correctly. I do not > understand how to determine what the correct value should be. > Originally the mach-rb95x.c did not have any definition for this > variable. I looked at other Mikrotik architectures and found the > 750Gr3 utilized this and set it to 0x6200. When I compiled this I > noticed differences in the amount of packets I was receiving via eth0. > > Looking at more architectures it appears that other devices with an > ar8327 use 0x0600. I tried that and saw 100% packet loss, and arp > was not responding. I went ahead and *guessed* and tried 0x6600. > Now pings sporadically began to respond: > > root@OpenWrt:/# arp -n > IP address HW type Flags HW addressMask Device > 10.128.41.1 0x1 0x2 d4:ca:6d:77:2b:3d *eth0 > root@OpenWrt:/# ifconfig eth0 10.128.41.2 netmask 255.255.255.0 up > root@OpenWrt:/# ifconfig eth0 > eth0 Link encap:Ethernet HWaddr 4C:5E:0C:6D:24:43 > inet addr:10.128.41.248 Bcast:10.128.41.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:187 errors:0 dropped:0 overruns:0 frame:0 > TX packets:20 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:14785 (14.4 KiB) TX bytes:2180 (2.1 KiB) > Interrupt:4 > > root@OpenWrt:/# ping 10.128.41.1 > PING 10.128.41.1 (10.128.41.1): 56 data bytes > 64 bytes from 10.128.41.1: seq=3 ttl=64 time=1.169 ms > 64 bytes from 10.128.41.1: seq=10 ttl=64 time=0.663 ms > 64 bytes from 10.128.41.1: seq=12 ttl=64 time=1992.529 ms > 64 bytes from 10.128.41.1: seq=17 ttl=64 time=0.660 ms > 64 bytes from 10.128.41.1: seq=20 ttl=64 time=0.610 ms > 64 bytes from 10.128.41.1: seq=23 ttl=64 time=0.612 ms > 64 bytes from 10.128.41.1: seq=27 ttl=64 time=0.634 ms > 64 bytes from 10.128.41.1: seq=31 ttl=64 time=0.631 ms > 64 bytes from 10.128.41.1: seq=39 ttl=64 time=0.583 ms > ^C > --- 10.128.41.1 ping statistics --- > 40 packets transmitted, 9 packets received, 77% packet loss > round-trip min/avg/max = 0.583/222.010/1992.529 ms > > I have about 77% packet loss. > > This is improvement as originally we saw 100% packet loss and no arp. > > I looked at a patch by Gabor Juhosg ( > https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/files/arch/mips/ath79/mach-rb91x.c?rev=39642 > ) and he set the RB91x to 0x0200 > I think if we correctly configure it in mach-rb95x.c, we may solve the > problem :-) > > Could someone help me determine what the correct > ath79_eth0_pll_data.pll_1000 should be configured to? > > -- Davey > > On Mon, Dec 8, 2014 at 3:20 PM, Chris Green wrote: >> On Mon, Dec 08, 2014 at 11:13:07AM -0700, David Hutchison wrote: >>> >>> root@Ope
Re: [OpenWrt-Devel] ar934x+ar8327v4
Hello, I have made some progress narrowing down the issue. It seems the ath79_eth0_pll_data.pll_1000 is not configured correctly. I do not understand how to determine what the correct value should be. Originally the mach-rb95x.c did not have any definition for this variable. I looked at other Mikrotik architectures and found the 750Gr3 utilized this and set it to 0x6200. When I compiled this I noticed differences in the amount of packets I was receiving via eth0. Looking at more architectures it appears that other devices with an ar8327 use 0x0600. I tried that and saw 100% packet loss, and arp was not responding. I went ahead and *guessed* and tried 0x6600. Now pings sporadically began to respond: root@OpenWrt:/# arp -n IP address HW type Flags HW addressMask Device 10.128.41.1 0x1 0x2 d4:ca:6d:77:2b:3d *eth0 root@OpenWrt:/# ifconfig eth0 10.128.41.2 netmask 255.255.255.0 up root@OpenWrt:/# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 4C:5E:0C:6D:24:43 inet addr:10.128.41.248 Bcast:10.128.41.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:187 errors:0 dropped:0 overruns:0 frame:0 TX packets:20 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:14785 (14.4 KiB) TX bytes:2180 (2.1 KiB) Interrupt:4 root@OpenWrt:/# ping 10.128.41.1 PING 10.128.41.1 (10.128.41.1): 56 data bytes 64 bytes from 10.128.41.1: seq=3 ttl=64 time=1.169 ms 64 bytes from 10.128.41.1: seq=10 ttl=64 time=0.663 ms 64 bytes from 10.128.41.1: seq=12 ttl=64 time=1992.529 ms 64 bytes from 10.128.41.1: seq=17 ttl=64 time=0.660 ms 64 bytes from 10.128.41.1: seq=20 ttl=64 time=0.610 ms 64 bytes from 10.128.41.1: seq=23 ttl=64 time=0.612 ms 64 bytes from 10.128.41.1: seq=27 ttl=64 time=0.634 ms 64 bytes from 10.128.41.1: seq=31 ttl=64 time=0.631 ms 64 bytes from 10.128.41.1: seq=39 ttl=64 time=0.583 ms ^C --- 10.128.41.1 ping statistics --- 40 packets transmitted, 9 packets received, 77% packet loss round-trip min/avg/max = 0.583/222.010/1992.529 ms I have about 77% packet loss. This is improvement as originally we saw 100% packet loss and no arp. I looked at a patch by Gabor Juhosg ( https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/files/arch/mips/ath79/mach-rb91x.c?rev=39642 ) and he set the RB91x to 0x0200 I think if we correctly configure it in mach-rb95x.c, we may solve the problem :-) Could someone help me determine what the correct ath79_eth0_pll_data.pll_1000 should be configured to? -- Davey On Mon, Dec 8, 2014 at 3:20 PM, Chris Green wrote: > On Mon, Dec 08, 2014 at 11:13:07AM -0700, David Hutchison wrote: >> >> root@OpenWrt:/dev# ifconfig eth0 >> eth0 Link encap:Ethernet HWaddr 4C:5E:0C:6D:24:43 >> inet addr:10.128.41.249 Bcast:10.128.41.255 Mask:255.255.255.0 >> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >> RX packets:144 errors:0 dropped:0 overruns:0 frame:0 >> TX packets:10 errors:0 dropped:0 overruns:0 carrier:0 >> collisions:0 txqueuelen:1000 >> RX bytes:8996 (8.7 KiB) TX bytes:1292 (1.2 KiB) >> Interrupt:4 >> > If it's of any use/interest my rb-2011uias-2hnd gives the following > MAC addresses:- > > br-lanLink encap:Ethernet HWaddr 4C:5E:0C:73:87:3E > eth0 Link encap:Ethernet HWaddr 4C:5E:0C:73:87:3E > eth0.1Link encap:Ethernet HWaddr 4C:5E:0C:73:87:3E > eth0.2Link encap:Ethernet HWaddr 4C:5E:0C:73:87:3E > eth0.3Link encap:Ethernet HWaddr 4C:5E:0C:73:87:3E > eth1 Link encap:Ethernet HWaddr 4C:5E:0C:73:87:43 > > Oddly it's eth1, the 10/100 fast ethernet switch built into the > processor that works and eth0 the Gigabit switch that doesn't work. > > Running an ARP scan from another computer on the LAN shows the > mikrotik (192.168.1.40) as follows:- > > 192.168.1.40 mikrotik4C:5E:0C:73:87:3E (Unknown) > > > -- > Chris Green > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
On Mon, Dec 08, 2014 at 11:13:07AM -0700, David Hutchison wrote: > > root@OpenWrt:/dev# ifconfig eth0 > eth0 Link encap:Ethernet HWaddr 4C:5E:0C:6D:24:43 > inet addr:10.128.41.249 Bcast:10.128.41.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:144 errors:0 dropped:0 overruns:0 frame:0 > TX packets:10 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:8996 (8.7 KiB) TX bytes:1292 (1.2 KiB) > Interrupt:4 > If it's of any use/interest my rb-2011uias-2hnd gives the following MAC addresses:- br-lanLink encap:Ethernet HWaddr 4C:5E:0C:73:87:3E eth0 Link encap:Ethernet HWaddr 4C:5E:0C:73:87:3E eth0.1Link encap:Ethernet HWaddr 4C:5E:0C:73:87:3E eth0.2Link encap:Ethernet HWaddr 4C:5E:0C:73:87:3E eth0.3Link encap:Ethernet HWaddr 4C:5E:0C:73:87:3E eth1 Link encap:Ethernet HWaddr 4C:5E:0C:73:87:43 Oddly it's eth1, the 10/100 fast ethernet switch built into the processor that works and eth0 the Gigabit switch that doesn't work. Running an ARP scan from another computer on the LAN shows the mikrotik (192.168.1.40) as follows:- 192.168.1.40 mikrotik4C:5E:0C:73:87:3E (Unknown) -- Chris Green ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
Hello, I did some more poking around. I don't know if I am way off course or not, but I hope these findings trigger some ideas. Firstly, I contacted Mikrotik and actually received a response: "Hello, that patch will not help you much. However, you can try to debug your FW on RB2011 as it uses same CPU and same Gbit switch chip as RB951G-2HPnD. You have to correctly initialize MAC address of switch chip to make it work. You have to do that via driver so that switch is not forwarding packets when OS is still booting. Regards, Janis K." -- Mikrotik Support I requested access to there kernel patches, instead they gave me something to look into. Since the Routerboard 2011 and the RB951G use the same processor, I took code to expose the SPI config partitions. This way I could confirm the MAC Address was indeed the same that was inside "hard_config": Looking at "routerboot.h" I saw the "4" id inside hard_config is the RB_ID_MAC_ADDRESS_PACK. root@OpenWrt:/dev# cat /dev/mtd1 | hexdump -C 64 72 61 48 00 04 00 1a 00 00 00 00 00 08 00 04 |draH| 0010 4c 5e 0c 6d 24 43 00 00 00 04 00 0e 00 00 00 06 |L^.m$C..| That is the same MAC that is written on the board ( The bottom of the 951G has "4c 5e 0c 6d 24 43" ... "4c 5e 0c 6d 24 48" ). I then checked that MAC against eth0: root@OpenWrt:/dev# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 4C:5E:0C:6D:24:43 inet addr:10.128.41.249 Bcast:10.128.41.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:144 errors:0 dropped:0 overruns:0 frame:0 TX packets:10 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:8996 (8.7 KiB) TX bytes:1292 (1.2 KiB) Interrupt:4 It all lines up. It's obviously not a MAC initialization problem. The ag71xx driver must be working correctly since RX/TX packets are showing. Since eth0 see's packets, that must mean communication between the ar8327 + ar934x is somewhat working. I'm wondering what we are missing... -- Davey On Fri, Dec 5, 2014 at 12:39 PM, David Hutchison wrote: > Here is a test I did by setting up swconfig manually. As you can see I > put ports 1 and 2 into vlangroup 1. Traffic from port 2 can ping > 10.128.41.1 which is a device on port 1. However eth0.1 which as > address 10.128.41.249 cannot ping 10.128.41.1 device on port 1. > Attached is the swconfig setup, and a dmesg. > > Here is the arp result as well: > root@OpenWrt:/# arp -n > IP address HW type Flags HW addressMask Device > 10.128.41.1 0x1 0x0 00:00:00:00:00:00 *eth0.1 > > I used to be able to do: > root@OpenWrt:/# swconfig dev eth0 show > Failed to connect to the switch > root@OpenWrt:/# swconfig list > Found: switch0 - ag71xx-mdio.0 > > Do you not think this is an issue with ag71xx? Do you it is something > in user-space? > > On Fri, Dec 5, 2014 at 12:18 PM, David Hutchison > wrote: >> I am using a very simple test setup with no vlans for now: >> >> root@OpenWrt:/# cat /etc/config/network >> >> config interface 'loopback' >> option ifname 'lo' >> option proto 'static' >> option ipaddr '127.0.0.1' >> option netmask '255.0.0.0' >> >> config globals 'globals' >> option ula_prefix 'fd26:7dae:48cb::/48' >> >> config interface 'lan' >> option ifname 'eth0' >> option type 'bridge' >> option proto 'static' >> option ipaddr '192.168.1.1' >> option netmask '255.255.255.0' >> option ip6assign '60' >> >> root@OpenWrt:/# swconfig dev switch0 show >> Global attributes: >> enable_vlan: 0 >> enable_mirror_rx: 0 >> enable_mirror_tx: 0 >> mirror_monitor_port: 0 >> mirror_source_port: 0 >> Port 0: >> mib: Port 0 MIB counters >> RxBroad : 5 >> RxPause : 0 >> RxMulti : 6 >> RxFcsErr: 0 >> RxAlignErr : 0 >> RxRunt : 0 >> RxFragment : 0 >> Rx64Byte: 0 >> Rx128Byte : 3252 >> Rx256Byte : 3 >> Rx512Byte : 4 >> Rx1024Byte : 0 >> Rx1518Byte : 0 >> RxMaxByte : 0 >> RxTooLong : 0 >> RxGoodByte : 223169 >> RxBadByte : 0 >> RxOverFlow : 0 >> Filtered: 0 >> TxBroad : 151 >> TxPause : 0 >> TxMulti : 324 >> TxUnderRun : 0 >> Tx64Byte: 208 >> Tx128Byte : 93 >> Tx256Byte : 99 >> Tx512Byte : 57 >> Tx1024Byte : 12 >> Tx1518Byte : 3260 >> TxMaxByte : 0 >> TxOverSize : 0 >> TxByte : 4960741 >> TxCollision : 0 >> TxAbortCol : 0 >> TxMultiCol : 0 >> TxSingleCol : 0 >> TxExcDefer : 0 >> TxDefer : 0 >> TxLateCol : 0 >> >> pvid: 0 >> link: port:0 link:up speed:1000baseT full-duplex txflow rxflow >> Port 1: >> mib: Port 1 MIB counters >> RxBroad : 151 >> RxPause : 0 >> RxMulti : 324 >> RxFcsErr: 0 >> RxAlignErr : 0 >> RxRunt : 0 >> RxFragment : 0 >> Rx64Byte: 208 >> Rx128Byte : 93 >> Rx256Byte :
Re: [OpenWrt-Devel] ar934x+ar8327v4
On Sat, Dec 06, 2014 at 08:58:05AM -0500, Soren Harward wrote: >On Dec 6, 2014 5:15 AM, "Chris Green" <[1]c...@isbd.net> wrote: >> >> To indicate that the problem is definitely something to do with eth0 >> not being 'hooked up' properly see the following:- >> >> root@OpenWrt:~# swconfig dev eth0 show >> Failed to connect to the switch. Use the "list" command to see >which >> switches are available. > >Mine does the same thing, and yet the giga switch passes traffic just >fine. Also, "swconfig dev switch0 show" works totally fine. The >switch name weirdness probably isn't the root of the problem. > Oh well, maybe it's related somehow though. -- Chris Green ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
On Dec 6, 2014 5:15 AM, "Chris Green" wrote: > > To indicate that the problem is definitely something to do with eth0 > not being 'hooked up' properly see the following:- > > root@OpenWrt:~# swconfig dev eth0 show > Failed to connect to the switch. Use the "list" command to see which > switches are available. Mine does the same thing, and yet the giga switch passes traffic just fine. Also, "swconfig dev switch0 show" works totally fine. The switch name weirdness probably isn't the root of the problem. -- Soren Harward stharw...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
To indicate that the problem is definitely something to do with eth0 not being 'hooked up' properly see the following:- root@OpenWrt:~# swconfig dev eth0 show Failed to connect to the switch. Use the "list" command to see which switches are available. root@OpenWrt:~# swconfig dev eth1 show Global attributes: enable_vlan: 1 Port 0: pvid: 1 link: port:0 link:up speed:1000baseT full-duplex txflow rxflow Port 1: pvid: 1 link: port:1 link:down Port 2: pvid: 1 link: port:2 link:down Port 3: pvid: 1 link: port:3 link:up speed:100baseT full-duplex auto Port 4: pvid: 1 link: port:4 link:down Port 5: pvid: 1 link: port:5 link:down VLAN 1: vid: 1 ports: 0 1 2 3 4 5 root@OpenWrt:~# This is on my RB2011 where eth0 is (should be) the 5 port Gigabit switch and eth1 is the 5 port fast (10/100) ethernet switch. -- Chris Green ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
On Fri, Dec 05, 2014 at 11:18:10PM -0500, Soren Harward wrote: > On Fri, Dec 5, 2014 at 5:21 AM, Chris Green wrote: > > Some people with the RB2011 (other incarnations but presumably > > basically the same) have it working OK. > > I'm one of those that has a working RB2011; it's currently running > r41293 with my RB2011UiAS patch ( > http://patchwork.openwrt.org/patch/5841/ ). Unfortunately, it's > working so well that I can't mess around with it at the moment. If > John can't track down the problem with his RB2011 in the next few > weeks, I can take a day before New Years, pull my RB2011 out of > production, upgrade it to trunk, and see what happens. That will at > least tell us whether it's a software or hardware problem. > Thanks, that sounds a good idea if we don't get anywhere before then. -- Chris Green ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
On Fri, Dec 5, 2014 at 5:21 AM, Chris Green wrote: > Some people with the RB2011 (other incarnations but presumably > basically the same) have it working OK. I'm one of those that has a working RB2011; it's currently running r41293 with my RB2011UiAS patch ( http://patchwork.openwrt.org/patch/5841/ ). Unfortunately, it's working so well that I can't mess around with it at the moment. If John can't track down the problem with his RB2011 in the next few weeks, I can take a day before New Years, pull my RB2011 out of production, upgrade it to trunk, and see what happens. That will at least tell us whether it's a software or hardware problem. -- Soren Harward ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
On Fri, Dec 05, 2014 at 12:39:16PM -0700, David Hutchison wrote: > Here is a test I did by setting up swconfig manually. As you can see I > put ports 1 and 2 into vlangroup 1. Traffic from port 2 can ping > 10.128.41.1 which is a device on port 1. However eth0.1 which as > address 10.128.41.249 cannot ping 10.128.41.1 device on port 1. > Attached is the swconfig setup, and a dmesg. > > Here is the arp result as well: > root@OpenWrt:/# arp -n > IP address HW type Flags HW addressMask Device > 10.128.41.1 0x1 0x0 00:00:00:00:00:00 *eth0.1 > > I used to be able to do: > root@OpenWrt:/# swconfig dev eth0 show > Failed to connect to the switch > root@OpenWrt:/# swconfig list > Found: switch0 - ag71xx-mdio.0 > > Do you not think this is an issue with ag71xx? Do you it is something > in user-space? > Same on mine (except I have an eth1 which is the 10/100 that works OK):- root@OpenWrt:~# swconfig dev eth0 show Failed to connect to the switch. Use the "list" command to see which switches are available. root@OpenWrt:~# swconfig list Found: switch0 - ag71xx-mdio.0 Found: switch1 - eth1 root@OpenWrt:~# -- Chris Green ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
Here is a test I did by setting up swconfig manually. As you can see I put ports 1 and 2 into vlangroup 1. Traffic from port 2 can ping 10.128.41.1 which is a device on port 1. However eth0.1 which as address 10.128.41.249 cannot ping 10.128.41.1 device on port 1. Attached is the swconfig setup, and a dmesg. Here is the arp result as well: root@OpenWrt:/# arp -n IP address HW type Flags HW addressMask Device 10.128.41.1 0x1 0x0 00:00:00:00:00:00 *eth0.1 I used to be able to do: root@OpenWrt:/# swconfig dev eth0 show Failed to connect to the switch root@OpenWrt:/# swconfig list Found: switch0 - ag71xx-mdio.0 Do you not think this is an issue with ag71xx? Do you it is something in user-space? On Fri, Dec 5, 2014 at 12:18 PM, David Hutchison wrote: > I am using a very simple test setup with no vlans for now: > > root@OpenWrt:/# cat /etc/config/network > > config interface 'loopback' > option ifname 'lo' > option proto 'static' > option ipaddr '127.0.0.1' > option netmask '255.0.0.0' > > config globals 'globals' > option ula_prefix 'fd26:7dae:48cb::/48' > > config interface 'lan' > option ifname 'eth0' > option type 'bridge' > option proto 'static' > option ipaddr '192.168.1.1' > option netmask '255.255.255.0' > option ip6assign '60' > > root@OpenWrt:/# swconfig dev switch0 show > Global attributes: > enable_vlan: 0 > enable_mirror_rx: 0 > enable_mirror_tx: 0 > mirror_monitor_port: 0 > mirror_source_port: 0 > Port 0: > mib: Port 0 MIB counters > RxBroad : 5 > RxPause : 0 > RxMulti : 6 > RxFcsErr: 0 > RxAlignErr : 0 > RxRunt : 0 > RxFragment : 0 > Rx64Byte: 0 > Rx128Byte : 3252 > Rx256Byte : 3 > Rx512Byte : 4 > Rx1024Byte : 0 > Rx1518Byte : 0 > RxMaxByte : 0 > RxTooLong : 0 > RxGoodByte : 223169 > RxBadByte : 0 > RxOverFlow : 0 > Filtered: 0 > TxBroad : 151 > TxPause : 0 > TxMulti : 324 > TxUnderRun : 0 > Tx64Byte: 208 > Tx128Byte : 93 > Tx256Byte : 99 > Tx512Byte : 57 > Tx1024Byte : 12 > Tx1518Byte : 3260 > TxMaxByte : 0 > TxOverSize : 0 > TxByte : 4960741 > TxCollision : 0 > TxAbortCol : 0 > TxMultiCol : 0 > TxSingleCol : 0 > TxExcDefer : 0 > TxDefer : 0 > TxLateCol : 0 > > pvid: 0 > link: port:0 link:up speed:1000baseT full-duplex txflow rxflow > Port 1: > mib: Port 1 MIB counters > RxBroad : 151 > RxPause : 0 > RxMulti : 324 > RxFcsErr: 0 > RxAlignErr : 0 > RxRunt : 0 > RxFragment : 0 > Rx64Byte: 208 > Rx128Byte : 93 > Rx256Byte : 99 > Rx512Byte : 57 > Rx1024Byte : 12 > Rx1518Byte : 3260 > RxMaxByte : 0 > RxTooLong : 0 > RxGoodByte : 4960741 > RxBadByte : 0 > RxOverFlow : 0 > Filtered: 0 > TxBroad : 5 > TxPause : 0 > TxMulti : 6 > TxUnderRun : 0 > Tx64Byte: 0 > Tx128Byte : 3252 > Tx256Byte : 3 > Tx512Byte : 4 > Tx1024Byte : 0 > Tx1518Byte : 0 > TxMaxByte : 0 > TxOverSize : 0 > TxByte : 223169 > TxCollision : 0 > TxAbortCol : 0 > TxMultiCol : 0 > TxSingleCol : 0 > TxExcDefer : 0 > TxDefer : 0 > TxLateCol : 0 > > pvid: 0 > link: port:1 link:up speed:1000baseT full-duplex auto > Port 2: > mib: Port 2 MIB counters > RxBroad : 0 > RxPause : 0 > RxMulti : 0 > RxFcsErr: 0 > RxAlignErr : 0 > RxRunt : 0 > RxFragment : 0 > Rx64Byte: 0 > Rx128Byte : 0 > Rx256Byte : 0 > Rx512Byte : 0 > Rx1024Byte : 0 > Rx1518Byte : 0 > RxMaxByte : 0 > RxTooLong : 0 > RxGoodByte : 0 > RxBadByte : 0 > RxOverFlow : 0 > Filtered: 0 > TxBroad : 0 > TxPause : 0 > TxMulti : 0 > TxUnderRun : 0 > Tx64Byte: 0 > Tx128Byte : 0 > Tx256Byte : 0 > Tx512Byte : 0 > Tx1024Byte : 0 > Tx1518Byte : 0 > TxMaxByte : 0 > TxOverSize : 0 > TxByte : 0 > TxCollision : 0 > TxAbortCol : 0 > TxMultiCol : 0 > TxSingleCol : 0 > TxExcDefer : 0 > TxDefer : 0 > TxLateCol : 0 > > pvid: 0 > link: port:2 link:down > Port 3: > mib: Port 3 MIB counters > RxBroad : 0 > RxPause : 0 > RxMulti : 0 > RxFcsErr: 0 > RxAlignErr : 0 > RxRunt : 0 > RxFragment : 0 > Rx64Byte: 0 > Rx128Byte : 0 > Rx256Byte : 0 > Rx512Byte : 0 > Rx1024Byte : 0 > Rx1518Byte : 0 > RxMaxByte : 0 > RxTooLong : 0 > RxGoodByte : 0 > RxBadByte : 0 > RxOverFlow : 0 > Filtered: 0 > TxBroad : 0 > TxPause : 0 > TxMulti : 0 > TxUnderRun : 0 > Tx64Byte: 0 > Tx128Byte : 0 > Tx256Byte : 0 > Tx512Byte : 0 > Tx1024Byte : 0 > Tx1518Byte : 0 > TxMaxByte : 0 > TxOverSize : 0 > TxByte : 0 > TxCollision : 0 > TxAbortCol : 0 > TxMultiCol : 0 > TxSingleCol : 0 > TxExcDefer : 0 > TxDefer : 0 > TxLateCol : 0 > > pvid: 0 > link: port:3 link:down > Port 4: > mib: Port 4 MIB counters > Rx
Re: [OpenWrt-Devel] ar934x+ar8327v4
I am using a very simple test setup with no vlans for now: root@OpenWrt:/# cat /etc/config/network config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config globals 'globals' option ula_prefix 'fd26:7dae:48cb::/48' config interface 'lan' option ifname 'eth0' option type 'bridge' option proto 'static' option ipaddr '192.168.1.1' option netmask '255.255.255.0' option ip6assign '60' root@OpenWrt:/# swconfig dev switch0 show Global attributes: enable_vlan: 0 enable_mirror_rx: 0 enable_mirror_tx: 0 mirror_monitor_port: 0 mirror_source_port: 0 Port 0: mib: Port 0 MIB counters RxBroad : 5 RxPause : 0 RxMulti : 6 RxFcsErr: 0 RxAlignErr : 0 RxRunt : 0 RxFragment : 0 Rx64Byte: 0 Rx128Byte : 3252 Rx256Byte : 3 Rx512Byte : 4 Rx1024Byte : 0 Rx1518Byte : 0 RxMaxByte : 0 RxTooLong : 0 RxGoodByte : 223169 RxBadByte : 0 RxOverFlow : 0 Filtered: 0 TxBroad : 151 TxPause : 0 TxMulti : 324 TxUnderRun : 0 Tx64Byte: 208 Tx128Byte : 93 Tx256Byte : 99 Tx512Byte : 57 Tx1024Byte : 12 Tx1518Byte : 3260 TxMaxByte : 0 TxOverSize : 0 TxByte : 4960741 TxCollision : 0 TxAbortCol : 0 TxMultiCol : 0 TxSingleCol : 0 TxExcDefer : 0 TxDefer : 0 TxLateCol : 0 pvid: 0 link: port:0 link:up speed:1000baseT full-duplex txflow rxflow Port 1: mib: Port 1 MIB counters RxBroad : 151 RxPause : 0 RxMulti : 324 RxFcsErr: 0 RxAlignErr : 0 RxRunt : 0 RxFragment : 0 Rx64Byte: 208 Rx128Byte : 93 Rx256Byte : 99 Rx512Byte : 57 Rx1024Byte : 12 Rx1518Byte : 3260 RxMaxByte : 0 RxTooLong : 0 RxGoodByte : 4960741 RxBadByte : 0 RxOverFlow : 0 Filtered: 0 TxBroad : 5 TxPause : 0 TxMulti : 6 TxUnderRun : 0 Tx64Byte: 0 Tx128Byte : 3252 Tx256Byte : 3 Tx512Byte : 4 Tx1024Byte : 0 Tx1518Byte : 0 TxMaxByte : 0 TxOverSize : 0 TxByte : 223169 TxCollision : 0 TxAbortCol : 0 TxMultiCol : 0 TxSingleCol : 0 TxExcDefer : 0 TxDefer : 0 TxLateCol : 0 pvid: 0 link: port:1 link:up speed:1000baseT full-duplex auto Port 2: mib: Port 2 MIB counters RxBroad : 0 RxPause : 0 RxMulti : 0 RxFcsErr: 0 RxAlignErr : 0 RxRunt : 0 RxFragment : 0 Rx64Byte: 0 Rx128Byte : 0 Rx256Byte : 0 Rx512Byte : 0 Rx1024Byte : 0 Rx1518Byte : 0 RxMaxByte : 0 RxTooLong : 0 RxGoodByte : 0 RxBadByte : 0 RxOverFlow : 0 Filtered: 0 TxBroad : 0 TxPause : 0 TxMulti : 0 TxUnderRun : 0 Tx64Byte: 0 Tx128Byte : 0 Tx256Byte : 0 Tx512Byte : 0 Tx1024Byte : 0 Tx1518Byte : 0 TxMaxByte : 0 TxOverSize : 0 TxByte : 0 TxCollision : 0 TxAbortCol : 0 TxMultiCol : 0 TxSingleCol : 0 TxExcDefer : 0 TxDefer : 0 TxLateCol : 0 pvid: 0 link: port:2 link:down Port 3: mib: Port 3 MIB counters RxBroad : 0 RxPause : 0 RxMulti : 0 RxFcsErr: 0 RxAlignErr : 0 RxRunt : 0 RxFragment : 0 Rx64Byte: 0 Rx128Byte : 0 Rx256Byte : 0 Rx512Byte : 0 Rx1024Byte : 0 Rx1518Byte : 0 RxMaxByte : 0 RxTooLong : 0 RxGoodByte : 0 RxBadByte : 0 RxOverFlow : 0 Filtered: 0 TxBroad : 0 TxPause : 0 TxMulti : 0 TxUnderRun : 0 Tx64Byte: 0 Tx128Byte : 0 Tx256Byte : 0 Tx512Byte : 0 Tx1024Byte : 0 Tx1518Byte : 0 TxMaxByte : 0 TxOverSize : 0 TxByte : 0 TxCollision : 0 TxAbortCol : 0 TxMultiCol : 0 TxSingleCol : 0 TxExcDefer : 0 TxDefer : 0 TxLateCol : 0 pvid: 0 link: port:3 link:down Port 4: mib: Port 4 MIB counters RxBroad : 0 RxPause : 0 RxMulti : 0 RxFcsErr: 0 RxAlignErr : 0 RxRunt : 0 RxFragment : 0 Rx64Byte: 0 Rx128Byte : 0 Rx256Byte : 0 Rx512Byte : 0 Rx1024Byte : 0 Rx1518Byte : 0 RxMaxByte : 0 RxTooLong : 0 RxGoodByte : 0 RxBadByte : 0 RxOverFlow : 0 Filtered: 0 TxBroad : 0 TxPause : 0 TxMulti : 0 TxUnderRun : 0 Tx64Byte: 0 Tx128Byte : 0 Tx256Byte : 0 Tx512Byte : 0 Tx1024Byte : 0 Tx1518Byte : 0 TxMaxByte : 0 TxOverSize : 0 TxByte : 0 TxCollision : 0 TxAbortCol : 0 TxMultiCol : 0 TxSingleCol : 0 TxExcDefer : 0 TxDefer : 0 TxLateCol : 0 pvid: 0 link: port:4 link:down Port 5: mib: Port 5 MIB counters RxBroad : 0 RxPause : 0 RxMulti : 0 RxFcsErr: 0 RxAlignErr : 0 RxRunt : 0 RxFragment : 0 Rx64Byte: 0 Rx128Byte : 0 Rx256Byte : 0 Rx512Byte : 0 Rx1024Byte : 0 Rx1518Byte : 0 RxMaxByte : 0 RxTooLong : 0 RxGoodByte : 0 RxBadByte : 0 RxOverFlow : 0 Filtered: 0 TxBroad : 0 TxPause : 0 TxMulti : 0 TxUnderRun : 0 Tx64Byte: 0 Tx128Byte : 0 Tx256Byte : 0 Tx512Byte : 0 Tx1024Byte : 0 Tx1518Byte : 0 TxMaxByte : 0 TxOverSize : 0 TxByte : 0 TxCollis
Re: [OpenWrt-Devel] ar934x+ar8327v4
On Fri, Dec 05, 2014 at 05:37:31PM +0100, Felix Fietkau wrote: > On 2014-12-05 17:15, David Hutchison wrote: > > > > The other thing to note ( and i'm not sure if this is by design ).. I > > used to be able to do "swconfig dev eth0 show" and show the switch the > > eth0 was connected to. Now I must use "swconfig dev switch0 show" to > > configure the switch. When you do "swconfig dev eth0 show" it says it > > Failed to connect to the switch. In the past, I have always used eth0 > > to configure the switch however that may have been incorrect. > Please post your network/switch configuration, and the output of > swconfig dev switch0 show > Just to join in the fun here's my results (from rb-2011uias-2hnd) attached. -- Chris Green root@OpenWrt:/# swconfig dev switch0 show Global attributes: enable_vlan: 1 enable_mirror_rx: 0 enable_mirror_tx: 0 mirror_monitor_port: 0 mirror_source_port: 0 Port 0: mib: Port 0 MIB counters RxBroad : 459787 RxPause : 0 RxMulti : 26183 RxFcsErr: 0 RxAlignErr : 0 RxRunt : 0 RxFragment : 0 Rx64Byte: 7557 Rx128Byte : 145114 Rx256Byte : 12418 Rx512Byte : 320892 Rx1024Byte : 6 Rx1518Byte : 4 RxMaxByte : 0 RxTooLong : 0 RxGoodByte : 125498098 RxBadByte : 0 RxOverFlow : 0 Filtered: 485983 TxBroad : 1 TxPause : 0 TxMulti : 12 TxUnderRun : 0 Tx64Byte: 0 Tx128Byte : 1 Tx256Byte : 0 Tx512Byte : 12 Tx1024Byte : 0 Tx1518Byte : 0 TxMaxByte : 0 TxOverSize : 0 TxByte : 4694 TxCollision : 0 TxAbortCol : 0 TxMultiCol : 0 TxSingleCol : 0 TxExcDefer : 0 TxDefer : 0 TxLateCol : 0 pvid: 0 link: port:0 link:up speed:1000baseT full-duplex txflow rxflow Port 1: mib: Port 1 MIB counters RxBroad : 0 RxPause : 0 RxMulti : 0 RxFcsErr: 0 RxAlignErr : 0 RxRunt : 0 RxFragment : 0 Rx64Byte: 0 Rx128Byte : 0 Rx256Byte : 0 Rx512Byte : 0 Rx1024Byte : 0 Rx1518Byte : 0 RxMaxByte : 0 RxTooLong : 0 RxGoodByte : 0 RxBadByte : 0 RxOverFlow : 0 Filtered: 0 TxBroad : 0 TxPause : 0 TxMulti : 0 TxUnderRun : 0 Tx64Byte: 0 Tx128Byte : 0 Tx256Byte : 0 Tx512Byte : 0 Tx1024Byte : 0 Tx1518Byte : 0 TxMaxByte : 0 TxOverSize : 0 TxByte : 0 TxCollision : 0 TxAbortCol : 0 TxMultiCol : 0 TxSingleCol : 0 TxExcDefer : 0 TxDefer : 0 TxLateCol : 0 pvid: 2 link: port:1 link:down Port 2: mib: Port 2 MIB counters RxBroad : 0 RxPause : 0 RxMulti : 0 RxFcsErr: 0 RxAlignErr : 0 RxRunt : 0 RxFragment : 0 Rx64Byte: 0 Rx128Byte : 0 Rx256Byte : 0 Rx512Byte : 0 Rx1024Byte : 0 Rx1518Byte : 0 RxMaxByte : 0 RxTooLong : 0 RxGoodByte : 0 RxBadByte : 0 RxOverFlow : 0 Filtered: 0 TxBroad : 0 TxPause : 0 TxMulti : 0 TxUnderRun : 0 Tx64Byte: 0 Tx128Byte : 0 Tx256Byte : 0 Tx512Byte : 0 Tx1024Byte : 0 Tx1518Byte : 0 TxMaxByte : 0 TxOverSize : 0 TxByte : 0 TxCollision : 0 TxAbortCol : 0 TxMultiCol : 0 TxSingleCol : 0 TxExcDefer : 0 TxDefer : 0 TxLateCol : 0 pvid: 1 link: port:2 link:down Port 3: mib: Port 3 MIB counters RxBroad : 0 RxPause : 0 RxMulti : 0 RxFcsErr: 0 RxAlignErr : 0 RxRunt : 0 RxFragment : 0 Rx64Byte: 0 Rx128Byte : 0 Rx256Byte : 0 Rx512Byte : 0 Rx1024Byte : 0 Rx1518Byte : 0 RxMaxByte : 0 RxTooLong : 0 RxGoodByte : 0 RxBadByte : 0 RxOverFlow : 0 Filtered: 0 TxBroad : 0 TxPause : 0 TxMulti : 0 TxUnderRun : 0 Tx64Byte: 0 Tx128Byte : 0 Tx256Byte : 0 Tx512Byte : 0 Tx1024Byte : 0 Tx1518Byte : 0 TxMaxByte : 0 TxOverSize : 0 TxByte : 0 TxCollision : 0 TxAbortCol : 0 TxMultiCol : 0 TxSingleCol : 0 TxExcDefer : 0 TxDefer : 0 TxLateCol : 0 pvid: 1 link: port:3 link:down Port 4: mib: Port 4 MIB counters RxBroad : 1 RxPause : 0 RxMulti : 12 RxFcsErr: 0 RxAlignErr : 0 RxRunt : 0 RxFragment : 0 Rx64Byte: 1 Rx128Byte : 0 Rx256Byte : 0 Rx512Byte : 12 Rx1024Byte : 0 Rx1518Byte : 0 RxMaxByte : 0 RxTooLong : 0 RxGoodByte : 4642 RxBadByte : 0 RxOverFlow : 0 Filtered: 0 TxBroad : 0 TxPause : 0 TxMulti : 0 TxUnderRun : 0 Tx64Byte: 0 Tx128Byte : 0 Tx256Byte : 0 Tx512Byte : 0 Tx1024Byte : 0 Tx1518Byte : 0 TxMaxByte : 0 TxOverSize : 0 TxByte : 0 TxCollision : 0 TxAbortCol : 0 TxMultiCol : 0 TxSingleCol : 0 TxExcDefer : 0 TxDefer : 0 TxLateCol : 0 pvid: 1 link: port:4 link:down Port 5: mib: Port 5 MIB counters RxBroad : 0 RxPause : 0 RxMulti : 0 RxFcsErr: 0 RxAlignErr : 0 RxRunt : 0 RxFragment : 0 Rx64Byte: 0 Rx128Byte : 0 Rx256Byte : 0 Rx512Byte : 0 Rx1024Byte : 0 Rx1518Byte : 0 RxMaxByte : 0 RxTooLong : 0 RxGoodByte : 0 RxBadByte : 0 RxOverFlow : 0 Filtered: 0 TxBroad : 0 TxPause : 0 TxMulti : 0 TxUnder
Re: [OpenWrt-Devel] ar934x+ar8327v4
On 2014-12-05 17:15, David Hutchison wrote: > Hello, > > Yes the problem remains when enable_vlan is set to 0 > > I don't think it's related to your changes either. I synced with trunk > in hope that your changes made a difference with my problem. However > that does not seem to be the case. > > I was hoping someone could point me in the right direction. Does this > sound more like an issue with ag71xx since that is what exposes the > "eth0" interface? Could it be as simple as the switch just isn't > recognized? Perhaps the switch interconnect is no longer RGMII and > should be GMII? > > If I knew where in those drivers to start looking, I could probably > help fix this problem. I enjoy tinkering with the drivers, and > learning how to fix them :) > > I was hoping you had some knowledge about how the interface becomes > tied with the switch itself, and if there were any specifics for the > ar8327 that must be set before the communication between the CPU + > Switch Chip can happen. > > Felix, would you by chance have any ideas as to what to check next? > The switch0 interface works fine, the eth0 interface tied to the > switch. Does not. > > The other thing to note ( and i'm not sure if this is by design ).. I > used to be able to do "swconfig dev eth0 show" and show the switch the > eth0 was connected to. Now I must use "swconfig dev switch0 show" to > configure the switch. When you do "swconfig dev eth0 show" it says it > Failed to connect to the switch. In the past, I have always used eth0 > to configure the switch however that may have been incorrect. Please post your network/switch configuration, and the output of swconfig dev switch0 show - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
I meant to say Could it be as simple as the switch just isn't fully initialized? instead of *recognized*... the ar8216 driver definitely recognizes it properly, and exposes the switch0 interface. I was thinking perhaps something else had to happen during init for the "eth0" interface. -- Davey On Fri, Dec 5, 2014 at 9:15 AM, David Hutchison wrote: > Hello, > > Yes the problem remains when enable_vlan is set to 0 > > I don't think it's related to your changes either. I synced with trunk > in hope that your changes made a difference with my problem. However > that does not seem to be the case. > > I was hoping someone could point me in the right direction. Does this > sound more like an issue with ag71xx since that is what exposes the > "eth0" interface? Could it be as simple as the switch just isn't > recognized? Perhaps the switch interconnect is no longer RGMII and > should be GMII? > > If I knew where in those drivers to start looking, I could probably > help fix this problem. I enjoy tinkering with the drivers, and > learning how to fix them :) > > I was hoping you had some knowledge about how the interface becomes > tied with the switch itself, and if there were any specifics for the > ar8327 that must be set before the communication between the CPU + > Switch Chip can happen. > > Felix, would you by chance have any ideas as to what to check next? > The switch0 interface works fine, the eth0 interface tied to the > switch. Does not. > > The other thing to note ( and i'm not sure if this is by design ).. I > used to be able to do "swconfig dev eth0 show" and show the switch the > eth0 was connected to. Now I must use "swconfig dev switch0 show" to > configure the switch. When you do "swconfig dev eth0 show" it says it > Failed to connect to the switch. In the past, I have always used eth0 > to configure the switch however that may have been incorrect. > > -- Davey > > On Thu, Dec 4, 2014 at 11:57 PM, Heiner Kallweit wrote: >> Am 05.12.2014 um 06:13 schrieb David Hutchison: >>> Hi, >>> >>> I ran into an issue with the Mikrotik Routerboard 951G's switch chip. >>> The new batch that we received use an updated ar8327 switch chip. The >>> switch chip would not function properly so I decided to load trunk and >>> utilize your patches. >>> >>> dmesg shows the following: >>> >>> switch0: Atheros AR8327 rev. 4 switch registered on ag71xx-mdio.0 >>> libphy: ag71xx_mdio: probed >>> eth0: Atheros AG71xx at 0xb900, irq 4, mode:RGMII >>> ag71xx ag71xx.0 eth0: connected to PHY at ag71xx-mdio.0:00 >>> [uid=004dd034, driver=Atheros AR8216/AR8236/AR8316] >>> >>> It appears the updated ar8216.c with your changes have successfully >>> initialized the chip. In fact I can even use "swconfig dev switch0" to >>> create vlans etc. >>> >>> If I create a port vlan ( eg. put ports 1 - 2 in vlan 1 ). I can plug >>> ethernet cables into each port and push data from port 1 to port 2 >>> etc. It appears the switch driver is working correctly. >>> >>> What is broken is the interface handle "eth0". It exposes eth0 and >>> ties it to the switch correctly ( as you can see from the above dmesg >>> output ). I then assign an IP address to eth0, however when I try to >>> ping a device connected to the switch. I get no response. There is no >>> arp traffic either. It's like data from the "eth0" handle doesn't know >>> how to route through the switch. >>> >>> It appears like the switch hardware is working ( since port 1 can >>> communicate to port 2 ). However when "eth0" attempts to communicate >>> to a device on port 1, it doesn't work. The device on port 1 cannot >>> communicate with the "eth0" interface either. >>> >>> I think your patches are specifically for the switch only. If that's >>> the case, then they are working. However, with your knowledge of >>> ar8327 could you point me into the direction of fixing the "eth0" >>> interface communicating to the ar8327 switch properly? Is there >>> something in ag71xx that I should be looking at? Could the ar8327 >>> switch not be initializing properly? The probe is definitely finding >>> *AR8327* so that seems to be OK. I am guessing this is something >>> specific with the ar924x CPU + ar8327 switch chip. I'm open to any >>> suggestions :-) >>> >>> -- Davey >> The recent changes to the AR8216 driver are mainly cleanups with >> no functional change. Also your dmesg output looks good. >> So at a first glance I don't think it's something with the driver. >> >> At first your /etc/config/network would be helpful. >> >> Does your problem also happen if vlans are switched off >> (enable_vlan set to 0) ? >> >> Heiner >> ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
Hello, Yes the problem remains when enable_vlan is set to 0 I don't think it's related to your changes either. I synced with trunk in hope that your changes made a difference with my problem. However that does not seem to be the case. I was hoping someone could point me in the right direction. Does this sound more like an issue with ag71xx since that is what exposes the "eth0" interface? Could it be as simple as the switch just isn't recognized? Perhaps the switch interconnect is no longer RGMII and should be GMII? If I knew where in those drivers to start looking, I could probably help fix this problem. I enjoy tinkering with the drivers, and learning how to fix them :) I was hoping you had some knowledge about how the interface becomes tied with the switch itself, and if there were any specifics for the ar8327 that must be set before the communication between the CPU + Switch Chip can happen. Felix, would you by chance have any ideas as to what to check next? The switch0 interface works fine, the eth0 interface tied to the switch. Does not. The other thing to note ( and i'm not sure if this is by design ).. I used to be able to do "swconfig dev eth0 show" and show the switch the eth0 was connected to. Now I must use "swconfig dev switch0 show" to configure the switch. When you do "swconfig dev eth0 show" it says it Failed to connect to the switch. In the past, I have always used eth0 to configure the switch however that may have been incorrect. -- Davey On Thu, Dec 4, 2014 at 11:57 PM, Heiner Kallweit wrote: > Am 05.12.2014 um 06:13 schrieb David Hutchison: >> Hi, >> >> I ran into an issue with the Mikrotik Routerboard 951G's switch chip. >> The new batch that we received use an updated ar8327 switch chip. The >> switch chip would not function properly so I decided to load trunk and >> utilize your patches. >> >> dmesg shows the following: >> >> switch0: Atheros AR8327 rev. 4 switch registered on ag71xx-mdio.0 >> libphy: ag71xx_mdio: probed >> eth0: Atheros AG71xx at 0xb900, irq 4, mode:RGMII >> ag71xx ag71xx.0 eth0: connected to PHY at ag71xx-mdio.0:00 >> [uid=004dd034, driver=Atheros AR8216/AR8236/AR8316] >> >> It appears the updated ar8216.c with your changes have successfully >> initialized the chip. In fact I can even use "swconfig dev switch0" to >> create vlans etc. >> >> If I create a port vlan ( eg. put ports 1 - 2 in vlan 1 ). I can plug >> ethernet cables into each port and push data from port 1 to port 2 >> etc. It appears the switch driver is working correctly. >> >> What is broken is the interface handle "eth0". It exposes eth0 and >> ties it to the switch correctly ( as you can see from the above dmesg >> output ). I then assign an IP address to eth0, however when I try to >> ping a device connected to the switch. I get no response. There is no >> arp traffic either. It's like data from the "eth0" handle doesn't know >> how to route through the switch. >> >> It appears like the switch hardware is working ( since port 1 can >> communicate to port 2 ). However when "eth0" attempts to communicate >> to a device on port 1, it doesn't work. The device on port 1 cannot >> communicate with the "eth0" interface either. >> >> I think your patches are specifically for the switch only. If that's >> the case, then they are working. However, with your knowledge of >> ar8327 could you point me into the direction of fixing the "eth0" >> interface communicating to the ar8327 switch properly? Is there >> something in ag71xx that I should be looking at? Could the ar8327 >> switch not be initializing properly? The probe is definitely finding >> *AR8327* so that seems to be OK. I am guessing this is something >> specific with the ar924x CPU + ar8327 switch chip. I'm open to any >> suggestions :-) >> >> -- Davey > The recent changes to the AR8216 driver are mainly cleanups with > no functional change. Also your dmesg output looks good. > So at a first glance I don't think it's something with the driver. > > At first your /etc/config/network would be helpful. > > Does your problem also happen if vlans are switched off > (enable_vlan set to 0) ? > > Heiner > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
On Fri, Dec 05, 2014 at 10:59:11AM +0100, Heiner Kallweit wrote: > On Fri, Dec 5, 2014 at 10:21 AM, Chris Green wrote: > > This sounds very like the bug #18401 I have raised for my > > RB2011UiAS-2HnD-IN. > > > > I have exactly the same problem of everything appearing to be detected > > OK and interfaces OK but eth0 simply doesn't do anything. > > Ticket 18401 relates to BB 14.07. Therefore the issue doesn't seem to be > related to recent changes in the AR8216 driver. > It might be something more general related to the SoC-internal switch and > and external switch chip being active in parallel. As I noted in #18401 the bug is exactly the same both in BB 14.07 and in the CC trunk. Thus I think it's probably not to do with the recent changes in the driver, rather to some sort of change in the hardware in the latest Mikrotik routers. Some people with the RB2011 (other incarnations but presumably basically the same) have it working OK. -- Chris Green ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
On Fri, Dec 5, 2014 at 10:21 AM, Chris Green wrote: > This sounds very like the bug #18401 I have raised for my > RB2011UiAS-2HnD-IN. > > I have exactly the same problem of everything appearing to be detected > OK and interfaces OK but eth0 simply doesn't do anything. Ticket 18401 relates to BB 14.07. Therefore the issue doesn't seem to be related to recent changes in the AR8216 driver. It might be something more general related to the SoC-internal switch and and external switch chip being active in parallel. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
its your lucky day, according to the DHL website my RB2011UiAS-2HnD-IN will arrive in the next 2-3 hours :) On 05/12/2014 10:21, Chris Green wrote: > This sounds very like the bug #18401 I have raised for my > RB2011UiAS-2HnD-IN. > > I have exactly the same problem of everything appearing to be detected > OK and interfaces OK but eth0 simply doesn't do anything. > > I can try patches etc. if/when necessary. > > On Thu, Dec 04, 2014 at 10:13:52PM -0700, David Hutchison wrote: >> Hi, >> >> I ran into an issue with the Mikrotik Routerboard 951G's switch chip. >> The new batch that we received use an updated ar8327 switch chip. The >> switch chip would not function properly so I decided to load trunk and >> utilize your patches. >> >> dmesg shows the following: >> >> switch0: Atheros AR8327 rev. 4 switch registered on ag71xx-mdio.0 >> libphy: ag71xx_mdio: probed >> eth0: Atheros AG71xx at 0xb900, irq 4, mode:RGMII >> ag71xx ag71xx.0 eth0: connected to PHY at ag71xx-mdio.0:00 >> [uid=004dd034, driver=Atheros AR8216/AR8236/AR8316] >> >> It appears the updated ar8216.c with your changes have successfully >> initialized the chip. In fact I can even use "swconfig dev switch0" to >> create vlans etc. >> >> If I create a port vlan ( eg. put ports 1 - 2 in vlan 1 ). I can plug >> ethernet cables into each port and push data from port 1 to port 2 >> etc. It appears the switch driver is working correctly. >> >> What is broken is the interface handle "eth0". It exposes eth0 and >> ties it to the switch correctly ( as you can see from the above dmesg >> output ). I then assign an IP address to eth0, however when I try to >> ping a device connected to the switch. I get no response. There is no >> arp traffic either. It's like data from the "eth0" handle doesn't know >> how to route through the switch. >> >> It appears like the switch hardware is working ( since port 1 can >> communicate to port 2 ). However when "eth0" attempts to communicate >> to a device on port 1, it doesn't work. The device on port 1 cannot >> communicate with the "eth0" interface either. >> >> I think your patches are specifically for the switch only. If that's >> the case, then they are working. However, with your knowledge of >> ar8327 could you point me into the direction of fixing the "eth0" >> interface communicating to the ar8327 switch properly? Is there >> something in ag71xx that I should be looking at? Could the ar8327 >> switch not be initializing properly? The probe is definitely finding >> *AR8327* so that seems to be OK. I am guessing this is something >> specific with the ar924x CPU + ar8327 switch chip. I'm open to any >> suggestions :-) >> >> -- Davey >> ___ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
On Fri, Dec 05, 2014 at 07:57:35AM +0100, Heiner Kallweit wrote: > Am 05.12.2014 um 06:13 schrieb David Hutchison: > > Hi, > > > > I ran into an issue with the Mikrotik Routerboard 951G's switch chip. > > The new batch that we received use an updated ar8327 switch chip. The > > switch chip would not function properly so I decided to load trunk and > > utilize your patches. > > > > dmesg shows the following: > > > > switch0: Atheros AR8327 rev. 4 switch registered on ag71xx-mdio.0 > > libphy: ag71xx_mdio: probed > > eth0: Atheros AG71xx at 0xb900, irq 4, mode:RGMII > > ag71xx ag71xx.0 eth0: connected to PHY at ag71xx-mdio.0:00 > > [uid=004dd034, driver=Atheros AR8216/AR8236/AR8316] > > > > It appears the updated ar8216.c with your changes have successfully > > initialized the chip. In fact I can even use "swconfig dev switch0" to > > create vlans etc. > > > > If I create a port vlan ( eg. put ports 1 - 2 in vlan 1 ). I can plug > > ethernet cables into each port and push data from port 1 to port 2 > > etc. It appears the switch driver is working correctly. > > > > What is broken is the interface handle "eth0". It exposes eth0 and > > ties it to the switch correctly ( as you can see from the above dmesg > > output ). I then assign an IP address to eth0, however when I try to > > ping a device connected to the switch. I get no response. There is no > > arp traffic either. It's like data from the "eth0" handle doesn't know > > how to route through the switch. > > > > It appears like the switch hardware is working ( since port 1 can > > communicate to port 2 ). However when "eth0" attempts to communicate > > to a device on port 1, it doesn't work. The device on port 1 cannot > > communicate with the "eth0" interface either. > > > > I think your patches are specifically for the switch only. If that's > > the case, then they are working. However, with your knowledge of > > ar8327 could you point me into the direction of fixing the "eth0" > > interface communicating to the ar8327 switch properly? Is there > > something in ag71xx that I should be looking at? Could the ar8327 > > switch not be initializing properly? The probe is definitely finding > > *AR8327* so that seems to be OK. I am guessing this is something > > specific with the ar924x CPU + ar8327 switch chip. I'm open to any > > suggestions :-) > > > > -- Davey > The recent changes to the AR8216 driver are mainly cleanups with > no functional change. Also your dmesg output looks good. > So at a first glance I don't think it's something with the driver. > > At first your /etc/config/network would be helpful. > > Does your problem also happen if vlans are switched off > (enable_vlan set to 0) ? > On my RB2011UiAS-2HnD-IN I have tried complete reconfiguration of the network to swap the setup of eth0 (external Gigabit) and eth1 (internal 10/100) and the problem still exists. I'll try turning the VLANs off though and see what happens. -- Chris Green ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
This sounds very like the bug #18401 I have raised for my RB2011UiAS-2HnD-IN. I have exactly the same problem of everything appearing to be detected OK and interfaces OK but eth0 simply doesn't do anything. I can try patches etc. if/when necessary. On Thu, Dec 04, 2014 at 10:13:52PM -0700, David Hutchison wrote: > Hi, > > I ran into an issue with the Mikrotik Routerboard 951G's switch chip. > The new batch that we received use an updated ar8327 switch chip. The > switch chip would not function properly so I decided to load trunk and > utilize your patches. > > dmesg shows the following: > > switch0: Atheros AR8327 rev. 4 switch registered on ag71xx-mdio.0 > libphy: ag71xx_mdio: probed > eth0: Atheros AG71xx at 0xb900, irq 4, mode:RGMII > ag71xx ag71xx.0 eth0: connected to PHY at ag71xx-mdio.0:00 > [uid=004dd034, driver=Atheros AR8216/AR8236/AR8316] > > It appears the updated ar8216.c with your changes have successfully > initialized the chip. In fact I can even use "swconfig dev switch0" to > create vlans etc. > > If I create a port vlan ( eg. put ports 1 - 2 in vlan 1 ). I can plug > ethernet cables into each port and push data from port 1 to port 2 > etc. It appears the switch driver is working correctly. > > What is broken is the interface handle "eth0". It exposes eth0 and > ties it to the switch correctly ( as you can see from the above dmesg > output ). I then assign an IP address to eth0, however when I try to > ping a device connected to the switch. I get no response. There is no > arp traffic either. It's like data from the "eth0" handle doesn't know > how to route through the switch. > > It appears like the switch hardware is working ( since port 1 can > communicate to port 2 ). However when "eth0" attempts to communicate > to a device on port 1, it doesn't work. The device on port 1 cannot > communicate with the "eth0" interface either. > > I think your patches are specifically for the switch only. If that's > the case, then they are working. However, with your knowledge of > ar8327 could you point me into the direction of fixing the "eth0" > interface communicating to the ar8327 switch properly? Is there > something in ag71xx that I should be looking at? Could the ar8327 > switch not be initializing properly? The probe is definitely finding > *AR8327* so that seems to be OK. I am guessing this is something > specific with the ar924x CPU + ar8327 switch chip. I'm open to any > suggestions :-) > > -- Davey > ___ -- Chris Green ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
Am 05.12.2014 um 06:13 schrieb David Hutchison: > Hi, > > I ran into an issue with the Mikrotik Routerboard 951G's switch chip. > The new batch that we received use an updated ar8327 switch chip. The > switch chip would not function properly so I decided to load trunk and > utilize your patches. > > dmesg shows the following: > > switch0: Atheros AR8327 rev. 4 switch registered on ag71xx-mdio.0 > libphy: ag71xx_mdio: probed > eth0: Atheros AG71xx at 0xb900, irq 4, mode:RGMII > ag71xx ag71xx.0 eth0: connected to PHY at ag71xx-mdio.0:00 > [uid=004dd034, driver=Atheros AR8216/AR8236/AR8316] > > It appears the updated ar8216.c with your changes have successfully > initialized the chip. In fact I can even use "swconfig dev switch0" to > create vlans etc. > > If I create a port vlan ( eg. put ports 1 - 2 in vlan 1 ). I can plug > ethernet cables into each port and push data from port 1 to port 2 > etc. It appears the switch driver is working correctly. > > What is broken is the interface handle "eth0". It exposes eth0 and > ties it to the switch correctly ( as you can see from the above dmesg > output ). I then assign an IP address to eth0, however when I try to > ping a device connected to the switch. I get no response. There is no > arp traffic either. It's like data from the "eth0" handle doesn't know > how to route through the switch. > > It appears like the switch hardware is working ( since port 1 can > communicate to port 2 ). However when "eth0" attempts to communicate > to a device on port 1, it doesn't work. The device on port 1 cannot > communicate with the "eth0" interface either. > > I think your patches are specifically for the switch only. If that's > the case, then they are working. However, with your knowledge of > ar8327 could you point me into the direction of fixing the "eth0" > interface communicating to the ar8327 switch properly? Is there > something in ag71xx that I should be looking at? Could the ar8327 > switch not be initializing properly? The probe is definitely finding > *AR8327* so that seems to be OK. I am guessing this is something > specific with the ar924x CPU + ar8327 switch chip. I'm open to any > suggestions :-) > > -- Davey The recent changes to the AR8216 driver are mainly cleanups with no functional change. Also your dmesg output looks good. So at a first glance I don't think it's something with the driver. At first your /etc/config/network would be helpful. Does your problem also happen if vlans are switched off (enable_vlan set to 0) ? Heiner ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] ar934x+ar8327v4
Hi, I ran into an issue with the Mikrotik Routerboard 951G's switch chip. The new batch that we received use an updated ar8327 switch chip. The switch chip would not function properly so I decided to load trunk and utilize your patches. dmesg shows the following: switch0: Atheros AR8327 rev. 4 switch registered on ag71xx-mdio.0 libphy: ag71xx_mdio: probed eth0: Atheros AG71xx at 0xb900, irq 4, mode:RGMII ag71xx ag71xx.0 eth0: connected to PHY at ag71xx-mdio.0:00 [uid=004dd034, driver=Atheros AR8216/AR8236/AR8316] It appears the updated ar8216.c with your changes have successfully initialized the chip. In fact I can even use "swconfig dev switch0" to create vlans etc. If I create a port vlan ( eg. put ports 1 - 2 in vlan 1 ). I can plug ethernet cables into each port and push data from port 1 to port 2 etc. It appears the switch driver is working correctly. What is broken is the interface handle "eth0". It exposes eth0 and ties it to the switch correctly ( as you can see from the above dmesg output ). I then assign an IP address to eth0, however when I try to ping a device connected to the switch. I get no response. There is no arp traffic either. It's like data from the "eth0" handle doesn't know how to route through the switch. It appears like the switch hardware is working ( since port 1 can communicate to port 2 ). However when "eth0" attempts to communicate to a device on port 1, it doesn't work. The device on port 1 cannot communicate with the "eth0" interface either. I think your patches are specifically for the switch only. If that's the case, then they are working. However, with your knowledge of ar8327 could you point me into the direction of fixing the "eth0" interface communicating to the ar8327 switch properly? Is there something in ag71xx that I should be looking at? Could the ar8327 switch not be initializing properly? The probe is definitely finding *AR8327* so that seems to be OK. I am guessing this is something specific with the ar924x CPU + ar8327 switch chip. I'm open to any suggestions :-) -- Davey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
