<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
<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>
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()
<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