2017-08-26

<montjoie> check all config options.. nothing seems missing
<montjoie> nothing more
<montjoie> I will
<montjoie> MoeIcenowy: could you share your .config ?
<montjoie> and mainline uboot
<montjoie> I use the just posted sun50i-h5-nanopi-neo-plus2.dts2
<montjoie> any change stuck me
<montjoie> the board work with the vendor image
<montjoie> switched on it, get nothing more
<MoeIcenowy> montjoie: allwinner-stable
<montjoie> MoeIcenowy: nothin more with earlycon
<montjoie> which branch of apritzel ATF do you use ?
<MoeIcenowy> montjoie: try to add earlycon=uart,mmio32,0x01c28000 in kernel cmdline
<montjoie> does someone could give me his setup for H5, no success at all . just get "Starting kernel"
<montjoie> raaaaaah mdio-mux-syscon does not load at the correct time when external PHY is used

2017-08-25

<montjoie> thanks KotCzarny will debug tonight
<montjoie> V3s will need mdio-mux-syscon, and so two mdio node, and one "empty"
<montjoie> MoeIcenowy: arg V3s need to disable shutdown
<MoeIcenowy> montjoie: "EMAC reset timeout"
<montjoie> you could add an external sensor for internal ambiant temp
<montjoie> it is not easy to do something good with unrelated material
<montjoie> liking the build
<montjoie> yeah!
<montjoie> if you could confirm that with my branch all work without mux
<montjoie> MoeIcenowy: yes I kept what you ve done
<MoeIcenowy> montjoie: on V3s it shouldn't be kept -- it should be forced to 1
<montjoie> MoeIcenowy: CLK_SEL keeped the same, anyway it was an error to give it to MDIO mux
<montjoie> my reg/mask was bad:(
<montjoie> yes
<montjoie> KotCzarny: I force update my repo
<montjoie> btw my mask/values seems wrong
<montjoie> ok
<montjoie> which commits ?
<montjoie> MoeIcenowy: I think for V3s I need to keep H3_EPHY_CLK_SEL in dwmac-sun8i
<montjoie> MoeIcenowy: if you could test it also on V3s
<montjoie> but since I want to send patch serie before tonight... I need a test on H3/H5 with external PHY
<montjoie> for solving our internal phy issue, I created a mdio-mux-syscon, but only tested it on integrated phy
<montjoie> yes
<montjoie> you need to enable mdio-mux-syscon
<montjoie> and ready to test a branch
<montjoie> anybody with an H3 or H5 with gigabit ethernet ?
<montjoie> does anybody could test https://github.com/montjoie/linux/tree/stmmac-sun8i-wip-next-20170824 on a H3 with gigabit ?
<montjoie> good morning winter I have a radiator
<montjoie> so it is now official, RIP bpim2+

2017-08-24

<plaes> montjoie: ok, no worries :)
<montjoie> sorry I have few time, I try to finish my solution for H3 internal PHY
<montjoie> someone tested it for me
<plaes> montjoie: Orange Pi Zero
<montjoie> for the syscon disapear its normal, its in dwmac
<montjoie> plaes: I do not own H2+
<plaes> montjoie: o/
<montjoie> try apt-cache search kernel-headers
<montjoie> Ntemis: here we discuss kernel, kernel-headers are a package, so totally unrelated
<montjoie> I will try to argue for that
<montjoie> mripard: do you agree with two mdio node ?
<montjoie> mripard: I will answer last mail from Florian, but discution is now circular, we seeing always discussed options.

2017-08-23

<willmore> montjoie, no, I asked if you still needed a copy of it from someone.
<montjoie> willmore: yesterday you said that boot.cmd was not necessary...
<montjoie> yes

2017-08-22

