2016-05-26

<montjoie> with 3 my board doesnt work
<wens> montjoie: funny, i remember using a value of 3...
<montjoie> apritzel: it is put off when you reboot
<montjoie> apritzel: I will publish a new version with your remark
<apritzel> montjoie: Ethernet is so great, you don't want to turn it off ;-)
<montjoie> and it seems that I cannot send the driver already (crash when stopping interface:))
<montjoie> apritzel: do you want it ?
<montjoie> apritzel: yes
<apritzel> montjoie: but your branch does not have the DT bits for A83T, right?
<montjoie> but both should be nearly the same
<montjoie> my current branch
<apritzel> montjoie: that is with your current branch on github? Or with wens' version?
<montjoie> wens: so it work perfectly on bpim3
<montjoie> wens: it was my fault, the good value is 6:) not 3
<wens> montjoie: sorry, i hadn't tested the new version on the a83t
<montjoie> wens: sorry forget about SC_ETXDC_SHIFT
<montjoie> but network doesnt work
<montjoie> it is what I got now
<montjoie> apritzel: no all is perfectly init with a bad txdelay
<montjoie> wens: SC_ETXDC_SHIFT was off by one too much
<montjoie> apritzel: yes on a bpim3
<apritzel> wens: so you have montjoie's driver running on an A83T with the RTL8211E PHY?
<montjoie> wens: in fact txdelay does not write anything, does allwinner,tx-delay = "3" is the right syntax ?
<wens> montjoie: i actually have a wip driver for rtc part of ac100
<wens> montjoie: :)
<montjoie> wens: at least the emac driver work on bpim3 with tx-delay
<montjoie> :(
<wens> montjoie: the axp pmic is a pmic and an ac100 combined
<montjoie> my googling seems to say "I need to buy one"
<montjoie> wens: do you know which model it is ?
<wens> montjoie: rtc is in the external chip
<montjoie> there are no RTC on A83T ?

2016-05-23

<montjoie> Amit_T: my first comment on too big was due to wens already said that to me:)
<Amit_T> montjoie: Thanks for the comments but I am bit confused do you want to have mmio region upto 10000 or I should cut it down ?

2016-05-20

<wens> as i mentioned to montjoie, i'm hoping the new bus-related power sequencing bindings could be ironed out so we could use them

2016-05-19

<lvrp16> montjoie: very nice work
<apritzel> wens: montjoie: so apparently this line has to be pulled down for at least 10ms, according to the PHY datasheet
<apritzel> montjoie: nice! looking forward at comparing the CE version of sha256 with the ARMv8 instructions
<montjoie> but benching it bring me some additionnal work to do
<montjoie> apritzel: yes
<apritzel> montjoie: that's the CE in H3 and A64?
<willmore> Yay, montjoie!
<Amit_T> montjoie: Nice :)
<montjoie> sha384 and 512 done:)
<montjoie> apritzel: send me I will fix it immediatly
<apritzel> wens: montjoie: I have two small compiler warning fixes for the EMAC driver
<montjoie> like flow_ctrl where I am sure to do shit
<montjoie> wens: I just need to remove one or more TODO
<wens> montjoie: i think you could try sending an initial version once the merge window is closed
<montjoie> ok I will remove it
<wens> montjoie: fyi allwinner,leds-active-low doesn't work with external phys (on the opi plus)
<montjoie> wens: apritzel I have updated my github emac branch with the phydev test problem

2016-05-18

