2018-01-27

<montjoie> icenowy[m]: if the copatible isnt used, go!
<icenowy[m]> montjoie, mripard: can I change the EMAC compatible string on V3s from sun8i-v3s-emac to sun8i-v3-emac?

2018-01-25

<montjoie> I confirm (1), do not trust allwinner source, try them (remember allwinner crypto engine doing RSA in CBC mode)

2018-01-15

<montjoie> H6 usermanual, no more info. end of knowledge on that topic:)
<KotCzarny> montjoie: got any pointers?
<montjoie> if Ac200 support it , why realtek dont ?
<montjoie> KotCzarny: ephy datasheet in H6 speak that internal PHY support WoL
<KotCzarny> montjoie would be an expert to answer that question

2018-01-09

<icenowy[m]> montjoie: (restore the interrupt context) the PHY switch bit should be always 0
<icenowy[m]> montjoie: P.S. the H6 MAC control register in syscon has a internal/external PHY switch register, which needs to be always set to 0
<montjoie> icenowy[m]: thanks, I will give you crypto patchs soon for test
<icenowy[m]> montjoie: the phy issue of H64 is really hw issue

2018-01-08

<montjoie> and related fun fact, H5 do more RSA stuff than usermanual say
<montjoie> icenowy[m]: could you ask your allwinner contact why RSA/ECC was removed from H3 specs (manual/datasheet) ?
<icenowy[m]> montjoie: ignore the Pine H64 dwmac issue now... tllim says it might be hw problem

2018-01-07

<montjoie> BenG83: could you show me your "ip a"
<montjoie> (unrelated, you could add CONFIG_REALTEK_PHY)
<montjoie> BenG83: and the random register fail is interesting
<montjoie> BenG83: so lots of multicast address
<BenG83> montjoie, I added your debug output:
<icenowy[m]> montjoie: tried 0
<montjoie> icenowy[m]: do you know which part exactly return ENODEV in of_mdiobus_register_phy ? (are you sure the phy addr=1 (try 7))

2018-01-06

<icenowy[m]> montjoie: it should fail at of_mdiobus_register_phy
<montjoie> icenowy[m]: could you add some pr_info in drivers/of/of_mdio.c of_mdiobus_register() for knowing which part fail ?
<BenG83> montjoie, thank you
<montjoie> BenG83: could you add some pr_info in sun8i_dwmac_set_filter() or I will do a patch for you in some minutes (need to
<BenG83> montjoie, do you have an idea what causes
<montjoie> I need the err to know which part of of_mdiobus_register fail
<montjoie> icenowy[m]: could you show me your dtb ?
<montjoie> reading of_mdiobus_register code seems to show some PHY node handling
<montjoie> (and sorry for the delay flooded by children NMI)
<montjoie> icenowy[m]: could you add the err printing at line drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c:241 ?
<montjoie> MDIO is done before exactly
<montjoie> icenowy[m]: the PHY is indepandant of the MDIO bus
<montjoie> the dev_err
<montjoie> could you hac the code for printing the err ?
<montjoie> let me check the code
<montjoie> could you show me the dts ? check the mdio compatible
<icenowy[m]> montjoie: what happened if "dwmac-sun8i 5020000.ethernet: Cannot register the MDIO bus"
<montjoie> time to migrate to a vger list ?

2018-01-04

<[TheBug]> you would have to wait and ask one of the dev guys, like wens or montjoie I am not sure what is needed my self tbh
<montjoie> Guest72290: read the user manual for registers detail
<Guest72290> montjoie: but at which address they are mapped in address space?
<montjoie> Guest72290: you need to use MDIO registers from EMAC

2018-01-03

<montjoie> ou can see it with the distccmon
<montjoie> BenG83: distcc loadbalance by default, you just need to have -j = numcores
<montjoie> If I remember I go for 11(main pc) to 8min with (opipc and a83t(1core) and main PC)
<montjoie> notbad
<montjoie> BenG83: i use basic distcc. just added node in priority order in DISTCC_XXX=""
<BenG83> montjoie, do you use distcc with some load balancing setup?
<montjoie> BenG83: I have started to use distcc, I have some siginifiant perf boost for linux compile

2018-01-01

<montjoie> trying my cubie2 after near one year... nothing work (could not find pctldev for node /soc@1c00000/pinctrl@1c20800...)
<montjoie> oups I wrote new instead of malloc
<icenowy[m]> montjoie: I think new just takes a class name
<willmore> montjoie, happy new solar orbital period to you, too!
<montjoie> happy = new(sizeof(struct year))

2017-12-31

<montjoie> icenowy[m]: wens thanks, will do it
<wens> montjoie: move the compatible out of sunxi-h3-h5.dtsi and into the two h3/h5 specific dtsi files

2017-12-30

<icenowy[m]> montjoie: a usual method is have no compatible in sunxi-h3-h5.dtsi
<montjoie> just I override the comaptible in sun50i-h5.dtsi
<montjoie> icenowy[m]: the base is in sunxi-h3-h5.dtsi
<icenowy[m]> montjoie: I think it's ok
<montjoie> yeah, datasheet are not real datasheet:)
<montjoie> "can" in term of standard
<montjoie> wens: since I need two compatible for H3/H5, can I override &ccrypto {compatible =""} in h5 node ?
<montjoie> yeah finaly got my H5 running (and crypto engine on it)
<icenowy[m]> montjoie: Ethernet on a SoPine w/ Baseboard doesn't work at current linux-next

