On Thu, Feb 25, 2016 at 02:43:22PM +0100, Krzysztof Adamski wrote:
> On Thu, Feb 25, 2016 at 01:59:43PM +0100, LABBE Corentin wrote:
> >On Thu, Feb 25, 2016 at 08:52:47AM +0100, Krzysztof Adamski wrote:
> >> On Mon, Feb 22, 2016 at 04:45:09PM +0100, LABBE Corentin wrote:
> >> >Hello
> >> >
> >> >This is a RFC patch series for supporting ethernet of H3/A83T/A64 SoCs.
> >> >For the moment, it is a bundle driver which handle:
> >> >- The MAC driver
> >> >- The internal PHY driver
> >> >- The internal PHY clock driver
> >> >
> >> >I am sorry for the quality of this code, I dislike to release that at
> >> >this state
> >> >but for the moment I am blocked in every direction.
> >> >
> >> >For A64 I didnt have access to such hardware, but according to
> >> >apritzel, the PHY need to be powered by the PMIC and for the moment
> >> >there are no support for it.
> >> >On my H3 (OPIPC) all basic functions works EXCEPT that frame
> >> >transmition is never sent on the wire.
> >> >On my A83T board (h8homlet), the PHY seems not powered. The PHY for
> >> >this board is an AC200 (an Allwinner chip without any datasheet)
> >> >accessible on the I2C bus.
> >> >
> >> >What need work ?
> >> >- Finding why the internal PHY of the Orange PI PC does not send frame
> >> >on the wire
> >>
> >> I don't think it's a PHY issue. I'm able to get some packets sent on the
> >> wire:
> >> - when doing ping from Orangepi PC, arp requests are seen on the other
> >> end of cable but Opc won't get arp replies
> >> - when doing arping from other end, I can get some replies from OPC
> >> - wen doing broadcast ping from other end, I'm getting some repies from
> >> OPC; the order of receiveing packages is wrong, times are high and
> >> packages are lost but at least something is received
> >>
> >> All I did so far is to modify sun8i_emac_xmit so tha none of bits 12-28,
> >> except bit 24, is set in ddesc->st (this seems to be the only bit set
> >> by
> >> BSP kernel, after brief look).
> >>
> >> Best regards,
> >> Krzysztof Adamski
> >
> >Great thanks for this finding. I can confirm that now I can get ARP replies
> >from my OPIPC.
> >I will investigate the "lots of frame lost".
> >But this undocumented bit does not explain why I can get only half
> >duplex from PHY.
>
> The bit is undocumented in datasheet but it is in the BSD kernel
> sources. It's description ("Second address chained") does not say much
> to me, though.
>
> What's strange to me right now is that after few packages transmitted,
> packets seems to be only sent when all four DMA descriptions are set -
> only then I get sun8i_emac_dma_interrupt and all 4 packets can be seen
> on the other end of the wire.
>
> It seems that first "flush" is done when descriptor 0 is first filled,
> then, this descriptor will be freed in sun8i_emac_complete_xmit so next
> time packet is to be transmitted this descriptor will be reused but
> nothing is transmitted until next packet is sent (descriptor 1 will be
> used). Both descriptors will be cleared in sun8i_emac_complete_xmit and
> then next two packets won't flush until 3rd descriptor is filled. From
> now on, packets will only be flushed when last (4th descriptor) is
> filled. Do you see the same behaviour? Any ideas why this happens?
>
I think the circular buffer was too hacked when I try to debug my issue.
I need to work on it.
Regards
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