<montjoie> good question, I can do without it ?
<willmore> montjoie, do you still need a boot.cmd?
<montjoie> I will try
<montjoie> I used the board/sunxi/README.sunxi64 from uboot (with apritzel ATF)
<montjoie> I have near the same config than my A64
<montjoie> beeble: nothing more
<montjoie> it is ttyS0 like my other boards
<montjoie> beeble: I have earlyprintk
<beeble> montjoie: an earlyprintk with a matching console would probably help you
<montjoie> always mainline:)
<KotCzarny> montjoie: booting legacy or mainline?
<montjoie> Could someone share to me his H5 boot.cmd ? I got only starting kernel...
<montjoie> ouch
<montjoie> for fun, I will launch a request to allwinner "remove DES/3DES(lol) add GCM"
<willmore> montjoie, from 'cryptsetup benchmark' on an H3: aes-cbc 128b 15.5 MiB/s 10.9 MiB/s
<montjoie> will see:(
<willmore> montjoie, plus the H5 has the AES acceleration instructions, so it does several times better than the H3 because of that as well.
<montjoie> very curious to see what they will add/remove in H6
<chrisf__> montjoie: hahaha. Not worried about throughput for my application. Just don't want the CPU load.
<montjoie> instead they add (and remove) random blockmode
<montjoie> Was happy when TLS module goes in kernel, but it use only GCM, an alg that CE does not support...
<montjoie> but why!!!
<montjoie> on A83T any AES > 1024bytes timeout and made any further AES timeout
<montjoie> I need to find a way to verify that
<montjoie> the only way to be better is perhaps that the 4 parallel stream are not really/badly used
<montjoie> my heart will suffer if I compare with optimized algs
<montjoie> I cry even when comparing with aes generic
<montjoie> I will setup mine tonight, perhaps good surprise vs H3 numbers...
<montjoie> and cry
<montjoie> chrisf__: now bench it:)
<chrisf__> montjoie: crypto engine in the H5 now doing AES256 correctly - thanks for your help.
<montjoie> just it seems we rely on a old ATF fork
<montjoie> thanks ElBarto, instructions ok!
<montjoie> I will update wiki
<montjoie> ElBarto: thanks
<ElBarto> montjoie: that what you want to follow
<ElBarto> montjoie: there is README.sunxi64 somewhere in u-boot tree
<montjoie> I try to install my H5 board but fail at http://linux-sunxi.org/Mainline_U-Boot#Install_U-Boot the instruction for arm64 is missing (since lack of u-boot-sunxi-with-spl.bin)

2017-08-21

<wens> montjoie: I should restate that we need a solution this week, preferably not at the end of the week
<montjoie> ok mripard already asked for it on ML
<wens> montjoie: please ask mripard. I have some other personal matters to deal with
<montjoie> just I remove mdio-mux
<montjoie> wens: with andrew answer, what do you think about two seperate mdio ?
<montjoie> now the real question, does it is faster...
<montjoie> and RSA work on A83t \o/
<montjoie> yes that was I mean to say
<willmore> montjoie, in specification documents, "MAY" indicated an optional requirement. "SHOULD" is a manditory requirement.
<montjoie> wens: I am a bit lost on what to do now. Does just I try to send the serie updated with your comments ?
<montjoie> I think it will finish in arch/arm
<montjoie> search for dma_map_single for example in Linux source
<montjoie> so you need to do what do DMA API, flush the cacheline
<chrisf_> montjoie: I don't have an API ;)
<montjoie> chrisf_: if you do DMA, you need to use the API for it:)
<chrisf_> montjoie: seems my H5 problems are because I haven't implemented dma_map/unmap. If I put my descriptor in SRAM C the length error goes away :)
<montjoie> all other mdio-mux dont care also of xMIII
<montjoie> but it will be more work
<montjoie> like we just called mmio-mux-regmap-select(bus)
<montjoie> what I understand is that mmio-mux-regmap will remove some code from dwmac-sun8i
<montjoie> wens: how do you understand AndrewLunn comment ? MAY ou SHOULD ?
<montjoie> nothing more
<montjoie> MoeIcenowy: yes, just add phy-is-integrated
<MoeIcenowy> montjoie: thus should I add phy-is-integrated to the V3s EPHY?

2017-08-20

