2016-03-30

<montjoie> your version havec only 16 descriptors, it is too few
<montjoie> yes
<montjoie> but it explains why I needed to tweek the filter
<montjoie> Amit_T: oooh you are right, thanks
<Amit_T> montjoie : Hello, In this sun8i_emac_set_macaddr , you are using only this SUN8I_EMAC_MACADDR_HI register but 32 bits should be stored in SUN8I_EMAC_MACADDR_LO ?
<montjoie> wens: I will remove thoses messages and for TX FIFO full I will tune it (number of descriptors)
<montjoie> yeah EMAC still working after a nigth:)

2016-03-29

<montjoie> emerge -e world in progress for full proof of work
<montjoie> in short write order of the ring descriptor
<montjoie> now I successfully compile something over NFS
<montjoie> due to some undocumented feature:)
<montjoie> yes I am near to solve the last TX ring bug in sun8i-emac

2016-03-27

<montjoie> emac tx ring buffer also:(

2016-03-25

<montjoie> like non TCP/UDP CRC not handled
<montjoie> certainly related to ARP stated as invalid CRC
<montjoie> and strange
<montjoie> interesting
<montjoie> wens: I ping to my H3 but not from
<montjoie> the additionnal patch I found made 4.6 compiel fail
<montjoie> it seems that reverting "stmmac: Fix 'eth0: No PHY found' regression" is not yet sufficient
<montjoie> I lost ethernet when going from 4.5 to 4.6
<montjoie> tkaiser: I had ethernet with this uboot
<tkaiser> montjoie: Maybe just this u-boot patch missing? https://patchwork.ozlabs.org/patch/599015/
<montjoie> tkaiser: I confirm it is
<montjoie> tkaiser: perhaps
<tkaiser> montjoie: Are you using u-boot 2016.03 with your Cubieboard2?
<montjoie> cubiebiard2 still have no network on 4.6rc :(
<montjoie> sorry
<montjoie> thanks wens. I havent backported a83t patch since I hadnt time to test it
<wens> montjoie: some cleanups here: https://github.com/wens/linux/tree/a83-emac
<montjoie> and in my memroy I didnt modify CRC bit
<montjoie> last time I ping it worked
<montjoie> I need to found a way(tool) to test network in all aspect
<montjoie> wens: I will check after work
<montjoie> wens strange
<wens> montjoie: ssh works with latest patch, but ping doesnt?

2016-03-24

<montjoie> plaes: do not know such command
<alain_> montjoie: same here, not sure how a regulator is supposed to look like on the schematic
<montjoie> alain_: I see nothing in the schematic but I am not an expert in reading them
<montjoie> gentoo will save us from systemd !
<montjoie> ok I understand
<montjoie> KotCzarny: account separation is unrelated to encryption, you need both
<KotCzarny> montjoie, nothing beats encrypted own subnotebook
<alain_> montjoie: sent by e-mail
<montjoie> may I recommend two unix accounts ? one for work, one for fun:)
<montjoie> yes
<montjoie> perhaps, I need to see if a schematic is available
<alain_> montjoie: I was wondering if we needed to power the PHY through a regulator as shown in that entry ...
<montjoie> alain_: no the problem is for stmmac
<alain_> montjoie: hi, any more thoughts as to why the EMAC driver is not seeing the OPI Plus PHY?
<montjoie> codekipper: sorry no
<montjoie> the only DMA work I do is on the crypto engine
<montjoie> my DMA patch for audio ? not me:)
<montjoie> what a low latency
<montjoie> pong
<codekipper> montjoie: Ping!
* montjoie discover patchwork.kernel.org and its command line client (happy)

2016-03-23

<alain_> montjoie: still the same issue with timeout at 500
<montjoie> 0
<alain_> montjoie: do I keep reg = 0 or 1 in the DTS ?
<montjoie> alain_: line 797 could you raise the timeout from 50 to more (500)
<montjoie> 1cc915 realtek phy so the problem is elsewhere
<montjoie> did you have a 3.4 boot log?
<montjoie> not sure it could help
<montjoie> did you enable PHY driver for realtek ?
<alain_> montjoie: same error with reg = 0
<montjoie> the address is random
<montjoie> reg = <0>;
<montjoie> do you have tried to change reg to 0 ?
<montjoie> without the try of putting eth0 up, it is not enougth
<alain_> montjoie: no root filesystem as it is on eMMC which this kernel does not support, not sure if enough info here for you
<montjoie> :)
<montjoie> renamed to emac_rgmii_pins
<alain_> montjoie: DTC arch/arm/boot/dts/sun8i-h3-orangepi-plus.dtb ERROR (phandle_references): Reference to non-existent node or label "emac_pins_a"
<montjoie> you need to enable emac in the final dts
<alain_> montjoie: do I still need to manually change the sun8i-h3-orangepi-plus.dts to add the emac entry or can I rely on the one in sun8i-h3.dtsi ?
<montjoie> alain_: If you could retry the latest patch on github
<alain_> montjoie: let me know if you want me to run tests
<montjoie> I need to setup a board with RGMII
<montjoie> logicaly no
<alain_> montjoie: I see you have updated the EMAC driver. Any OPI Plus specific changes?
<montjoie> lvrp16: take it at http://sunxi.montjoie.ovh/ethernet/
<zoobab> @montjoie of course
<jelle> montjoie: nice
<tkaiser> montjoie: Thx
<montjoie> I have updated github.com/montjoie.linux with a branch for emac if someone is interested
<willmore> montjoie, thanks for the clarification and the link. I added it to my reading list.
<montjoie> See sunxi.montjoie.ovh for status
<montjoie> lvrp16: willmore I work on all Allwinner crypto accelerator
<willmore> montjoie is working on it for the cubbieboard 2.

