<wens>
montjoie: fyi i would drop the regulator bindings for now, since a) we don't support the pmic, and b) there's discussion on how to do power sequencing for various busses
2016-05-16
<apritzel>
montjoie: thanks, will pick it from there!
<montjoie>
apritzel, my github have the latest version
<apritzel1>
montjoie: great! Do you have some preview for me to test it tonight?
<montjoie>
apritzel1: I will publish tomorow the latest version of emac with latest PHY patch from wens
<apritzel1>
montjoie: OK, thanks, one thing less to worry about
<montjoie>
apritzel1: yes for external gigabit PHY
<apritzel1>
montjoie: out of interest: has this driver been run on a board with an external (Gigabit) PHY before?
<apritzel1>
montjoie: I will update and re-check tonight
<apritzel1>
montjoie: re: EMAC driver crash on Pine64> I think I have an older version of your driver, also not sure I got the DT bits correct
<montjoie>
apritzel could you share the stack trace ?
2016-05-15
<wens>
montjoie: ^
<tkaiser>
dave0x6d: montjoie's of course.
2016-05-14
<KotCzarny>
montjoie: hrm
<montjoie>
I never think anything MDIX related in ethernet drivers
<montjoie>
KotCzarny: I think the support is in PHY
<KotCzarny>
montjoie: does your driver support mdi-x ?
2016-05-13
<montjoie>
KotCzarny: the speed is not bad in my memory
<apritzel>
montjoie: I got this, I am just afraid that the A53 crypto instructions are faster than Allwinners crypto engine
<montjoie>
I clearly dont have the expertise on assembly
<montjoie>
I speak only about the CryptoEngine no crypto extention
<montjoie>
ssvb: I dont think the crypto engine use neon
<apritzel>
ssvb: montjoie: also would be interesting to see how the crypto extensions perform on the A53
<ssvb>
montjoie: Cortex-A53 in A64 has roughly twice faster NEON per MHz compared to Cortex-A7 in H3, so the software crypto should have a nice speed boost
<montjoie>
yes even for A20 I need it
<ganbold>
montjoie: updated benchmark page would be nice
<montjoie>
A64 is same as H3 (just +/- some algos)
<montjoie>
but A83T is a bit similar
<montjoie>
H3
<ganbold>
montjoie: which SoC?
<montjoie>
will I resist to bench it...
<montjoie>
crypto engine aes support complete, now working on hash
<wens>
montjoie: half way through my emac/ephy rework
<montjoie>
mripard: since it is written in fex I think no
<mripard>
montjoie: sorry, what I meant was can it change between two orange pi pc for example
<montjoie>
mripard: yes it is why it need to be in dt, but currently the only one way is devmem
<wens>
montjoie: it's probably going to be a couple of dt properties
<NiteHawk>
montjoie: bpi-m1 is emac, or? it uses GMAC_TX_DELAY=3
<montjoie>
does anyone here with Gigabit EMAC needed to tweak tx/rx delay ?
2016-05-11
<montjoie>
lvrp16: at least it is written in datasheet
<montjoie>
and then typex all user manual:)
<montjoie>
willmore: bug
<willmore>
montjoie, in that it had a bug and they cut it out? Or in that CTS/CTR aren't recommended for use anymore? (or both)
<montjoie>
willmore: like CTS/CTR in A20:)
<willmore>
montjoie, every feature you advertise is a feature you have to test and guarentee. If people aren't demanding RSA, why go through that pain? (conspiracy theory: they knew it had a bug, so they quietly cut it out)
<montjoie>
KotCzarny: the A83T and H3 is only with DMA (no cPU poll) so no choice it will free CPU
<montjoie>
the greatest problem is "why allwinner removed RSA from H3 user manual"
<montjoie>
lvrp16: I expect that it will be faster, at least it have 4 channel of work
<willmore>
montjoie, I was joking about your recent good work with the ethernet driver. ::)
<montjoie>
willmore: I speak about crypto engine, never tried to overclock ethernet
<willmore>
montjoie, overclocking ethernet is not a good idea.
<montjoie>
willmore: last time I try overclock bad things happen, but at least the result is secure
<willmore>
montjoie, overclock the crypto engine!
<montjoie>
it could be earlier if I was smart enought to enable module clock...
<willmore>
montjoie, congratulations.
<montjoie>
yeah I am near to have AES working on H3 Crypto Engine
2016-05-10
<montjoie>
ouch, ANY write on the A83T SecuritySystem stuck the board...
<plaes>
montjoie: fixed few typos
<montjoie>
just try iperf
<jelle>
montjoie: I'll ping you when I've set it up or are there steps somewher about testing?
<jelle>
err montjoie ^
<montjoie>
you could try to bench on board other than opipc
<jelle>
montjoie: I guess the h3 doesn't need further testing?
<montjoie>
2 weeks that I need to click on "create"
<montjoie>
what is the exact sequence of cabling to do FEL for pine64, I got nothing in lsusb
<wens>
montjoie: i guess it's still under debate?
<montjoie>
wens: so if I understand you, I need to add ephy register in my driver right ?
<Amit_T>
apritzel:montjoie: Hello, able to tftp kernel and other images but I do see this when bootz , http://paste.ubuntu.com/16199625/
2016-05-02
<Amit_t_>
apritzel:montjoie: Got the ping working now from u-boot prompt :) :)
<Amit_T>
montjoie: Hello, I can see now the second transmit packet on the wire but it doesn't look good .Instead of ICMP echo request , its sending some UDP packet , http://paste.ubuntu.com/16186378/ .
2016-04-30
<montjoie>
just updated my github with the latest h3 emac driver
2016-04-29
<Amit_T>
montjoie: ok
<montjoie>
Amit_T: when the hardware sent a frame it then go the next descriptor (the 4*u32 structure). you can see it in TX_DMA_CURR_DESC
<montjoie>
and check if your current descriptor is the same than HW current desc
<montjoie>
the DMA TX state will let you know if DMA is stopped and why
<montjoie>
Amit_T: try restart dma after each packet and print DMA STATE register
<Amit_T>
montjoie: you mean to say 4 in total
<montjoie>
Amit_T: arp(2) then ping
<Amit_T>
montjoie : Yes.It never sent on wire.
<montjoie>
Amit_T: if I understand the second frame is never sent ?
<Amit_T>
apritzel: montjoie: Hello, I am able to send ARP request and receive ARP reply to u-boot .This particular function net_send_packet from u-boot https://github.com/trini/u-boot/blob/master/net/arp.c#L224 , once again triggers the driver's send function but this time around there in no packet send on wire
2016-04-26
<montjoie>
checking ntp/hwclock derive
<montjoie>
first you need monitoring :)
<montjoie>
oneinsect: I2C_MV64XXX does not work ?
<montjoie>
oneinsect: my repo is just mainline with emac, I do not know I2C status for it
<oneinsect>
montjoie: quick question
<montjoie>
does someone with a gigabit H3/A83T could run iperf on it and give me the output of ethtool -S eth0 ?
<apritzel>
zoobab: you could give it a try: the driver is just one file, you could download it from montjoie's github and just add it to the Makefile of a 4.4 kernel and see what happens
<montjoie>
zoobab: driver fully usable
2016-04-25
<apritzel>
Amit_T: it's the one from montjoie's github repo, pulled end of last week
<Amit_T>
apritzel: Its same Ethernet driver worked by montjoie, right ?
<Amit_T>
montjoie: To be honest with you, I did try different combination of write order before posting it but nothing seems to work
<montjoie>
Remove the first BIT(29) and with lucks it will work
<montjoie>
:)
<Amit_T>
montjoie: Thanks for your comments .
<wens>
montjoie: bpi m3 needs rx/tx delay set in syscon register :/
<wens>
montjoie: i do not have the chinese one
2016-04-24
<montjoie>
than chinese
<montjoie>
wens: does the a83t emac datasheet is different in english ?
2016-04-23
<montjoie>
apritzel: for some opi, without regulator, it have the same symptom (rst timeout). But i dont know what do the regulator
<apritzel>
montjoie: or does the MAC itself require some special regulator, for talking to the PHY via MDIO, for instance?
<apritzel>
montjoie: no, no LEDs at all
<montjoie>
apritzel: does "ethernet led" fire up when powering it ?
<apritzel>
montjoie: OK, will push my arm64 warning fixes and the Pine64 .dts bits anyway, so people can play with it
<apritzel>
montjoie: too bad, that means that apparently by default the PMIC does not power the PHY :-(
<montjoie>
apritzel: each time someone speak about SOFT_RST, it was a missing regulator
<montjoie>
apritzel: no the comment is just for replace it
<apritzel>
montjoie: seeing your commented readl_poll_timeout() there I wonder if you have seen issues with this before?
<apritzel>
montjoie: the driver seems to initialize, but bringing the interface up leads to a timeout in SOFT_RST
<apritzel>
montjoie: I badly hacked the a20-gmac clock to set bit 13 as well for the time being
<apritzel>
montjoie: are you around? I am playing with your driver on the Pine64 ...
2016-04-20
<montjoie>
no use of external DMA device
<montjoie>
the DMA is done by EMAC, so it is reseted/asserted in the same time