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?
Best regards,
Krzysztof Adamski
--
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 linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
