2018-06-25

<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
<montjoie> MoeIcenowy: My lab is doing that
<wens> montjoie: I don't want sluggish I/O :)
<MoeIcenowy> montjoie: collect multiple SBCs' compute ability?
<montjoie> wens: but I used x86 and arm for kernel distcc compile
<wens> montjoie: my work machine is x86
<montjoie> wens: no cross compile since distcc is on native ARM/ARM64 boards:)
<wens> montjoie: distcc + cross compile = headache
<montjoie> KotCzarny: I believed speak was about impact on building
<KotCzarny> montjoie: distcc doesnt help big git operations ;)
<montjoie> what about distcc ?
<montjoie> MoeIcenowy: in fact I made a typo in interrupt number (shame #2)
<MoeIcenowy> montjoie: \ hooray /
<montjoie> ah ah ah my kbuild robot which boot results started! http://kernel.montjoie.ovh/coverage/result/
<montjoie> libkcapi is good for it also
<montjoie> I have created one, but I need to update it
<KotCzarny> montjoie: did you create montjoie's-benchmark-suite yet?
<montjoie> yes, sun8i-ce working on R40!
<montjoie> already enabled...
<montjoie> how to enable it ?
<montjoie> MoeIcenowy: I just found that CLK_MBUS is defined in drivers/clk/sunxi-ng/ccu-sun8i-r40.h and not in include, why ?
<montjoie> MoeIcenowy: so the usermanual for R40 is wrong, or they didnt test their driver
<MoeIcenowy> montjoie: there's no such a clock in user manual CCU chapter
<montjoie> MoeIcenowy: the R40 usermanual state that cryptoengine need a MBUS clock, but I found no MBUS in dt header
<MoeIcenowy> montjoie, KotCzarny: I remember NEO+2 uses a single-chip 1GiB DDR3 solution
<MoeIcenowy> montjoie: what R40 MBUS problem?
<montjoie> MoeIcenowy: thanks the dt stuff made ethernet appear in uboot
<montjoie> MoeIcenowy: and thought on my MBUS for R40 question ?
<montjoie> Arg will check it after work
<montjoie> MoeIcenowy: where can I see it?
<montjoie> MoeIcenowy: any idea for the RAM SIZE ?
<montjoie> MoeIcenowy: so I need to enable it in uboot dt, thanks
<montjoie> MoeIcenowy: will do, believed only .config matters
<MoeIcenowy> montjoie: check u-boot dt?
<montjoie> furthermore I have only 512 RAM instead of 1G
<montjoie> it is remote so cannot see it
<montjoie> I use the official uboot config
<montjoie> I have CONFIG_MACPWR="PD6" in .config
<montjoie> I have a FriendlyARM NanoPi NEO Plus 2 but I have no net in uboot (even with SUN8I_EMAC enabled in .config) any idea on how to enable it ?

2018-06-18

<montjoie> hlauer: I am sure to have read that it exists tools for testing stability of each freq value
<montjoie> hlauer: I am a voltage noob, but other people here know more about how to set them
<montjoie> hlauer: I dont think R40 has cpufreq support (according to http://linux-sunxi.org/Mainlining_Effort)
<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> yes
<montjoie> pfff shame on me
<montjoie> seems that mmc is never reprobed
<montjoie> wens: booted my R40 with drivercore/mmc/pinctrl debug https://paste.pound-python.org/show/au0gAjV08jhvNQp6wbvd/

2018-06-16

<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
<pgreco> montjoie, sure, it is the standard from fedora
<montjoie> pgreco: could you share your .config for R40 ?
<montjoie> wens: I have enabled all AXP config (and so CONFIG_MFD_AXP20X_I2C=y)
<pgreco> montjoie, just updated my bpi-m2u to the latest fedora (linux-next from a few days ago) and I get a null pointer crash on boot
<wens> montjoie: axp20x-i2c?

2018-06-13

<pgreco> montjoie, does it help if I paste the modules in my initramfs?
<f11f12> pgreco, montjoie: mmc works on my V40 board.
<montjoie> already have all those
<montjoie> pgreco: do you remember which regulator ?
<montjoie> pgreco: I need to add more debug on a83t
<pgreco> montjoie: btw, did you figure out how to fix gmac for the a83t?
<pgreco> montjoie, anything specific for sunxi-next? it works on my bpi-m2u using 4.17 rc7
<montjoie> mmc driver is defered but seems never reprobed
<montjoie> my R40 boot but wait forever on mmc, any idea ?

2018-06-08

<willmore> montjoie, my sympathy. The Pine64 is a good board.

2018-06-07

<montjoie> believed in power supply problem, but all other board working with it without problem:(
<montjoie> mine is reseting every 5s/10s
<montjoie> My pine64 is dead, she go to board paradise
<montjoie> RIP pine64

2018-06-05

<vagrantc> montjoie: it's a cubietruck_plus, fwiw
<vagrantc> montjoie: been a while since i've looked ... i've mostly used a usb ethernet adapter because it was so unusable
<montjoie> vagrantc: does your a83t eth0 is at 100m or 1g ?
<montjoie> no
<montjoie> so its why less people complains about it, only 1G people will hit it
<montjoie> pgreco: thanks, I have the same output, but the tricks is 100Mb
<montjoie> d7c5f6863550 ("ARM: dts: sun8i: a83t: bananapi-m3: Add AXP813 regulator nodes")
<montjoie> and this commit changed DT supply/axp
<montjoie> it worked perfectly before one commit
<montjoie> nope
<montjoie> but its normal since its a phy supply problem
<montjoie> KotCzarny: in 100mbit it works!
<KotCzarny> montjoie, try that 100mbit
<montjoie> could you pastebin your /sys/kernel/debug/regulator/regulator_summary ?
<montjoie> no problem ?
<pgreco> montjoie: last night did an iperf3
<montjoie> my pine64 is self reseting so I need to check why
<montjoie> wow, I plugged a USB LAN stick on my a83t, ping with 7000ms...
<anarsoul> montjoie: connect usb keyboard and try to type something?
<montjoie> not sure that I could test now, but i add test to my LAVA lab for automatic regression test
<montjoie> how to test it ?
<montjoie> ssh is nearly impossible
<montjoie> a simple ping get 50% loss
<montjoie> iperf or ping
<montjoie> pgreco: I need a network test

2018-06-04

<pgreco> montjoie. Bpi m3. Using 4.17 rc7 + smp
<montjoie> the problem is that wens didnt hit it on his board
<montjoie> vagrantc: I remember someone on this channel hitting that when I speaked about it, digging in my log...
<vagrantc> montjoie: i get more like 85%
<vagrantc> montjoie: you're lucky to only have 50% loss
<montjoie> hello any a83t owner ? with recent kernel ? I have 50% packet loss from all kernel for 4 month at minimum

2018-05-31

<montjoie> your password is not bad
<montjoie> deserter: patch are on git you can already use it for testing
<montjoie> it mades my gentoo unhappy, so welcome 4.18!
<montjoie> deserter: yes

2018-05-30

<montjoie> gentoo!

2018-05-28

<montjoie> anybody with an A20 on recent linuc-next ? I get some kernel panic

2018-05-24

<montjoie> ok
<qschulz> montjoie: could you send a mail to me so that I try to not forget about it :) ?
<qschulz> montjoie: hi, we're moving offices in a week and we'll shutdown the lab for a few days then. We'll update LAVA and apply your patches then
<montjoie> qschulz: hello could you try https://review.linaro.org/#/c/24968/ in your LAVA Lab ?

2018-05-19

<wens> montjoie: where's that? I do see other stmmac patches in net-next

2018-05-18

<montjoie> it seems that I need to test all his patchs if I want stmmac to not break...
<montjoie> lol dmiller revert patchs from that synopsys guy, it breaks dwmac-sun8i build!

2018-05-17

<montjoie> it works but its unsecure
<montjoie> but warning prng is broken
<montjoie> just like before, when a synopsys guy add support for a newer stmmac, it breaks old one
<montjoie> wens: you are not guilty:D
<montjoie> wens: before the r40
<wens> montjoie: hmm, is that breakage before or after the r40-dwmac merge?
<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?

2018-03-30

<ejmefa> yann Mr__Anderson netlynx return0e_ RichardG867 embed-3d f0xx libv ak_hepcat reinforce rej tllim JohnDoe4 nuuuciano swiftgeek dave0x6d ernestask specing afaerber gnufan1 BenG83 SP7RT xes nobe victhor TheSeven kaspter megi clemens3 leviathan indy lurchi_ montjoie stellirin kuhn icenowy[m] GuLinux[m] ch40s[m] mic-e[m] yann_soubeyrand Net147 oliv3r souther mripard ssvb arete74 kelvan merlin1991 grw Ke kilobyte medvid black_ink qeed buZz hanetzer aib _0x5

2018-03-27

<KotCzarny> montjoie is local ethernet master

2018-03-21

<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
<KotCzarny> montjoie, doesnt distcc require homogenous gcc?
<montjoie> adding 4+1 ARM core to my 8core give me improvments
<montjoie> why not use both? distcc and powerfull 8 core ?

2018-02-15

<willmore> montjoie, yay!
<montjoie> someone here recommanded to use polyfuse for that
<montjoie> champagne! crypto/crypto_engine merged, now I can start to submit CryptoEngine
<embed-3d> montjoie: I'm using something like this: https://de.aliexpress.com/item/5V-30A-150W-Universal-Regulated-Single-Output-Switching-power-supply-for-LED-Strip-light-AC-to/1603712949.html?src=google&albslr=220262545&isdl=y&aff_short_key=UneMJZVf&source=%7Bifdyn:dyn%7D%7Bifpla:pla%7D%7Bifdbm:DBM&albch=DID%7D&src=google&albch=shopping&acnt=494-037-6276&isdl=y&albcp=664345099&albag=32945289759&slnk=&trgt=61865531738&plac=&crea=de1603712949&
<montjoie> the hardest was to grab ATX connector from an old motherboard
<montjoie> embed-3d: my major problem is getting molex connector, sawing old harddriver...
<embed-3d> montjoie: cool! That looks like a better solution than my setup! I think I will redesign mine!
<montjoie> embed-3d: http://sunxi.montjoie.ovh/cluster2.jpg an old photo before soldering
<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%).
<wens> montjoie: so is mine

2018-02-05

<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