2017-03-08

<montjoie> or use gentoo:)

2017-03-06

<plaes> montjoie knows better
<montjoie> perhaps some betatest from spammers
<montjoie> wens: got one

2017-03-05

<wens> montjoie: yes, but haven't used it in quite a while
<montjoie> or anybody here who got it, any recent try to use it ?
<montjoie> wens: did you still own the h8homlet devboard ?

2017-03-04

<montjoie> exactly I want to know if it exists other board with it
<montjoie> plaes: I do not know any other board that use it.
<plaes> montjoie: can you name any other of those boards?
<montjoie> apart from bpim3
<montjoie> anybody here with board that use dwmac-sun8i AND TX/RX delay ?
<montjoie> my not-updated-for-months a83t board is still updating gentoo, I pray for PSCI support:)
<montjoie> seems fun

2017-03-03

<montjoie> and without PCSI, iperf is still the same 400MB/s both way
<montjoie> surprised that it works on the first try:)
<montjoie> MoeIcenowy: yes
<MoeIcenowy> montjoie: did it connect to network?
<montjoie> wens: bpim3 with dwmac-sun8i on top of your branch booted

2017-03-01

<montjoie> so no problem for openssl engine acceleration/offload
<montjoie> but openssl do the same
<montjoie> just the CE support only RSA with padded data
<montjoie> no quirk I remember
<MoeIcenowy> montjoie: what quirk?
<montjoie> no bench for the moment
<KotCzarny> montjoie: did the quirk fix hurt performance further?
<montjoie> at origin, I buy H3 only for that (RSA accel)
<willmore> montjoie, that's great news! Thanks walkiry!
<montjoie> CryptoEngine successfully pass RSA 512 test thanks to walkiry
<wens> montjoie: just updated that branch, should work

2017-02-28

<montjoie> wens: for testing dwmac-sun8i on a83t, which one of your branch is the best ? still sun8i-a83t-mmc ?

2017-02-26

<tucker> montjoie: np.
<montjoie> tucker: thanks for the report
<tucker> Hey. Just wanted to report that I'm running 4.10 with dwmac ethernet (extracted from montjoies stmmac-sun8i-wip tree, internal phy) on my silly little H3 box. The dts is (for now) more or less a copy of the orangepi-pc dts.
<montjoie_> MoeIcenowy: I pushed my v2 which should fix your issue on V3S (early init PHY)

2017-02-24

<montjoie> thanks
<walkiry> montjoie: i also noticed that the key (exposant) buffer is not reversed [MSB...LSB] (in contrary to other data such as modulus and encryption buffer )
<montjoie> reydecopas: why not
<reydecopas> montjoie: to the average user... I mean a howto for building maybe armbian, enable config in kernel, getting compile cryptodev, and openssl with cryptodev support and openvpn
<montjoie> reydecopas: howto for what ?
<montjoie> reydecopas: my last bench will disappoint you
<montjoie> and let CE only work on easy request
<montjoie> I have begin to work on fallback for handling them
<montjoie> the biggest problem is to handle non aligned request
<montjoie> for the moment no, I need to finish it
<reydecopas> @montjoie Can I help you in something?
<montjoie> reydecopas: I need to finish it
<montjoie> sun8i-ce is experimental
<montjoie> MoeIcenowy: init phy early is harder than I think:(
<montjoie> the pain is the lack of documentation (and its speed)
<walkiry> montjoie: hope it helps :)
<walkiry> montjoie: no problem, this crypto engine is a pain in the ***
<montjoie> walkiry: thanks I will try to update the CE driver with those informations
<walkiry> montjoie: The security system RSA mode works on the A64. The data should be presented in a form of array of the key size (modulus, key, data) such as : [LSB....MSB] and the result will be return following the same pattern.

2017-02-23