2016-03-22

<willmore> montjoie, you're welcome. I look for things...
<montjoie> I didnt start to work on it, my basic driver for aes didnt work
<montjoie> that's a huge remove of functionnality
<montjoie> oh ok, no more RSA
<montjoie> in which page ? since H3 have only DMA it will be async
<montjoie> thanks willmore
<montjoie> Interesting the crypt engine guide in 1.2 datasheet
<lvrp16> probably useful for montjoie?
<willmore> montjoie, the datasheet that jernej mentions says "v1.2 Add the programming guide of crypto engine", FYI.
<alain_> montjoie: thanks a lot, I'll check this out tonight and will let you know how it goes
<montjoie> I have setup a github repo for releasing my patchs http://github.com/montjoie/linux/ I will put it EMAC patchs this afternoon
<montjoie> alain_: sorry I lag, I need to check that I get all wens patchs
<alain_> montjoie: hi, let me know if you want to do further tests with the emac driver on the orange pi plus
<montjoie> I will read them
<wens> montjoie: for a83t it is simple, just use the gmac clk driver
<montjoie> but H3 and a83t is different
<montjoie> I will write that on the email
<montjoie> or we can simply give a second iomem to the EMAC driver
<montjoie> the only weird bit is the LED_POL that is not really a part of aclk_driver
<montjoie> for me we just use it for choosing PHY interface, so it is not a PHY driver (handling a specific PHY ID)
<montjoie> we speak about the systemcontrol registe rigth ?
<montjoie> I will answer the mail
<montjoie> wens: if you want, but I am not convinced that a phy driver is the best
<montjoie> wens: yes
<wens> montjoie: did you get hans' reply on h3 emac internal phy?

2016-03-21