<apritzel> montjoie: of_phy_connect() (called from your sun8i_emac_mdio_probe()) does not return a pointer-wrapped error, but just NULL if it fails
<KotCzarny> montjoie: great, now i only need working power management on my opipc (and soon opi+2e)
<montjoie> KotCzarny: sha256 done:)
<KotCzarny> montjoie: :)
<montjoie> tomorow probably
<montjoie> ingoing for SHA224 256 384 512
<KotCzarny> montjoie: i mean sha256
<KotCzarny> montjoie: is there aes256?
<KotCzarny> montjoie: you da man!
<montjoie> selftest OK for MD5 SHA1 and AES for H3 crypto:)
<montjoie> no hurry, It give me time to work on CE:)
<apritzel> montjoie: the stack trace is only at home, unfortunately :-(
<montjoie> In the same time I need to finish to setup my pine64
<montjoie> if you could share the stack trace
<montjoie> apritzel: yes the regulator is optional
<apritzel> montjoie: if that rings a bell, let me know, if not, I will investigate later on
<apritzel> montjoie: so I assume that phydev was NULL
<apritzel> montjoie: but the regulator is optional, right?
<apritzel> montjoie: thanks
<montjoie> with latest wens ephy patch
<montjoie> apritzel: I have updated https://github.com/montjoie/linux/tree/sun8i-emac-wip

2016-05-17

<wens> montjoie: both
<montjoie> wens chich regulator bindings ? regulator_io ?
<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
<montjoie> so perhaps I have some problem
<montjoie> and I need to retest it because the quality of hwrng (tested by rngtest) decrease when the SS is usd by another algo
<igraltist> montjoie: could you give me the url for github again :D
<montjoie> until recently the quality wasnt enough good
<igraltist> montjoie: ok
<montjoie> igraltist: no mainline at all for hwrng
<igraltist> montjoie: the /dev/hwrng is build so i was thinking the patch was in mainline
<montjoie> try from my github
<igraltist> montjoie: i just remember that i was trying ur patch before. but it was longer time ago
<montjoie> and from where do you get hwrng patch ?
<montjoie> could you share dmesg ?
<montjoie> igraltist: didnt own any cubietruck
<igraltist> montjoie: the rngd does not start, [rngd] No entropy sources working, exiting rngd_
<igraltist> montjoie: did u test the hwrng on cubietruck with kernel 4.5?
<wens> montjoie: not sure what you gain from splitting it out
<wens> montjoie: the syscon/ephy code is 100 something lines, only called in _init/_uninit
<montjoie> wens: do you think split in two files could be a good idea ? sun8i_emac sun8i_ephy
<montjoie> thanks
<montjoie> wens: I will check it
<wens> montjoie: my h3-emac branch is updated

2016-05-12

<willmore> montjoie, I have H3 and A64 boards, let me know if you want me to do any soak testing or anything.
<oneinsect> montjoie: i cant seem to apply that patch
<ssvb> montjoie: and the use of special crypto instructions on ARM64 - https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/crypto/aes-ce.S?id=refs/tags/v4.6-rc7
<montjoie> apritzel: 4 channel of DMA task (8 if I can use also the Secure CE)
<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
<montjoie> wens: I have updated http://linux-sunxi.org/Sun8i_emac for instructions but we need a proper way to do it
<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"
<jelle> montjoie: nice!
<montjoie> I have create http://linux-sunxi.org/Sun8i_emac feel free to comment
<wens> dave0x6d: networking is montjoie's work, i'm just throwing patches together cause i want remote access to my boards

2016-05-09

<KotCzarny> i think montjoie wrote mainline driver
<montjoie> wens: do you want that I do it ?
<montjoie> need concensus on how to "driver" PHY
<montjoie> alain__: no
<lennyraposo> montjoie can probably give you details in his battles with that

2016-05-08

<montjoie> but I fear that DMA will never be usable, I need to confirm it, but the data coruption bug made DMA impossible
<montjoie> KotCzarny: yes but less cpu
<KotCzarny> montjoie: those tests with dma mention its much slower
<montjoie> longsleep: KotCzarny SS do not use DMA for the moment so always CPU...
<montjoie> see the bug report on my site
<montjoie> longsleep: yes and no, since cryptodev use ioctl you cannot use it with secomp
<montjoie> and my bench are for the first SS (A20/A10/etc)
<longsleep> montjoie: can openssl use cryptodev?
<montjoie> longsleep: af_alg is slow so bad perf is "expected", cryptodev is better but not in mainline
<KotCzarny> looking at benches of ciphers on montjoie's site..
<longsleep> montjoie: sunxi-ss md5 and sha1 is slower than the kernel ones according to your cryptotest af_alg - that is expected?
<apritzel> and I tried two weeks ago to compare the initialisation sequence of the BSP driver with montjoie's
<apritzel> but then montjoie was getting promising results and so I dropped this
<apritzel> montjoie, wens: does sunxi-ss does something that the ARMv8 crypto extensions don't
<longsleep> montjoie: ah but i can try if i get some numbers with https://github.com/montjoie/cryptotest - thanks for the link!
<longsleep> montjoie: yeah i was looling into the ones which are in the BSP 3.10 driver for A64
<montjoie> oups it seems you speak BSP crypto driver and not mainline
<montjoie> longsleep: old data on sunxi.montjoie.ovh
<montjoie> since I made them:)
<montjoie> longsleep: I have benchmarked them
<wens> montjoie: ^
<apritzel> montjoie: there is some extra power signal referenced in the PHY section, but it's not clear where it is connected
<apritzel> montjoie: PHY powered> yeah, would make sense, only the schematics is not really helpful here
<montjoie> apritzel I am sure that on pine64 PHY need to be powered, each time EMAC timeout in reset, the root cause is PHY