<montjoie> and so moved init_phy too late in the process
<montjoie> funny that I hit it certainly, but forget it after updated uboot
<montjoie> MoeIcenowy: I will work on it tomorow, but fix is nearly easy
<MoeIcenowy> montjoie: thx l-)
<montjoie> MoeIcenowy: PHY problem confirmed on my opipc without emac in uboot
<montjoie> MoeIcenowy: thanks for the try, I will try ask them direclty just in case of...
<walkiry> montjoie: i commented some stuffs i understood from their maze code
<walkiry> montjoie: line 371
<MoeIcenowy> montjoie: nope... BU2 seems to not care EMAC
<walkiry> montjoie: http://pastebin.com/EwAwDVyy
<montjoie> MoeIcenowy: do they give you TX/RX delay infos ?
<montjoie> could you paste the content ?
<montjoie> where ?
<montjoie> just some algs are different like absence of sha512
<walkiry> montjoie: i try every configuration
<montjoie> walkiry: near the same
<montjoie> walkiry: I think my issue is LE/BE ordering
<walkiry> montjoie: you say the A64 crypto ip block is the same as the H3
<montjoie> but RSA is in "I try everything for made it works" (crappy)
<montjoie> walkiry: you could check my cryptoengine github branch
<montjoie> "lol" is totaly legal for such a code
<montjoie> RSA in CBC mode
<montjoie> the BSP driver for RSA is a total joke
<montjoie> at least they claim it is present
<montjoie> more generally, RSA does not work on any Allwinner CE
<montjoie> walkiry: no
<willmore> That would be a montjoie question.

2017-02-22

<wens> montjoie: just that they are in the CCU (perhaps because it looks like a clock)
<wens> montjoie: the clock related settings in the syscon are the same
<montjoie> will trytoday
<montjoie> MoeIcenowy: not yet
<MoeIcenowy> montjoie: have you checked EPHY issue?
<montjoie> wens: dwmac-sunxi and sun8i are incompatible, perhaps I read you wrong
<montjoie> MoeIcenowy: dwmac-sun8i have it (board bpi m3 need it)
<MoeIcenowy> montjoie: rx and tx delays is always a disaster ;-)
<montjoie> MoeIcenowy: I vote for question about tx/rx delay:)
<wens> MoeIcenowy: btw, can you also ask about the GMAC clock, how the tx/rx delays are calculated and what units they are in, to help montjoie ?

2017-02-20