2017-12-29

<jack> montjoie: for the SMP support, or are those the ones you're talking about
<jack> montjoie: where did the patches get sent too? I've been using ones cribbed from the tbs repo

2017-12-28

<ElBarto> montjoie: will do, but what is your view on this ?
<montjoie> but my play got a "vinyle scratching", ethernet is so unstable, that compile on NFS is ....
<montjoie> vagrantc: patch sent by Mylene for Linux
<vagrantc> montjoie: does that require patches in linux, u-boot, or both?
<montjoie> wow, now a83t have 8 core, time to play "master of universe" when lauching some gentoo emerge!
<montjoie> ElBarto: for renaming the pinctrl name to emac? why not, you can try
<ElBarto> montjoie: thoughts ? should I or kevans91 submit a patch ?
<ElBarto> montjoie: but doesn't the a83t datasheet is wrong and describe gmac from a20 ?
<montjoie> anybody know how to enable a regulator with /sys/kernel/debug/regulator/xxx ?
<montjoie> ElBarto: I agree, but the datasheet said "gmac" and everybody speak "emac"
<ElBarto> montjoie: re gmac ?
<montjoie> jernej: rtc doesnt work ?
<montjoie> but not as stable than before
<montjoie> jernej: the following hack bring back ethernet https://paste.pound-python.org/show/6BlmwcE60z0o4GrbAMUU/
<montjoie> Now I know I am not the only one, I should mail
<montjoie> but didnt understand what is broken
<montjoie> jernej: I know the problem, the add of AXP to DT
<jernej> montjoie: still doesn't work
<montjoie> jernej: yes CONFIG_REALTEK_PHY=y
<jernej> montjoie: which config has to be set for realtek phy driver?
<montjoie> jernej: even without realtek PHY driver, it use the generic one
<montjoie> jernej: so its broken for you also ?
<jernej> montjoie: I can't get IP address though dhclient
<ElBarto> montjoie: was the naming of the pin function to gmac for a83t-emac intentional ?
<montjoie> jernej: thanks, the best I can have is stable ping(no loss) but bandwitch near to 0
<montjoie> jernej: do you have ethernet working on last linux-next ?
<jernej> montjoie: me
<montjoie> anybody here with a bpim3 ?
<montjoie> oups
<montjoie> the kernel does not start at all now
<wens> montjoie: ^

2017-12-27

<pgreco> montjoie: I've seen that happen to people on #fedora-arm
<montjoie> both a64 boards do "mmc0: Card stuck in wrong state! mmcblk0 card_busy_detect status: 0xe00"
<smaeul> montjoie: do you have any idea when the date jumped?
<montjoie> in fact it's normal, date print 18 feb 2113
<montjoie> wow my pine64 uptime is 24855 days

2017-12-26

<KotCzarny> montjoie: then again, how much code would it require (in ~lines) to write basic bare-metal driver that would only need to check for specific packets?
<montjoie> KotCzarny: do not know, according to usermanual, it is PHY which do that part, and it is not documented
<KotCzarny> montjoie: how much code would it need to implement wake-on-lan on baremetal?

2017-12-22