2016-05-06

<montjoie> strange
<hpeter> montjoie: i need retry 14,5,35,14,37 times to wait reset complete
<hpeter> montjoie: It's horrible, I had tried with 5 times with http://pastebin.com/5gB2sPQV
<hpeter> montjoie: thanks, I'll try how many time should this need to wait
<montjoie> thanks hpeter for the timeout, I had a todo to change it to a better function. Just done it with upper delay
<hpeter> montjoie: i found a dirty result http://pastebin.com/1G6LxQYg
<hpeter> montjoie: here is bootlog http://pastebin.com/Dr9J0sRp
<montjoie> hpeter: could you paste your bootlog ?
<montjoie> hpeter: yes you need both EMAC and EPHY
<hpeter> montjoie: hi, I had tried your sun8i-emac-wip with Orange PI PC (Allwinner H3) with enable CONFIG_SUN8I_EMAC=yy
<montjoie> hpeter: solved
<hpeter> montjoie: thanks :D
<montjoie> hpeter: I forgot a patch on my github, I will update it soon
<hpeter> montjoie: thanks for your help :D
<montjoie> hpeter: I will check if I forgot a patch

2016-05-05

<apritzel> montjoie: I just tried it again, the a64-wip tree with defconfig booted "fine":
<apritzel> montjoie: Salut, what .config did you use for the Pine64 kernel? defconfig?
<montjoie> openssl compiled in 25minutes over NFS, 20 on tmpfs, not so bad for NFS:)
<montjoie> (the image posted yesterday of course)
<montjoie> apritzel: I use the DT provided by your image
<apritzel> montjoie: do you use the DT from that tree as well? (or the ones from the image, they should be the same)
<montjoie> no mmc log at all
<montjoie> your a64-wip
<apritzel> montjoie: which kernel? which tree?
<montjoie> on pine64 which MMC driver is necessary ? I enable only ALLWINNER one but no mmc at all
<n3rd_dude> NiteHawk, KotCzarny, montjoie, thank you for your advice. I have to go now. I might be back in a couple of hours :-) ttyl
<apritzel> montjoie: can you drop the UBSAN dmesg somewhere?
<apritzel> montjoie: no, but thanks for the heads up
<montjoie> ETOOMANYWARN
<montjoie> apritzel: do you have tested aarm64 with ubsan ? I need to disable it when testing my pine64
<n3rd_dude> montjoie: that'd be nice to see
<montjoie> even on rpi I compile over NFs, but rpi is a bit more slow:)
<montjoie> n3rd_dude: I need to take time to iozone NFS
<n3rd_dude> montjoie: ^ :-)
<montjoie> I didnt try to optimize it, but it is fast enought (relative to sdcard speed)
<n3rd_dude> montjoie: no overhead?
<montjoie> but you need a NFS server with "classic" storage
<montjoie> n3rd_dude: Wizzup compiling on NFS is fast enought

2016-05-04

<montjoie> ssvb: for FEL issue yesterday, it seems to be ENEEDMOREPOWER

2016-05-03

<ssvb> montjoie: I mean the USB OTG part of the hardware, which might be potentially broken on your board (as one of the possible explanations)
<montjoie> I tried both upper and down
<montjoie> it boot perfectly from sdcard, I will try another USB hub at work
<montjoie> same hub for both cable
<montjoie> I am near sure to have seen an usb device on my last try, one month ago
<montjoie> then FEL cable then power
<montjoie> I have disconnect all
<montjoie> one side connected to upper pine64 usb the other on my USB hub
<montjoie> USE male A-A
<montjoie> with sdcard it boot but whithout it I got nothing
<montjoie> yes
<ssvb> montjoie: have you checked https://linux-sunxi.org/Pine64#FEL_mode ?
<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
<montjoie> what do you mean ?
<montjoie> DMA reset ?