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 0x3e000000 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 <blo...@openwrt.org> 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 = 0x3c000000;
>>>>
>>>> I think we found a solution :)
>>>>
>>>
>>> looking at the other routerboards bit 25 is always set does 0x3e000000
>>> 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 0x3e000000 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 <blo...@openwrt.org>
>>>> wrote:
>>>>>
>>>>>
>>>>> On 10/12/2014 14:44, Chris Green wrote:
>>>>>> On Wed, Dec 10, 2014 at 10:23:12AM +0000, 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 0x6f000000, 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
>>>>>>> 0x6f000000) and see if it works for me too.
>>>>>>>
>>>>>> Eureka! :-)
>>>>>>
>>>>>> Changing the line in mach-rb2011.c from:-
>>>>>>
>>>>>> ath79_eth0_pll_data.pll_1000 = 0x06000000;
>>>>>>
>>>>>> to:-
>>>>>>
>>>>>> ath79_eth0_pll_data.pll_1000 = 0x6f000000;
>>>>>>
>>>>>> 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
>
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
