<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"...
<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>
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
<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>
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