<MoeIcenowy> montjoie: when after boot, the content of 0x01c50004 is 0x08000001 (according to Allwinner's DT R40 GMAC is at 0x01c50000
<MoeIcenowy> montjoie: I'm now testing on R40 -- PHY is now properly probed, but "EMAC reset timeout"
<montjoie> by support you means ?
<MoeIcenowy> montjoie: support for PHYRSTB is also needed in dwmac-sun8i
<wens> montjoie: cb2 is gmac with 100mbps phy
<montjoie> yes only 100
<montjoie> for testing stmmac chanegs on non-dwmac-sun8i
<montjoie> no I am sure that cubieboard2 use stmmac, I use it for test
<montjoie> what give you clues that they changed GMAC IP ?
<montjoie> (A20)
<montjoie> cubieboard2 gmac is dwmac-sunXi
<montjoie> if they use sun4i-emac.c its clearly not dwmac-su8ni related
<montjoie> MoeIcenowy: I will retest without uboot/EMAC
<wens> montjoie: i just remember there's some magic value if you want stmmac to scan the mdio bus, i think it was -1
<montjoie> I am puzzled why my opipc works
<montjoie> you have 15 choice
<montjoie> did you try 2 3 4 ?
<montjoie> MoeIcenowy: I a interested to know if you put the good reg=<>, does it work woithout modification
<montjoie> wens: didnt remember to have use -1
<montjoie> yes, before mdio bus is registered
<wens> montjoie: use -1 to test all addresses
<montjoie> I will think on how to move init_phy
<montjoie> when you will find the good reg, perhaps it is not necessary
<montjoie> if you do not know phy address
<montjoie> normal, 0 is the catch all, I need to refind how to test 15 address
<montjoie> my memory corruped probably
<montjoie> last time I set 0, mdio probe tried 1-15
<montjoie> no 30 lines od mdio print ?
<montjoie> which one is non ffff
<montjoie> you could see on mdio prints
<montjoie> attached on which address ?
<montjoie> and yeah probably init_phy is not early enought
<montjoie> try it
<MoeIcenowy> montjoie: on opipc I think u-boot gained emac support before linux
<montjoie> MoeIcenowy: could you paste dmesg ?
<montjoie> if you have only two stmmac_mdio_read reg is not 0
<montjoie> but at least on opic it works
<montjoie> add pr_info for be sure
<montjoie> init_phy is called before
<montjoie> MoeIcenowy: the clock is enabled before in init_phy
<montjoie> MoeIcenowy: and with reg = <0>
<MoeIcenowy> montjoie: sorry I seek for wrong place...
<montjoie> stmmac_probe_config_dt
<montjoie> put a pr_info in all calling chain
<montjoie> interesting
<montjoie> so mdio bus is not registered
<montjoie> oh
<MoeIcenowy> montjoie: no new debug infos
<montjoie> and no init_phy ?
<montjoie> :) forget to add __func__, but at least phy_node exists
<MoeIcenowy> montjoie: (null) of_phy_connect
<montjoie> try this
<montjoie> its look good otherwise
<montjoie> and nodes on the board DT ?
<montjoie> perhaps the DT node are not well set
<montjoie> could you regive me a link to your nodes ? (seeing all your emac node)
<montjoie> without MDIO read, no PHY can be found
<montjoie> oh
<MoeIcenowy> montjoie: no any debug output...
<montjoie> for dumping all address
<montjoie> set reg = <0> also
<montjoie> with that we see what mdio see
<montjoie> and paste the resulting dmesg
<montjoie> patch incming:)
<montjoie> sorry mdio.c
<montjoie> go in mdio_read of stmmac_ethtool and add a pr_info to print all reads
<MoeIcenowy> montjoie: what will you consider about this bug?
<montjoie> you could try
<montjoie> MoeIcenowy: so it works now ?
<montjoie> MoeIcenowy: yes the init phy is done when netdev is "opened"
<MoeIcenowy> montjoie: stmmac_init_phy is even not called...
<montjoie> you need it yes
<MoeIcenowy> montjoie: sun8i_power_phy is not called at all
<montjoie> in all phy functions
<montjoie> MoeIcenowy: add pr_info to my code
<MoeIcenowy> montjoie: maybe something wrong prevents sun8i_power_phy being called?
<MoeIcenowy> montjoie: https://pastebin.anthonos.org/view/5692bdd4 here's the kernel log
<MoeIcenowy> montjoie: P.S. in BSP source code something is read from SID then written to clk register...
<montjoie> it is enabled by sun8i_dwmac_power_internal_phy if internal_phy flag is set
<montjoie> the internal phy is modeled in it
<montjoie> in sun8i-h3 emac node
<MoeIcenowy> montjoie: when will the CLK_BUS_EPHY and RST_BUS_EPHY be passed?
<montjoie> source
<montjoie> I mean BSP code
<montjoie> MoeIcenowy: do you have compared value set in syscon by BSP and mine ?
<MoeIcenowy> montjoie: I used 1 for phy reg
<montjoie> 0 is for PHY DHCP:)
<montjoie> yes reg = <1>;
<wens> MoeIcenowy: montjoie means the "register" property in the phy node under dwmac, not the syscon
<montjoie> in DT, what address is set for phy ? (try 0)
<montjoie> no user manual for v3s ?
<montjoie> could you paste dmesg ?
<montjoie> MoeIcenowy: which compatible dt do you use
<MoeIcenowy> montjoie: ping

2017-02-19

<MoeIcenowy> oh montjoie is not here
<MoeIcenowy> montjoie: ping, stmmac on V3s cannot scan the internal PHY (V3s do not support external PHY)
<MoeIcenowy> montjoie: testing dwmac-sun8i on V3s

