<willmore>
montjoie, nope. PC, PC2, Pine64/2G, Zero, and One.
<montjoie>
same symptom with a recent next kernel, going back to gigabit does not work
<montjoie>
and does they work at Gigabit (and survive G->100->G)
<montjoie>
willmore: do you have any a83t ?
<willmore>
montjoie, okay, sorry, don't have one of those to help test.
<montjoie>
I have found an old working kernel, so, wens, I confirm my board work with gigabit BUT when going to 100m, going back to gigabit never work
<montjoie>
willmore: bpim3
<willmore>
montjoie, what board are you working on?
<montjoie>
50% to 80% packet loss
<montjoie>
even ssh does not work
<montjoie>
I will disable all RSB write to see what happen
<montjoie>
please try it, just in case of
<montjoie>
arg
<montjoie>
last time you didnt know;)
<montjoie>
wens: you are at gigabit ?
<montjoie>
and I am no the only one affected by this issue:)
<montjoie>
its not an hardware issue, with revert of the patch it worked at gigabit
<wens>
montjoie: I guess you could try removing the regulator stuff again, and also disable SW in U-boot, and see if it still works (vs dts without regulators + u-boot with sw on)
<montjoie>
wens: MoeIcenowy for the a83t 1G phy problem i have added debug to RSB https://pastebin.com/8Yqpxzhr so it seems that DCDC1 is on and sw bit is ok. What can I do ?
<willmore>
Thanks, montjoie.
<montjoie>
old but not obsolete!
2018-06-21
<montjoie>
sometime got bug, sometime algo got retired from datasheet
<montjoie>
benching distcc for compiling kernel with allwinner boards... not bad (18min with cubieboard2+R40+OpiPC)
<KotCzarny>
ask montjoie about CE status and bugs :>
2018-06-19
<montjoie>
so all stmmac/sunxi patchs will be tested
<montjoie>
I will send photo/schemas soon
<montjoie>
automated with LAVA for boot testing
<montjoie>
all boards are up for compile and I grab one by one after for boot test
<hlauer>
montjoie: Do you have the cpufreq driver running on a R40 device ? Made some DT entries, but are unsure about voltages.
<montjoie>
MoeIcenowy: the R40 usermanual about Crypto said i need to activate MBUS clock, but I didnt see in dt-bindings. Since you have done the R40 clocks, does I miss something ?
2018-06-17
<montjoie>
I'm damned
<montjoie>
pfff my R40 does not work at Gigabit but 100M
<montjoie>
\o/ I will can use sun8i-ce dedicated to SW
<montjoie>
MoeIcenowy: yes but R40 is enhanced A20. only trial will proove it
<MoeIcenowy>
montjoie: seems to be sun8i-ce according to document
<montjoie>
yes finaly R40 boot! now time to check ... sun4i-ss or sun8i-ce ?
<wens>
montjoie: turns out I accidentally removed the i2c pinctrl line when rebasing
<wens>
montjoie: I did something similar with the h64 wondering why the external rtc didn't work
<wens>
montjoie: no worries
<montjoie>
soory for the noise
<montjoie>
I miss the rule "wait longer before reporting because it always your fault"
<montjoie>
sensille: what status it has on ifconfig ?
2018-06-15
<montjoie>
will do, but I begin to have too many board to debug
<montjoie>
wens: what can I do ?
<wens>
montjoie: your axp pmic does not seem to be probing
2018-06-14
<montjoie>
wens: any idea for my R40 not having MMC https://pastebin.com/Bg0X4hpm ? I see that dwmac is deferred then probed but mmc is deferred and never reprobed
<montjoie>
pgreco: thanks but didnt see any critical difference
<montjoie>
I will try to update my github with last crypto driver today
<montjoie>
R0b0t1: crypto should came soon!
2018-05-16
<montjoie>
it works and should have detected this but my newborn freeze me last two month
<montjoie>
I should finish my maling list bot compile and test!
<montjoie>
unless I found the issue
<montjoie>
I will send a mail asking for revert
<montjoie>
two commit, removing only one lead to crash
<montjoie>
found the guilty for stmmac brokenness! like before, a synopsys guy
<montjoie>
could someone try linux-next and confirm that dwmac-sun8i is broken due to 4dbbe8dde8485b89bce8bbbe7564337fd7eed69f and 5f0456b43140af9413397cc11d03d18b9f2fc2fc
<montjoie>
especially if 486 have < 8M RAM
<montjoie>
not for a long time, since school professor understood rapidly that it was silly to ask studient to do java on 486
<montjoie>
I did some java on 486
<montjoie>
no a JVM must have memory contrainsts! BDSMJVM
<montjoie>
a windows for running the JVM...
<montjoie>
could be bad, they could try to qemu a windows
<montjoie>
hello! I am back to work! and two month after last boot... no network on H3. I love linux-next
2018-04-28
<montjoie>
icenowy[m]: ATE EPHY ?
<icenowy[m]>
montjoie: someone has verified that just set EMAC pinmux to PA on H6 and set RMII will make ATE EPHY work, as expected.
2018-04-23
<fredl_>
montjoie - I tried that actually using apt-file
<montjoie>
you could have checked Python.h on your precedent system and get the package owning it
<fredl_>
Was looking for fdt packages or something, thanks montjoie
<montjoie>
you miss python-dev
2018-04-22
<pgreco>
wens, yes, I remember talking about that with montjoie, when we were testing ethernet for the a83t
2018-04-06
<icenowy[m]>
mripard, montjoie: if I want to convert the syscon of A64 to a regmap exported by the sunxi-sram driver, how to do it?
<montjoie>
and we cannot ask marc/spinics/mail-archive to archive it ?
<montjoie>
mripard: why not a vger one ?
<montjoie>
mripard: wens perhaps its time to ask for a vger mailing list ?
<montjoie>
and mripard deny to use it for get_maintainer.pl
<montjoie>
because its not an official kernel ML address
2018-03-16
<icenowy[m]>
montjoie: I have thought a way to hack it -- use EL2 MMU to wrap the PCIe part; however implementing such a hack is beyond my knowledge level
<montjoie>
lots of people could want H6 for PCIe, they must know that it is buggy and probably not(never?) supported by mainline
<hanetzer>
montjoie: aye.
<montjoie>
icenowy[m]: go! life is too short for crappy hardware
<icenowy[m]>
mripard, montjoie: I'm thinking whether to fill the H6 PCIe box at the mainline status matrix with black
2018-03-13
<montjoie>
libv: I still use wiki for uboot and some board info (where are uart?)
<libv>
montjoie: no idea
<montjoie>
libv: what is the bandwith usage of linux-sunxi.org ?
<montjoie>
you could see my work "the lavabox"
<montjoie>
not myself but some coworker
2018-03-11
<montjoie>
both
<montjoie>
at least the H6 PRNG seems broken, and probably precedent also
<montjoie>
The more I read BSP, the more I think they never test crypto beyond "compile test"
2018-03-08
<montjoie>
icenowy[m]: yes guess correct, I saw your email:)
<icenowy[m]>
montjoie: is my guess correct?
<wens>
montjoie: what part exactly?
<hanetzer>
montjoie: hmm? as in, 'its fucked, don't bother' ?
<montjoie>
oh it seems that H6 will have the first black case in support matrix:(
2018-03-06
<codekipper>
montjoie: thanks...there is a discussion on the ASoC ml about this...I'll take a look later
<montjoie>
so probably a problem in free electron lab
<montjoie>
codekipper: the kernelci log seems to show that uboot does not work
2018-03-05
<montjoie>
raaah! RSA is redesigned on H6
<montjoie>
so now I have two way of doing AES (and XTS is exclusive to RAES)
<montjoie>
the most cryptic is the new RAES "algo"
<montjoie>
some more register write for start task
<montjoie>
BenG83: mostly compatible, the tasklist size element changed from cryptlen/4 to cryptlen
2018-03-04
<BenG83>
montjoie, yay :)
<montjoie>
ciphers are working on H6!
<montjoie>
ohh a 3rd clock is necessary
<montjoie>
mmh CE report no errors
<montjoie>
PRNG Id seemsto have changed
<montjoie>
I fear some contant changes
<montjoie>
argh DMA timeout for crypto engine on H6
<montjoie>
pff another FTDIwith RX/TX inverted
<montjoie>
BenG83 icenowy[m] do you have a link to where ae uart of pineh64 ?
2018-03-03
<montjoie>
BenG83: thanks
<BenG83>
montjoie, works for me :)
<montjoie>
icenowy[m]: does u-boot h6-dram and linux h6-init are the right branch for H6 ?
2018-02-28
<montjoie>
what's your favorite wire color ?
<montjoie>
the knight who say ni requires a sacrifice!
<montjoie>
but not enought sdcard for it:(
<willmore>
montjoie, yay!
<montjoie>
ah ah! just got my pineh64. time to test cryptoengine
2018-02-25
<montjoie>
BenG83: a random veroboard from alliexxpress
<montjoie>
finally its a good one
<montjoie>
one hour to undersstand why my atx doesnt startup
<BenG83>
montjoie ouch
<montjoie>
raaaaah after hours of soldering my allwinner lab, I just found that the veroboard has an hidden layer non documented which connect all lines (and all my USB + and -)...
2018-02-20
<silviop>
montjoie: is it the only way to show battery in desktop enviroment ?
<montjoie>
silviop: and perhaps its author does not sent it for review
<montjoie>
silviop: because it seems bad ? doing many things that need to be splited
2018-02-16
<montjoie>
already proposed it, but only wens and mripard could ask it I think
<montjoie>
aka not in MAINTAINERS
<montjoie>
rellla: because linux-sunxi is not an official mailing list
<montjoie>
using gentoo help for having the exact same version
<montjoie>
it seems to work with same gcc version cross + native
<t3st3r>
montjoie> would distcc handle cross + non cross easily? oO
<montjoie>
BenG83: nice, I believe to see some DC 12->5V like mine
<montjoie>
embed-3d: I do the same (8 board relay controlled by arduino nano)
<embed-3d>
montjoie: pleas: I built up my costom power switch out of a relais pcb with 8 relais and and arduino uno. Its cheaper and less time consuming than doing an own schematic
<montjoie>
Trying to create the schema for it, but Fritzing is dying of segfault and kicad is complex for placement:(
<plaes>
montjoie: would be cool
<montjoie>
plaes: if you want I can share my CI plan (custom power swicth + LAVA + kernelci)
2018-02-06
<montjoie>
yeah two name for two different thing
<montjoie>
and them I will send the allwinner/cryptoengine driver
<montjoie>
cryptoengine aka linux/cryptoengine
<montjoie>
miasma: I wait the crypto maintainer to merge my crypto engine serie
<miasma>
montjoie: btw what's the status of the hw accelerated crypto on h3/h5? is it possible to enable mainline support for those ciphers that seem to work now?
<montjoie>
willmore: yes it's a good way to know maximum
<embed-3d>
montjoie: Ok, iperf results are not comparable with an real data transfer test ;)
<montjoie>
iperf
<embed-3d>
montjoie: How did you test it? with real data or with iperf?
<montjoie>
embed-3d: without SMP I has better perf
<embed-3d>
montjoie: I agree this is very _low_, but I think think this has to do with missing smp/dvfs and a low frequency of the cpu, because I have a cpu load of 100% during copying
<montjoie>
embed-3d: 10MB/s is really LOW, with my stale kernel (so before DT AXP) I could obtain far better
<embed-3d>
montjoie: I'm not able confirm this. I was able to copy (with scp a ~2 GB big file from and to the bpi-m3). The bandwidth is low, but stable (~10MB/s). But it looks like that this is due to the missing smp/dvfs patches and the low frequency (during copy cpu load 100%).
<embed-3d>
montjoie: Do you have also a boot problem with latest mainline?
<embed-3d>
montjoie: I don't have any problems there. What for a switch do you use? I can do some load tests on wednesday and try to reproduce your problem. What do you do/see exactly when you have those problems? (a log would be helpful)
<montjoie>
embed-3d: so your ethernet is stable and with good bandwith ?
<embed-3d>
montjoie: v1.2
<montjoie>
wens: mine is v1.2
<montjoie>
embed-3d: whats your board revision ?
<embed-3d>
montjoie: I've tested bpi M3 (current mainline) yesterday, I had to disable the wifi and and wifi_powersequence due to a current bug with ac100/clocking, but I don't see your ethernet problem.
<montjoie>
jernej: do you have retested your bpi M3 for the ethernet problem ?
<montjoie>
wens: will check it after work
<wens>
montjoie: does your board have a revision number?
<wens>
montjoie: no idea, as I'm unable to reproduce it
<montjoie>
wens: I still hit the problem with A83T and unusable packet loss ethernet and since I am not the only one to hit it, any idea on how to fix it ?
<montjoie>
yes
2018-01-30
<montjoie>
you will hit problem on A83T with it, but that's not the reason