<montjoie> ouch got an if (err) return err; that return when err = 0
<montjoie> MoeIcenowy: no, since V3s could do only internal, they are no intereset in representing a mdio which will never be used
<MoeIcenowy> montjoie: should I care the mdio mux when writing the V3s DT?
<chrisf__> montjoie: I'll be interested to hear how you get on.
<montjoie> and no iommu
<montjoie> chrisf__: I am setupping an H5 for testing CE on it.
<montjoie> pfff with the same UART dongle, RX/TX is inverted between bpim3 and a H5 board. At least someone lie on RX/TX location

2017-08-18

<wens> montjoie: mdio-parent-bus is optional
<wens> montjoie: ok, I didn't know there was already a binding for mdio-mux
<montjoie> chrisf_: I expect to have my crypto/engine patch merged soon, so in a few days I will send sun8i-ce code for review (and perhaps it will be merged in a few release)
<montjoie> yes 4bytes
<montjoie> chrisf_: len is in block
<montjoie> chrisf_: new branch sun8i-ce-wip_next-20170817
<chrisf_> montjoie: AES decrypt. I've been looking very closely at your github!
<montjoie> (and it is a good time to update it)
<montjoie> chrisf_: you could see what I do on my github
<montjoie> chrisf_: which type of task do you run ?
<montjoie> and I cannot remove parent mdio as mdio-mux "mdio-parent-bus" is mandatory
<montjoie> wens: current usage of mdio-mux seems as to keep mdio type
<montjoie> wens: yes I mispelled, will set mdio as label for external mdio
<montjoie> int_mdio was just like a comment
<montjoie> ok for mdio as external mdio name
<montjoie> with your ok, I will send it
<montjoie> please see the 4 commits and said what you think
<montjoie> thanks for confirming
<montjoie> mdio-mux solve only external and internal phy merge
<montjoie> mdio-mux is independant of the PHY select
<wens> montjoie: v3s still has the internal/external phy select bit
<montjoie> MoeIcenowy: wens could you confirm that V3s does not need any mdio mux since external PHY is impossible
<montjoie> clocks/resets ar not under int_mdio, but under phy
<montjoie> wens: https://paste.pound-python.org/show/RUdLDZUC5LPQrVeCqGPu/ I need to finish doc update
<wens> montjoie: can you push it somewhere?
<montjoie> wens: mdio-mux works!
<montjoie> yes but with mux of_phy_find_device does not find the PHY...
<wens> montjoie: you will probably need to ask rob to look at it specifically?
<montjoie> I work on it in case of...
<montjoie> but mdio-mux does not work out of the box and stmmac will need some more patch
<montjoie> wens: lets see if my last serie will be accepted. If not we will probably need mdio-mux (which I agree with rob is probably the right way)

2017-08-17

<wens> montjoie: it will be -rc6 this weekend. we need to sort this out by next week or I'm going to revert H3 EMAC support
<montjoie> wens: rob made an anwser, I am checking mdio mux in case of...
<montjoie> :)
<montjoie> ouch what happened! klined!

2017-08-16

<igraltist> montjoie: ok
<montjoie> igraltist: no

2017-08-15

<montjoie> MoeIcenowy: not yet
<MoeIcenowy> montjoie: have you sent the dwmac-sun8i ephy patches?

2017-08-14

<montjoie> In fact I wish to have a column for that in the support matrix or other wiki way
<montjoie> I want to do some secureboot optee, which SoC is the best for that ? I ask that because I saw some task about H3 thaa cannot be boot in secure mode
<montjoie> and since PAX have some part in assembly... ARM support is not evident
<montjoie> grsec is beyond framework with PAX.
<montjoie> :) I didnt wanted to start the troll about grsec availlability:)
<montjoie> I think it should works, depend on what grsec patch you have (against which kernel)
<montjoie> fugitive: grsec supports arm ?
<montjoie> property on dt node is simple
<montjoie> the correct way is probably to create two MDIO node but it requires some(lot) of hack of stmmac
<montjoie> but on this thread, long delay seems a goal
<montjoie> wens: yes, I try to wait...
<wens> montjoie: still, Rob hasn't answered what to do about the internal phy node
<wens> montjoie: you should probably pick the doc patch from net-next, and include it in your series for netdev
<montjoie> wens: it seems that rockship integrated PHY is merged, so I will resend my series without the doc patch and with property on board DT