2017-02-18

<MoeIcenowy> montjoie: I got a V3s board with ethernet port now. maybe I should try dwmac-sun8i there?

2017-02-17

<montjoie> yes datasheet speak about EMAC so I keep it
<montjoie> ah ok the question was GMAC vs EMAC
<montjoie> it's the same
<BroderTuck> montjoie: is it DWMAC as in 'config DWMAC_SUN8I', GMAC as in 'tristate "Allwinner sun8i GMAC support"', or EMAC as in "Support for Allwinner H3 A83T A64 EMAC ethernet controllers" ?
<montjoie> argh
<montjoie> oen comment from mripard force me to add another big cleanup patch
<montjoie> now time to code dwmac-sun8i v2
<beeble> montjoie: they have to be picosecond steps. they only question is if its a 1ns or more of a 2ns range you get with the register. i would guess its -1 to 1 ns for the 5bit register and -0.5 to 0.5 for the 4bit
<wens> montjoie: nope, that is a question for allwinner
<montjoie> wens: any idea for my tx/rx delay question ?
<montjoie> so MoeIcenowy you should change the emac comptable to h3 and not a64
<montjoie> perhaps syscon register is different
<MoeIcenowy> montjoie: yes
<montjoie> no user manual for R40 ?
<montjoie> MoeIcenowy: show me your DT patch
<MoeIcenowy> montjoie: dwmac-sun8i failed to work on R40...
<montjoie> it seems that I need to patch my driver for an additionnal regualtor
<montjoie> MoeIcenowy: good question
<MoeIcenowy> montjoie: how for more than one regulators?
<montjoie> see example in bpim2+ DT (or pine64)
<MoeIcenowy> montjoie: how to specify regulators for it?
<beeble> montjoie: approximately 60ps steps. but thats due reasoning not measuring. don't have equipment with that OCOCresolution
<montjoie> yes
<MoeIcenowy> montjoie: can dwmac-sun8i enable/disable regulators now?
<montjoie> wens: mripard what can I do for the tx/rx delay, each time someone ask for "what is the units" and datasheet doesnt give anything

2017-02-15

<terra854> montjoie: But i don't see ethernet activity on my Pine
<terra854> montjoie: Not sure if it's booted or not
<terra854> montjoie: Kernel fails to boot for some reason...
<montjoie> and compiling on x86 show me some problem I should address
<montjoie> but I still expect some
<montjoie> all work on sun8i-emac was re-used so it reduce the surface of attack:)
<montjoie> yes
<montjoie> even if dwmac-sun8i is elss code, I expect some problem
<montjoie> for having a good sun8i-emac, 5 versions where needed
<montjoie> there will be some comment when I will send it
<montjoie> terra854: clearly no way fo 4.11
<montjoie> it depend on what do your initrd
<montjoie> I do not use any initrd
<terra854> montjoie: How come initrd support is not turned on in your config?
<montjoie> 22:)
<montjoie> nothing to update, the main driver is not sent for the moment
<plaes> montjoie: :(
<montjoie> since there are not specific for sunxi, no CC
<montjoie> on netdev
<montjoie> yeah all cleanup patch are accepted, now comes the hard time
<montjoie> a long time ago it was based on it
<montjoie> its my minimal one
<montjoie> as a base yes
<terra854> montjoie: So use that config?
<montjoie> its mine
<montjoie> not enabled
<montjoie> I will immedialy fix that
<montjoie> sunxi_defconfig, but dwmac-sun8i is not included in it
<montjoie> you mean .config ?

2017-02-14

<montjoie> terra854: got mmc from linux-next
<terra854> montjoie: Your tree also has the USB and MMC drivers slated for 4.11/
<montjoie> terra854: stable yes
<beeble> terra854: montjoie tree does have both
<terra854> montjoie: The ethernet code i mean
<terra854> montjoie: So it is considered as stable?
<montjoie> yes
<terra854> montjoie: A64 Ethernet?
<montjoie> thanks
<montjoie> if you have non-h3/a64 with stmmac for checking that cleanup patch do not break anything
<beeble> montjoie: 936mbit in both directions. like yesterday. nothing obvious broken. but will keep it running
<montjoie> its the final version, no more code todo
<beeble> montjoie: thats not criticism, i just want to know what i'm testing against :)
<beeble> montjoie: thats just a rebase?
<montjoie> just updated https://github.com/montjoie/linux/tree/stmmac-sun8i-wip if people want to test
<montjoie> peripherals ?

2017-02-13

<montjoie> my h3 board (bpim2+) is worst 100/150
<montjoie> on my pine64 I got less Tx 500 RX 700 at max
<beeble> montjoie: is this roughly the same as with the realtek on your pine/h3?
<montjoie> thanks beeble
<beeble> montjoie: tested your stmmac-sun8i-wip-next-20170210 with a micrel phy. plain iperf3 without any additional settings/tuning 936 in both directions
<montjoie> terra854: no ethernet for 4.11
<montjoie> I need to finish some todo but I will try
<MoeIcenowy> montjoie: can you send out dwmac-sun8i in 4.12 merging window?
<montjoie> even dwmac-sun8i is very usable now
<MoeIcenowy> montjoie is WIP on making it better
<MoeIcenowy> wait for montjoie ;-)