<montjoie> tomorow I will add some debug for finding the problem
<montjoie> try reg <0> in case of
<montjoie> the current driver bundle PHY management
<montjoie> no
<montjoie> the PHY is not detected
<montjoie> could you paste dmesg ?
<alain_> montjoie: progress, kernel builds fine, systems boots and sees the ethernet interface, however can't seem to send any packets out
<montjoie> ssvb: no change with two errata process running
<montjoie> I own only A20 device
<montjoie> ssvb: it reduces the general latency
<ssvb> montjoie: also I wonder if running something like this https://gist.github.com/ssvb/2c9995b43c97c5ec066a on both CPU cores together with the crypto test can lead to reproducing the bug easier?
<ssvb> montjoie: how expensive is the use of spinlock_irqsave?
<montjoie> alain_: emac_pins_a
<alain_> montjoie: ERROR (phandle_references): Reference to non-existent node or label "emac_pins"
<montjoie> I reproduce data corruption too frequently...
<ssvb> montjoie: but it is expected to be extremely rare because the necessary conditions are rather difficult to reproduce
<ssvb> montjoie: there is no workaround for this erratum, only fixes in updated revisions of Cortex-A7 processor
<montjoie> a simple test could be to remove all readsl
<ssvb> montjoie: it is in the errata document, available for download from the ARM website (assuming that one has a registered account there)
<montjoie> ssvb: I dont see this errata in menuconfig choice
<montjoie> ssvb: beyond my knowledge, I am an ARM assembly noob.
<ssvb> montjoie: how many instructions are needed for a context switch from some floating point userland process to this decryption loop in the kernel?
<montjoie> alain_: rename it without rgmii_
<ssvb> montjoie: the pre-requisite is a VFP divide or square root operation, executed no further than 58 instructions before some conditional load/store instructions in a certain pattern
<ssvb> montjoie: not sure if this is yet another false lead - "Cortex-A7 erratum 823274: Load or store which fails condition code check might cause deadlock or data corruption"
<montjoie> do you have added base EMAC patch ? (from http://sunxi.montjoie.ovh/ethernet )
<montjoie> working on removing PHY clk hack and proper MII/RGMII choice is my next task
<montjoie> yes, just I need tester for reporting that the DT works
<alain_> montjoie: would you happen to have the dts entry to get your h3 emac driver working with the Orange Pi Plus?
<montjoie> just changin frequency
<montjoie> KotCzarny: I think a "sort of that" issue
<montjoie> for being sure that its speed was not the issue
<montjoie> I change DRAM on ssvb suggestion
<montjoie> KotCzarny: mu board dont fail dram test
<montjoie> :)
<KotCzarny> montjoie: dont mind me, im in silly mood
<montjoie> perhaps, but so why disabling interupt via spinlock_irqsave made it works ?
<ssvb> montjoie: yes, without DMA usage it is hard to blame DRAM
<montjoie> only if I use spinlock_bh
<montjoie> DRAM speed could dommage board ?
<montjoie> so I dont have choice to change the spinlock type
<montjoie> so the DRAM speed is not the issue
<montjoie> yes 480 before
<montjoie> ssvb: and no DMA yet since my last test show me again some "DMA timeout"
<montjoie> ssvb: 360Mhz failed
<apritzel> zoobab: yes, montjoie has had some success in the last days, but it's still WIP
<ssvb> montjoie: I looked up a bit, and if I understand it correctly, the crypto code does not use dma yet?
<ssvb> montjoie: has 360mhz also failed?
<montjoie> trying 360
<montjoie> :(
<montjoie> fail at 408
<ssvb> montjoie: compile and run sunxi-meminfo from https://github.com/linux-sunxi/sunxi-tools on the device
<montjoie> ssvb: how to know the current memory speed ?
<montjoie> checking with 408Mhz (I fail to wait for tonight)
<tkaiser> montjoie: The person who reported that first is also using Cubieboard2 :)
<montjoie> I pray that its the issue
<montjoie> ssvb: I will try it tonight
<montjoie> 400MHz ?
<montjoie> ssvb: which frequency do you recommend ?
<montjoie> so something perhaps sent an interupt durring ciphering and boum
<montjoie> ssvb: I I disable irq the problem disappear so the RAM is goot for me
<montjoie> what the fuck
<montjoie> if I umount remove sun4i-ss and remount it, the bad block disappear
<montjoie> ssvb: cubieboard2
<montjoie> like LUKS adding one
<montjoie> For each request I do the same via aes-asm and sometime a got an additionnal corrupt block
<ssvb> montjoie: what kind of board is that?
<montjoie> the sun4i-ss corruption get me mad
<montjoie> lennyraposo: thanks
<lennyraposo> hey montjoie

2016-03-20

<montjoie> no, just I need to reorder them
<tkaiser> montjoie: It seems 0001 and 0005 of your EMAC patches are identical. Possible that there's some patch around that didn't make it on your web site?
<tkaiser> montjoie: Thx! :)
<montjoie> solved
<montjoie> no
<tkaiser> montjoie: Is this intentional: 'You don't have permission to access /ethernet/0001-ethernet-add-sun8i-emac-driver.patch on this server.'? :)

2016-03-19

<montjoie> time to commit
<montjoie> ouch I fixed a bug, and now the EMAC is SO FAST
<montjoie> wens: I needed to check for dynamic debug since without it defining DEBUG is not sufficient (at least in my last try)
<wens> montjoie: fyi a better way than EMAC_DEBUG is to change all the printk calls into the _debug variant, like dev_debug()
<lennyraposo> wow montjoie

2016-03-17

<plaes> montjoie: where do you keep the patches?
<montjoie> apritzel patch updated
<montjoie> apritzel: I need first to remove the sunxi_hack function:)
<apritzel> montjoie: or maybe it's time to post a new version on the ML?
<montjoie> yes
<montjoie> but still with some latency
<apritzel> montjoie: great!
<montjoie> wens: apritzel last EMAC bug is gone, NFS works:)
<montjoie> but first I need that NFS works (so multi RX frame reception works)
<montjoie> I have some hint on what cause this
<montjoie> yes:( network is slow
<montjoie> strangely because allwinner driver does not seems to handle it
<montjoie> but it is not handled on reception
<montjoie> fragmented skb is handled
<montjoie> yes:)
<apritzel> montjoie: so you can dump dmesg now over ssh? ;-)
<montjoie> wens: I will continue to backport your patchs
<wens> montjoie: cool
<montjoie> but with the current state, a stable ssh is possible
<montjoie> One more bug I need to solve is the RX multi frame
<montjoie> wens: I updated the patch
<lennyraposo> montjoie got h3 mac working
<montjoie> no
<montjoie> yes stable ssh
<montjoie> I need to backport wens patch and release it
<montjoie> the ethernet just work
<lennyraposo> montjoie*
<montjoie> wens: thanks I will backport them
<wens> montjoie: i've updated my a83-usb branch, this time all changes are individual patches
<lennyraposo> I believe montjoie is working on that