2017-08-12

<MoeIcenowy> montjoie: P.S. it
<MoeIcenowy> montjoie: when udhcpc is in definite "sending discover" I unplugged the cable, no link down infomation is shown, however a warning appeared "NETDEV WATCHDOG: eth0 (dwmac-sun8i): transmit queue 0 timed out"
<MoeIcenowy> montjoie: I'm retrying dwmac-sun8i on R40

2017-08-11

<wens> montjoie: that would work
<montjoie> wens: or put phy-is-integrated in board dts
<MoeIcenowy> montjoie: not yet released
<montjoie> no H6 user manual ?
<montjoie> I can propose it, in my mail
<montjoie> wens: or another solution, split mdio in two
<montjoie> ok
<wens> montjoie: Rob and Mark Rutland (mostly Rob). Florian comments on ethernet related dt changes, so add him as well?
<montjoie> wens: I will make answer another to your last mail. Does rob is the right target ? (since it is a DT problem)
<wens> montjoie: I don't think that would pass review by dt maintainers
<montjoie> wens: and using @integrated ?
<montjoie> I read DT spec in case I see a solution
<montjoie> I pick 31, but I fear that hack would be rejected
<montjoie> like @FF ?
<montjoie> seldom used address ?
<wens> montjoie: then move the internal phy to a seldom used address, like I mentioned before
<montjoie> wens: deleting property on all external phy is horrible
<wens> montjoie: right now it works, because external phy is rgmii, and that is the last thing set
<montjoie> there are something I have difficulty to understand
<montjoie> wens: so on bpim2+ integrated and external phy is merged. how dtc know which phy-mode etc.. to use ?
<montjoie> not bad
<montjoie> KotCzarny: yes
<wens> montjoie: it doesn't match the policy on device node names
<KotCzarny> montjoie: did you miss zidoo h6 box announcement?
<montjoie> would love to do the driver for that:)
<montjoie> pcie!!!
<montjoie> wens: what do you think with my idea ? nodename: integrated-phy

2017-08-10

<montjoie> igraltist: didnt get it but only get 5.4.0
<montjoie> wens: just sent!
<montjoie> wens: I have 3 patchs one binddoc, one for h3 dt, and one for stmmac
<montjoie> patch for doc is ready:)
<wens> montjoie: since we need it for netdev, as opposed to them sending it for net-next, you should probably also do the "phy-is-integrated" generic binding part
<montjoie> wens: we got an answer \o/

2017-08-09