2017-02-10

<montjoie> apritzel: still 5 cleanup patch to launch:)
<montjoie> peppe answered fast for me:)
<apritzel> montjoie: ah, well done, so now for the real stuff?
<wens> montjoie: he has his own work system
<montjoie> but at least, most of cleanup was included
<wens> montjoie: yup
<montjoie> dmiller love to apply patch without telling you:(
<montjoie> apritzel: perhaps your work need to be set in WIP/mainlining
<apritzel> montjoie: and I am close to get cpufreq working on top of SCPI as well
<montjoie> in fact my problem is "no cpufreq" on my pine64 and I believed that it is THS that do that but perhaps I am wrong
<montjoie> yes megous patch
<montjoie> plaes: agree with an entry "stale driver" ?
<montjoie> because the matrix still got a link to WIP
<plaes> montjoie: my bad :(
<montjoie> perhaps it is better to create an entry "stale driver"
<montjoie> It seems that THS got removed from WIP

2017-02-09

<tkaiser> montjoie: In case I could further help, just ask. Now time to prepare barbecue (Gigot! Am currently in the South of France on vacation) but I'll real backlog tomorrow and answer if I can :)
<tkaiser> montjoie: At least when you're in 'passive benchmarking' mode trusting in common benchmark tools like iperf or iperf3 (I prefer the latter since reporting 2 second values and also count of retransmits)
<tkaiser> montjoie: Please read through 2nd post of this here to get the idea why you most of the times don't test your driver but something else: https://forum.armbian.com/index.php/topic/1917-armbian-running-on-pine64-and-other-a64h5-devices/
<tkaiser> montjoie: Another annoying relationship is compiler settings benchmark tools like iperf/iperf3 have been built with. I got different numbers with iperf3 with otherwise identical environment when comparing Debian Jessie (GCC 4.9) vs. Ubuntu Xenial (GCC 5.4) with distro packages. Numbers in one direction were different since iperf3 on Xenial behaved multithreaded while acting single threaded on Jessie (and being bottlenecked by
<tkaiser> montjoie: In case you have any cpufreq scaling working use performance governor, in case you're using any cpufreq less than 1200 MHz on H3 change this and always run htop in another shell.
<tkaiser> montjoie: For network performance tests you have to take care what you're measuring in reality. Common tools like iperf/iperf3 (and all the others) on SBC are easily bottlenecked by lack of CPU horsepower.
<montjoie> with the new dwmac-sun8I
<montjoie> TX/RX
<montjoie> ElBarto: on pine64 for the moment I got 500/700