<montjoie> probably
<montjoie> pfff I am cursed, all my boards have problem, bpim64 "waiting for root"...

2017-12-19

<montjoie> I have set regulator_debug and now lots of fail appears https://pastebin.com/2uLDthzN
<montjoie> wens: could you share your uImage/dtb for a83t ? for being sure where my problem is
<montjoie> embed-3d: patch was sent for multi cpu

2017-12-18

<montjoie> I have diffed sunxi_defconfig and mine and nothing AXP related is missing
<montjoie> wens: even linux-sunxi fail on my a83t https://pastebin.com/QRVxu6QN the sw is powered!
<montjoie> and I target more compilation power when all boards will be up via distcc
<montjoie> maz: I clearly target the bonus point for "boot test"
<maz> montjoie: I'm not saying you should try and replicate the kbuild robot, which probably uses more HW than you will ever be able to acquire...
<montjoie> I have only 8 core:(
<maz> montjoie: that's pretty restrictive. any change to the core code has a major potential for breaking your toys... and in my experience, that's what happens most of the time.
<montjoie> aka "all things that can break my boards"
<montjoie> maz: I target all patchs for sunxi/stmmac
<maz> montjoie: trying every single patch would be a gigantic task. but no later than yesterday, I got a nice message from the robot informing me that I had broken arm64... Always a pleasure! ;-)
<maz> montjoie: i don't think the robot picks up *everything*. it picks up longer series, and branches from korg.
<montjoie> maz: I confirm, I have found a patch sent some hours ago which did not compile under arm64, and no kbuild robot message...
<montjoie> and "do you have added warnings"
<montjoie> and my goal is to add boot test after
<montjoie> maz: I sent at least a mail that should said to me "do not apply" and never get it
<maz> montjoie: kbuild definitely builds ARM. I get a nastygram often enough when I break it! ;-)
<montjoie> by mail I mean patch/serie
<montjoie> Since kbuild_robot does not build ARM, I have done mine which do. If anyone is interested in testing it, send mail to lkml at montjoie.ovh
<montjoie> not so bad without optimisation
<montjoie> 300 400Mbit yesterday
<wens> montjoie: performance is really low on the bpi m3
<montjoie> wens: what to you mean by "tx sucks" ?
<wens> montjoie: could you try increasing the voltage for DCDC1?
<montjoie> I will try sunxi-next
<montjoie> it worked one time, and then it always fail
<montjoie> I have problem since I have worked on ref_sw as you asked
<montjoie> wens: I hit the same problem with recent linux-next (and your patch)
<montjoie> so now with proper config I hit problem, but I do not understand why you do not hit the same problem
<montjoie> I have switched to mainline uboot int he same time
<montjoie> it worked before, because uboot enabled the proper regulator
<montjoie> and I think I hit the problem later because of not having any AXP config enabled
<montjoie> and clearly my problem is PHY underpowered
<montjoie> on my 20171103, If I simply copy over bpim3 dt from 1102 it works again
<montjoie> emac ones
<montjoie> in fact I test my linux-next branch
<montjoie> and for testing I stack my patch, so why I can go to 4.15-rc1
<montjoie> wens I have badly explain myself, at start of modifying syscon, the default syscon is good
<wens> montjoie: on the cubietruck-plus, which doesn't need delays, it's 0x00000006
<wens> montjoie: my working value is 0x00001CE6
<wens> montjoie: and the bpi-m3 needs proper rgmii rx and tx delays set. so the default syscon register value is not going to work
<wens> montjoie: that hardly makes any sense. the axp patches were merged for 4.15-rc1, while the emac dts patches are for 4.16-rc1

2017-12-17

<montjoie> wens: my problem comes with ARM: dts: sun8i: a83t: bananapi-m3: Add AXP813 regulator nodes
<montjoie> BenG83: compatible = "snps,dwmac-mdio";
<montjoie> BenG83: the MDIO node need the compatible
<BenG83> montjoie, yes give me a sec
<montjoie> BenG83: could you paste the DT EMAC node ?
<montjoie> and it reduce heavily the patch
<montjoie> IgorPec: why did you backport timer change ?
<montjoie> which diff ?
<montjoie> IgorPec: which part (dt/code) you fail to backport ?
<IgorPec> montjoie: you have a working dwmac on 4.14.y? I am trying to backport from 4.15.y but no luck so far
<montjoie> good = bus_emac 1 1 300000000 0 0
<montjoie> wens: it's a clk problem "bus-emac 2 2 300000000 50000 0" <- bad
<montjoie> wens: it's not syscon since it get the default value
<montjoie> nullptr deref
<montjoie> additionnaly axp20x pinctrl crash on my last try
<montjoie> not yet
<montjoie> so seems kernel related and not uboot related
<montjoie> wens: after booted a recent kernel, I need to a real power off for network works again