<montjoie> inf: allwinner,leds-active-high is iinvalid try "/delete-property/ allwinner,leds-active-low;"
<montjoie> :)
<inf> time to take a walk or something... thank you very much montjoie :)
<montjoie> silly question, how about the cable ?
<inf> montjoie: https://gist.github.com/196a1e0a1438940d68d45d9ab54015f2 and on the other side mii-tool tells me: "enp0s31f6: no link" (after bringing up the interface, of course)
<montjoie> inf: paste the dmesg about emac
<montjoie> and with lots of bugs
<montjoie> inf sun8i-emac is old
<montjoie> the current linux-next got it
<montjoie> try dwmac-sun8i
<montjoie> inf: sun8i-emac is a hotkey that means you do not use a recent kernel
<montjoie> if we have a choice for H3, i think it will be simplier to use it on V3S
<montjoie> I expect to have one with my last mail
<montjoie> for our case I think its the best, but each time we ask, we got no answer for andre/florian/etc
<MoeIcenowy> montjoie: is "phy-is-internal" the final choice?
<montjoie> just after got it, I will do all patch for it
<montjoie> wens: I have just sent an answer asking for a choice
<wens> montjoie: thanks
<montjoie> will try first a ping
<montjoie> wens: I will try to do a patch with "phy-is-internal" explaining that we could have two phy with same id for wake up the conversation
<wens> montjoie: no word from Florian :(

2017-08-04

<montjoie> sun4i-ss with dma is slower (/10)
<montjoie> note also that sun4i-ss is cpu driven, not dma like sun8i-ce
<montjoie> I fear that cryptsetup benchmark use larger block than 512
<montjoie> KotCzarny: cryptsetup benchmark is not good for numbers, I need to redo it with libkcapi
<montjoie> KotCzarny: https://pastebin.com/paGfK4Ky strange that after removing of sun8i-ce, xts become available

2017-08-03

<montjoie> raah need to emerge cryptsetup
<montjoie> will try on h3
<montjoie> KotCzarny: SS is uesfull, CE not:)
<montjoie> but on my cubie2 xts is always faster
<KotCzarny> montjoie: and i though you've said it's useless
<montjoie> yeah sun4i-ss is usefull
<montjoie> both have engine for openssl but sometime hard to install
<montjoie> cryptodev is out of tree... AF_ALG not (but slower)
<montjoie> with it cipher support could start to be mainlined
<montjoie> and for crypto engine, I am stuck. Waiting for herbert xu answer on cryptoapi/cryptoengine
<montjoie> KotCzarny: I cannot think that armbian will use my non stable driver
<montjoie> the driver for crypto engine is not in mainline
<montjoie> oh you mean crypto extentions, not crypto engine
<montjoie> and I am pessimist but, high numbers and crypto engine are orthogonal
<montjoie> even with you use my branch with crypto engine, no h5 DT on it
<montjoie> I think it do not use the crypto engine:)
<montjoie> and I wait for answer
<montjoie> I have replied
<montjoie> but your answer seems that you prefer the phy-is-internal
<montjoie> I asked if "ed sun8i-h3-ephy,ethernet-phy-idxxx" will be good
<montjoie> wens: it seems that the only solution is with ethernet-phy-idxxx, but I still wait the official answer to my reply
<montjoie> :)
<wens> montjoie: use phy-is-internal
<montjoie> wens: do you think I can send the patch now ? it seems that sed sun8i-h3-ephy,ethernet-phy-idxxx will be good ?

2017-08-02

<montjoie> I agree
<wens> montjoie: btw, next time you send patches, please specify which patches should go in which tree
<montjoie> at first agreement I will sent patch:)
<montjoie> wens: rockchip patch with phy-is-internal sent this morning, we will see what netpeople will say
<wens> montjoie: so I think the solution is "phy-is-internal", maybe wait a few days, then you can send patches fixing dwmac-sun8i?

2017-08-01

<montjoie> wens: mripard no news for the PHY ? does I lost/miss something ? or perhaps Florian doesnt understand that we wait for him ?

2017-07-28

<montjoie> why ?
<MoeIcenowy> montjoie: because I didn't get it fast enough
<montjoie> wens: ok
<montjoie> perhaps I should have sent the series as RFC
<montjoie> wens: yes but the answer from mripard_ seemed to that we have no choice in our case
<wens> montjoie: can you wait until the rockchip discussion comes to an end?
<montjoie> MoeIcenowy: why there are no emac node in V3S ?

2017-07-27

<montjoie> wens: I confirm:)

2017-07-26

<montjoie> the legacy sunxi_ss driver is crap. good luck:)

2017-07-25

<KotCzarny> but for userland tests probably montjoie's page might be helpful too
<montjoie> ah android...
<montjoie> its old:) do you have other modules loaded, because without modprobe...
<montjoie> cafijo: which kernel version do you use ?
<montjoie> cafijo: ask your question
<montjoie> will check
<montjoie> wens: why ?
<wens> montjoie: see commit f4458b92d2 ("net: stmmac: Adjust dump offset of DMA registers for ethtool") in netdev

2017-07-24

<qschulz> montjoie: that's not the first read that is problematic, it is every read of temp before the pm_runtime is enabled
<montjoie> or force a first read during probe/init
<montjoie> and why not adding a variable "first_read" ?