2016-03-16

<montjoie> and I will publish it without the noise of debug
<montjoie> I fixed a bug in the current EMAC driver, I will update it soon
<montjoie> no hurry, I need to first found why dmesg stuck the ssh connection (packet sent with bad length)
<wens> montjoie: i'll update my branch a bit later
<montjoie> since you said I forgot to backport your RGMII modification
<montjoie> wens: do you have modified something for make it works ?
<montjoie> wens: thanks for the test:)
<wens> montjoie: sun8i-emac driver on a83 seems to be working, though it is too noisy to use for now
<wens> montjoie: you also reverted the rgmii changes i made in sun8i_emac_set_link_mode()
<wens> montjoie: fyi the mdio bits can stay in the ethernet driver

2016-03-15

<tkaiser> montjoie: More feedback tomorrow. I was lazy and let just built an Armbian image with your patches and no network came up
<montjoie> tkaiser: does arp works ?
<montjoie> tkaiser: the phy seems ok (id 44), perhaps you hit the same bug then me with big frame
<tkaiser> montjoie: Doesn't work for me: http://pastebin.com/nQKZdp7r
<tkaiser> montjoie: I had to add 0000-sun8i-h3.patch: http://sprunge.us/QFXd (I would believe you rely on http://moinejf.free.fr/opi2/sun8i-h3.dtsi)?
<montjoie> I am based on 4.5
<montjoie> tkaiser: I think
<tkaiser> montjoie: Should your patches work against a clean 4.5?
<montjoie> normal, I post the patch and found a missing part (txstats)
<montjoie> apritzel http://sunxi.montjoie.ovh/ethernet/ (still needing to setup a public git repo)
<apritzel> montjoie: can you post a fixed version somewhere?
<montjoie> I know what is it
<montjoie> but long output like dmesg doesnt work
<maz> montjoie: been there quite a few times.
<maz> montjoie: a classic.
<montjoie> maz: it was CRC:)
<montjoie> ssh working:)
<montjoie> I rebase my commits
<montjoie> tkaiser: I will update it soon
<montjoie> tonigth wireshark will confirm it
<tkaiser> montjoie: http://sunxi.montjoie.ovh/patchs_current/ is pretty outdated isn't it?
<maz> montjoie: sounds like a checksumming issue.
<montjoie> arp/ping works, just a strange problem that my pc doesnt finalize TCP 3way handshake with it
<maz> montjoie: doing something you are proud of is definitely commendable. doing something that is useful to others is even better.
<montjoie> mripard_: I understand well your point of view, but I wanted to do something that can I be proud of it
<montjoie> so now we know it
<montjoie> the bugs that make me lose time was undocumented...
<mripard_> montjoie: no DT is easy
<montjoie> mripard_: more than a bit of cleanup since no DT, etc.. and I wanted to be sure to understand all what I do
<montjoie> KotCzarny: will do that
<mripard_> montjoie: you spent a lot of time on this already, is there really a point in trying to have a driver working from scratch when allwinner's just need a bit of cleanup? ?
<KotCzarny> montjoie: try pinging with different packet sizes?
<montjoie> tcpdump see nothing
<montjoie> and I got a reply to the first ssh packet but my mainpc doesnt answer
<montjoie> no idea
<montjoie> 200 ping and after the void...
<montjoie> ok
<wens> montjoie: i have cubietruck plus, which uses rtl phy :)
<montjoie> I will publich the last patch today
<montjoie> and I2C
<montjoie> wens for a83t I need ac200
<montjoie> but ping work and ring buffer works
<montjoie> just ssh wont work and I dont see why
<montjoie> yes
<wens> montjoie: yay!
<montjoie> ssh comes soon
<montjoie> it is official the EMAC H3 answer ping now

2016-03-11

<montjoie> basicly just using spin_lock_irqsave instead of spin_lock_bh made the issue diseapear and I dont understand why
<montjoie> and expecting to have an answer
<montjoie> so I will resend the same mail with some more infos I get now
<montjoie> but with AF_ALG now
<montjoie> same problem than https://lkml.org/lkml/2015/10/11/47
<montjoie> no idea at all
<montjoie> ok I have found a workaround for the sun4i-ss corruption
<montjoie> cosm_: someone was faster then me https://patchwork.ozlabs.org/patch/596077/ :)
<montjoie> Now I have two revert patch in my 4.5rc, no luck...
<montjoie> I will send a mail for that
<montjoie> the first patch touching stmmac was the good one:)