2017-12-16

<montjoie> so good news it's not an hardware problem, but something is bad with recent kernel/uboot
<montjoie> wens: uboot 2017.7 + 4.6.0rc4 no packet drop:)
<montjoie> anarsoul: under uboot or after ?
<montjoie> wens: I still get packet loss with your uboot
<montjoie> I have put old uboot and it stop at boot
<montjoie> icenowy[m]: not change delay at all
<icenowy[m]> montjoie: delays tweaked?
<wens> montjoie: but it's the emac patches I sent
<montjoie> iperf is impossible
<montjoie> I have changed power supply and still lots of packet loss
<montjoie> wens: which uboot do you use with your bpi M3 ?

2017-12-12

<wens> montjoie_: mine looks ok, but I'm not doing a lot of traffic
<wens> montjoie_: hmm

2017-12-11

<montjoie> 52%
<montjoie> wens: on my bpim3 I have lots of packet lost

2017-12-06

<montjoie> anyway I have found gigabit board with this property, I will send a patch for remove it
<wens> montjoie: I could argue that this is part of the platform glue layer, because it exists outside of the PHY, and is probably an inverter along the path
<montjoie> if this register (LED low/high) affect also non-internal PHY, it must be kept on emac node
<montjoie> I just need to verify that it affect only internal PHY
<montjoie> I know
<montjoie> it is asked by andrew
<wens> montjoie: to be fair, I don't see any point in moving the property either
<montjoie> ok I will split in two, move as asked, and then try to change...
<montjoie> because its cleaner
<montjoie> Instead I could just remove leds,allwinner from board DT and still need to change dwmac-sun8i
<montjoie> and I need to revert the patch dmiller applied
<montjoie> mripard: what was asked is to move allwinner,leds from &emac to a new &internal_phy in board dT
<mripard> montjoie: everyone agrees to one thing, and you want to do something else?
<mripard> montjoie: you're not going to get anywhere changing the binding all the time
<montjoie> and easy my allwinner,leds emac-to-phy patch
<montjoie> wens: it will clean heavily DT
<wens> montjoie: not much point to it
<montjoie> wens: since mostly all H3 boards with internal PHY use allwinner,leds-active-low, what do you think about set is as a default, and then create leds-active-high

2017-12-05

<montjoie> they have changed the crypto code a bit (and they use mainline sun4i-ss)
<icenowy[m]> montjoie: H6 EPHY is the one in AC200

2017-12-04

<montjoie> wink[AW]: thanks we see it
<icenowy[m]> montjoie: but it seems that the EPHY register fields in syscon are bogus
<montjoie> Yes I wanted it to see if we can do more with EPHY
<montjoie> :D
<icenowy[m]> maybe montjoie?
<icenowy[m]> montjoie: ^

2017-12-01

<jernej> montjoie: ^^^
<icenowy[m]> montjoie: for ATE it's said that it's connected to an internal I2C

2017-11-30

<montjoie> arg
<wens> montjoie: he already did, check his tree
<montjoie> no he said that he wants to
<wens> montjoie: davem already applied your patch
<montjoie> wens: mripard a conlusion on allwinner,leds-active-low ? do I modify DT ?
<montjoie> EPHY
<montjoie> I wonder if using interupt could enhance perf
<apritzel> montjoie: the H6 is sun50iw6p1, in case you wonder
<apritzel> montjoie: looks indeed like MDIO: https://pastebin.com/w9YFst3k
<montjoie> perhaps register in 8.13 are by MDIO
<montjoie> there are more gister in ATE (3.20) but no base address for it
<montjoie> more EPHY registers are documented beyong syscon
<montjoie> I speak about H6
<apritzel> montjoie: and this EPHY things probably relates to the ATE (chapter 3.21)
<apritzel> montjoie: the BSP .dtsi lists the usual EMAC_PHY register in the syscon: <0x0 0x03000030 0x0 0x4>
<montjoie> in H6 user manual I see EPHY datasheet, I wanted to find if this doc is backward compatible. But the EPHY is in ATE and I do not find any base address for it

