<willmore>
lurchi_, are yo using the BSP kernel or mainline? montjoie has stopped work on the driver for mainline and is instead working on adapting the existing mainline driver to work on Alwinner chips. You might look to his repo.
<montjoie>
does someone know how to magic sysrq over uart ?
2017-01-28
<montjoie>
plaes: I will clean
<montjoie>
probably hwrng will never come to mainline
<montjoie>
I will update hwrng
<plaes>
montjoie: btw, you have two entries there - sunxi-ss and hwrng
<montjoie>
plaes: and thanks for using good wiki commit log, I hate people that change something with message "status matrix":)
<montjoie>
mirceac: wens has an a83t tree
2017-01-25
<wens>
montjoie: op-tee doesn't have much code for the a80, so it's probably equally broken :/
<wens>
montjoie: the problem is just setting the core to non-secure does not fully secure the SoC
<montjoie>
wens: if you need some help for securing A80, optee support it with some ASM, perhaps it could help you
2017-01-21
<montjoie>
MoeIcenowy: I have a fix to push for that
<MoeIcenowy>
montjoie: /home/icenowy/git-repos/cryptotest/kernel/cryptotest.c:133:8: error: implicit declaration of function 'crypto_alloc_ablkcipher' [-Werror=implicit-function-declaration]
<MoeIcenowy>
montjoie: "sun4i-ss 1c15000.crypto-engine: Die ID 7" is it an expected dmesg output?
<MoeIcenowy>
montjoie: do you have a way to test sun4i-ss?
<MoeIcenowy>
montjoie: I tried to change phy_mode to rgmii and the internal_phy property in sun8i-emac to RGMII thing.
<MoeIcenowy>
montjoie: maybe it put a PHY designed as 1000Mbps there, then tested, but found the performance is much low than 1000Mbps, then named it 100Mbps
2017-01-20
<montjoie>
so even opipc could in theory gain some perf beyond 100Mbit/s
<montjoie>
like I just said before, it is interesting that the internal phy accept RGMII and negociate gigabit link
<montjoie>
in fact I needed to chaneg syscon and reset before probing MDIO
<montjoie>
wens: yes, but I believed that the probem would be a priority problem
<wens>
montjoie: 0 is kind of like a broadcast address
<wens>
montjoie: fyi, the rtl8211e responds to both 0 and the phy address programmed through the phyaddr pins
<montjoie>
interesting that the internal phy branded as 100 could negociate 1G
<montjoie>
I note "change syscon / reset the board then register MDIO bus"
<montjoie>
still bad perf
<MoeIcenowy>
montjoie: congrats ;-)
<montjoie>
it is the return of great realtek phy:)
<montjoie>
mdio_reset should fix that
<montjoie>
MoeIcenowy: I think the problem is that stmmac register the mdio before any int/extphy choose, and so libphy probe internal phy and get stuck on it
<montjoie>
by EPHY you means internalphy ?
<MoeIcenowy>
montjoie: I think you should try to probe the phy id of both internal and external phy with sun8i-emac...
<montjoie>
and something in my driver still select internal phy
<montjoie>
MoeIcenowy: but certainly the ac200 is the internal phy
<montjoie>
just need to boot my opipc
<montjoie>
the Id can be printed via phydev->id
<montjoie>
I use 0 also
<montjoie>
but another problem, I wrongly said that I use reg 1 with stmmac
<montjoie>
the phy_print_status do not print it
<montjoie>
need to print it
<montjoie>
seems weird
<montjoie>
physically it can, if only one is powered
<montjoie>
yes
<montjoie>
multiple phy can be on that bus
<montjoie>
EMAC speak on the MDIO bus
<montjoie>
and so it is why my "probes just after" give me ac200 for slot 0
<montjoie>
but if you probe 1, it become the default
<montjoie>
and 0 is the dhcp for phy, so it seems realtek answer first
<montjoie>
so two phy wired
<montjoie>
with stmmac, in DT I set 1
<montjoie>
I think to see the problem, with sun8i-emac the phy slot is 0
<montjoie>
I am mad
<montjoie>
lol, according to loghost it seems that yesterday I booted with sun8i-emac and realtek phy was here
<montjoie>
if it give me random id, what a chance to alsways have the same
<MoeIcenowy>
montjoie: seems that it's impossible to be an AC200...
<montjoie>
its the phylib that does that
<montjoie>
just thinked that I have a loghost for all log, and in august the board has a RTL8211E Gigabit Ethernet
<montjoie>
good perf was in the past in my memory
<montjoie>
I got the same perf with sun8i-emac now
<montjoie>
the furthermore strange thing, is that I am nearly sure to get good perf when working on sun8i-emac on that board
<montjoie>
just in case , other RGMII ?
<MoeIcenowy>
montjoie: one of my friend in Sinovoip says that it's RTL8211D/E
<montjoie>
but the code size is not large
<montjoie>
MoeIcenowy: yes more dedicated since dma register are different
<MoeIcenowy>
montjoie: I think this glue is the most dedicated glue among stmmac glues?
<montjoie>
first I need to send the 15 patch against stmmac I had
<KotCzarny>
montjoie: call it efficiency patch
<montjoie>
yes it work, but I wanted to test the "speed patch"
<montjoie>
MoeIcenowy: you can find it on github, and I wanted to test gigabit on H3
<MoeIcenowy>
montjoie: could you at first sort out your sun8i-stmmac driver? ;-)
<montjoie>
where do come this ac200 phy
<montjoie>
but i want to know the end of this PHY mistery
<KotCzarny>
montjoie: at least you can go back to real boards ;)
<montjoie>
raaaah I forgot a ++ and now my bpim2+ is stuck scanning phy, and no remote power off:(
<montjoie>
and the source dump someone give yesterday show the reset function commented
<montjoie>
seems not production safe:)
<montjoie>
but their phy driver I try block the phy
<montjoie>
verified from BSP sources
<montjoie>
441400
<MoeIcenowy>
montjoie: I asked someone from Sinovoip
<montjoie>
but the phy id comes from somewhere
<montjoie>
didnt check yet
<montjoie>
I will add some debug to scan all phy slot
<montjoie>
ac200 for sure (phy id)
<MoeIcenowy>
montjoie: so what is it? ac200 or rtk phy?
<montjoie>
but the trouble fact is that I see a realtek chip on my board
<montjoie>
tkaiser: silkprint said banapi v1.1
<montjoie>
probably the loss on RX is due to CRC offload disabled
<montjoie>
strange, normally TX < RX
<montjoie>
ErwinH: 423 is with -R ?
<montjoie>
anybody with a running bpim2+ ?
<montjoie>
thanks for the test
<ErwinH>
montjoie: stmmac works on OrangePi PC2 as well.
2017-01-19
<tkaiser>
montjoie: They also sent out broken dev samples to the guys wanting to improve camera drivers. None of the boards sent was able to operate with their own camera (two small hand soldered resistors where on PCB rev 1.0).
<montjoie>
I will read tonight, it is remote
<tkaiser>
montjoie: What's written on the board as version?
<montjoie>
the other boards sent works
<tkaiser>
montjoie: At least I'm not surprised that BPi people are that 'smart' to send developers crappy hardware to ensure they can't support the board
<montjoie>
smell non production board
<montjoie>
the other board with AC200 is the homlet A83T
<tkaiser>
montjoie: V1.1 is the one from production batches, also RTL8211E equipped.
<montjoie>
it's a sample from foxconn, so perhaps its not a prod one
<montjoie>
I will check the hw version
<tkaiser>
montjoie: Between RTL chip and H3 it's printed 'BPi M2 Plus V1.0' (the broken version where camera doesn't work)
<tkaiser>
montjoie: My BPi M2+ has RTL8211E as usual
<montjoie>
and perhaps bad perf due to "handlded as generic phy"
<montjoie>
so bpim2+ has an allwinner ac200 PHY, no datasheet
<montjoie>
plaes: ok
<plaes>
montjoie: please send the notice to mailing list
<montjoie>
KotCzarny: not a realtek phy
<montjoie>
perhaps
<montjoie>
very strange this bpim2+ it is the only one where flow control is enabled
<montjoie>
plaes: your mmc fix work
<montjoie>
I am sure to has better perf before
<montjoie>
very strange
<montjoie>
bananapi m2+ have horrible perf 100Mb/s on a gigabit link
<montjoie>
june! its old, does he still work on this ?
<igraltist>
montjoie: i did it with old kernel like: cat /sys/class/thermal/thermal_zone0/temp
<montjoie>
igraltist: you mean via the sun4i_ts ?
<montjoie>
thanks
<montjoie>
I note your numbers for adding them as example in commitlog
<KotCzarny>
montjoie, yeah, 14677 with your patch, 35004 without
<montjoie>
as a client
<montjoie>
with ly patch the number should be less
<montjoie>
you could try to compare number of interupt
<KotCzarny>
montjoie: is there specific situation i should try?
<montjoie>
KotCzarny: you said yesterday you got only 280Mbit/s
<KotCzarny>
montjoie: 910/710 with the patch
<KotCzarny>
let's see montjoies patch
<montjoie>
terra854: native compiling also in early times, but on NFS
<montjoie>
terra854: cross compiling
<montjoie>
KotCzarny: or try directly the github repo
<KotCzarny>
montjoie: that patch also failed on 4.9.4
<montjoie>
plaes: will test
2017-01-18
<plaes>
montjoie, jonkerj: could you try the patch I posted on mailinglist on top of current mainline?
<montjoie>
ErwinH: for the moment sun8i-emac is the best choice
<montjoie>
it's that
<montjoie>
the hardware works, since it works with sun8i-emac
<willmore>
montjoie, does not work in the driver or on the hardware?
<montjoie>
for an unknow reason offload of RX CRC does not work
<montjoie>
500M both direction
<montjoie>
glorrrrryyyyy
<montjoie>
perhaps it could boost perf on other stmmac:D
<montjoie>
it seems that I found the bug which made stmmac slow
<montjoie>
stmmac use a lock in txclean, I pray it was the bottleneck
<ErwinH>
It's the same as with the H5 OrangePi PC2, with the driver/kernel from Xunlong it reaches 450mbit/s but with the driver from montjoie it runs at full speed (950mbit/s)
<montjoie>
ok
<montjoie>
but still twice as mine
<montjoie>
ouch 280:)
<KotCzarny>
montjoie: 860mbit when bpi-r1 is a server and 280mbit when its a client
<montjoie>
ok
<beeble>
montjoie: 928-940 rx/tx pretty much the same
<beeble>
montjoie: and sun9i
<montjoie>
beeble: ok I could wait
<beeble>
montjoie: rk3368, but can only try later today since it's in use right now
<montjoie>
it will help me:)
<montjoie>
if you could try
<montjoie>
cool, what iperf give you ?
<montjoie>
but in 100Mbit
<montjoie>
(official stmmac, so non-h3/a64)
<montjoie>
anybody here with a gigabit stmmac ?
<montjoie>
and it fail also on bpi+ if I remember
<montjoie>
opipc
<plaes>
montjoie: which board did you have?
<montjoie>
if someone found the missing patch, it must be sent for 4.10rc
<plaes>
montjoie, jonkerj o/
<montjoie>
like my cubie2
<montjoie>
wens: yes I just need to test one of it on a stmmac nonsun8i
<wens>
montjoie: i think you can send out some cleanup patches first
2017-01-17
<montjoie>
so anybody here tried optee on AW stuff ?
<montjoie>
the hard work is done
<willmore>
montjoie, good luck!
<montjoie>
yeah still some gaps I need to fullfill
<montjoie>
perhaps some function are missing:)
<montjoie>
and -d just segfault:D
<montjoie>
nothing that can help to identify for -S
<montjoie>
but I need to recheck
<montjoie>
so perhaps not a gmac4
<montjoie>
and get 0
<montjoie>
it try to read sysnopsys_id
<montjoie>
ETOOHACKEDBYALLWINNER
<montjoie>
dont know
<willmore>
montjoie, I was think of the the H3/H5/A64
<montjoie>
you means all other glued driver in stmmac dir ?
<montjoie>
these ?
<willmore>
montjoie, what generation of GMAC is on these chips?
<montjoie>
all stmmac driver use non-chainmode
<willmore>
montjoie, do all existing drivers use ring buffer mode instead of chain mode? chain mode is popular in Intel NICs, IIRC.
<willmore>
Unless montjoie feels that the framework of the driver will never allow full performance. Then there's room for arguement.
<willmore>
I think montjoie is on the right path. Get the existing driver to support the new hardware. Then improve that driver to make all hardware work better.
<montjoie>
KotCzarny: there are a dozen of glue to stmmac, porting them without hardware should be hard
<KotCzarny>
montjoie: maybe do the other thing, ie port stmmac to your driver?
<montjoie>
since chain_mode is an optionnal argument, perhaps nobody use it and so bad perf
<montjoie>
willmore: I need to, on pine64 the perf of stmmac is awful
<willmore>
montjoie, now do you port the improvements from the emac driver to the stmmac driver?
<montjoie>
jonkerj: bisected to a mripard commit in pinctrl BUT the last two kernel produce kernel crash and not mmc timeout
<jonkerj>
montjoie: did you manage to find the cause of the MMC error when running very recent kernel?
<montjoie>
plaes: fix uploaded
<montjoie>
jonkerj: sun8i-emac is in fact a modified dwmac and so the driver become a glue to the mainline stmmac driver
<montjoie>
:)
<plaes>
montjoie: last commit, you can now remove Ethernet Phy from the todo :P