2017-11-25

<wens> montjoie: but if i run mii info after setting the ip, ping works
<wens> montjoie: after setting ipaddr and netmask, ping doesn't work
<wens> montjoie: have this funny issue on uboot with a83t emac

2017-11-24

<wens> montjoie: I just did, and it seems to work well
<montjoie> wens: will try uboot also
<wens> montjoie: argh, I meant U-boot, sorry
<montjoie> on next-20171018 at least it worked!
<montjoie> wens: yes
<wens> montjoie: can you try it on an h3 board with internal phy?
<montjoie> I am setting my own LAVA lab, so tftp (via uboot emac) is the main way of test
<montjoie> wens: yes on pine64 or bpi64
<wens> montjoie: have to used u-boot emac recently?
<montjoie> oups I acked
<montjoie> wens: I sent the patch "arm64: allwinner: a64: add Ethernet PHY regulator for several boards" for that
<wens> according to icenowy[m] or montjoie, ATF does that
<montjoie> and on linux-next :)

2017-11-23

<montjoie> mripard: it is what I looking for:)
<mripard> montjoie: most of them have been either already sent or merged though
<montjoie> mripard: this repo have lots of work for a83t...
<montjoie> thanks I will test it
<montjoie> wens: any plan on when to do it ? :)

2017-11-22

<vagrantc> wens, montjoie: i tried pulling patches from linux-master to add back in dwmac-sun8i ... and the ethernet was recognized, but not functional ... would the emac vs. phy bindings likely cause that?
<montjoie> I agree
<montjoie> no
<montjoie> wens: where do you want it ?
<montjoie> arg! I will fix it
<wens> montjoie: the bindings put the property under the emac node, while the driver expects it under the phy node
<wens> montjoie: the dwmac-sun8i bindings don't match the driver for allwinner,leds-active-low

2017-11-18

<KotCzarny> aalm: montjoie is local emac master
<montjoie> wow one VM with 1G RAM, useless
<montjoie> virtualization without RAM is useless

2017-11-17

<montjoie> I have problem with my pine64 with the same power supply...
<montjoie> I have buyed compoments for using an ATX
<montjoie> perhaps the power suply is dieing
<montjoie> the kernel were I am sure to have network tested before sending patch, doesnt have network yesterday
<montjoie> I have the impression that network is random on it
<montjoie> even my old working kernel is slow
<montjoie> network work but so slow
<montjoie> I have weird problem on all my board, getting mad
<montjoie> I have updated to 2017.11
<montjoie> bpim3 is my only board with delay for test
<montjoie> it was set since the beginning
<montjoie> delay ?
<montjoie> arg still no ethernet something is weird
<montjoie> I feared to do an error
<wens> montjoie: the schematics should be pretty clear
<montjoie> ok thanks I will try
<wens> montjoie: the switch is routed externally from swin, which is connected to dcdc1 on bpi-m3, and output through swout
<wens> montjoie: it's reg_sw
<montjoie> wens: reg_dc1sw does not exists in axp81x
<wens> montjoie: it's powered from dcdc1, _via_ sw

2017-11-16

<montjoie> wens: are you sure that bpim3 PHY is powered via dcdc1 ?
<montjoie> wens: I confirm that a83t need phy-supply
<montjoie> mripard: do you want that I try (CC you and wens in the process ?)
<wens> montjoie: i think there was an attempt before, but I don't know the history there
<montjoie> and so add it to all sunxi part in MAINTAINERS
<montjoie> wens: mripard could it be the time to ask for a kernel.org mailing list ? (just see your complaint on googlegroup:))

2017-11-15

<willmore> montjoie, depends on the board. 3A seems safe. But, I suggest fusing *before* the DC/DC board. Because Polyfuses have a small voltage drop under load. Before the DC/DC it's not a problem. After the regulator it's more of an issue.
<montjoie> willmore: any idea of the maximum allowed current ? 3A ?
<willmore> montjoie, you're welcome. Thanks for all of your work!
<montjoie> willmore: thans for the polyfuse, will try with it
<montjoie> choice between ethernet and USB3...