<montjoie>
for solving this I project to transform an ATX power supply to a "supply power for all device cluster"
<montjoie>
I suspect the external power
<montjoie>
damaged with smell:)
<montjoie>
and the last usb/sata converter I use just burnt my disk:(
<NiteHawk>
montjoie: sure. poor sata is still better than none ;) just thought i'd mention it
<montjoie>
NiteHawk: I am not interested in speed but reliable (more than sd card) storage for backup
<montjoie>
oneinsect: my github tree have more recent patch
<NiteHawk>
montjoie: see tkaiser's edit - "Removed SATA category since it's just the slowest USB-to-SATA bridge in the world" :D
<montjoie>
oh opi+2 have sata...
2016-04-15
<montjoie>
ok
<montjoie>
oneinsect: I did not any dts for nanopi
<montjoie>
when grep TODO will be empty I will send it for review
<montjoie>
no I need to finalize some details first. I wait also for wens ephy driver
<montjoie>
oneinsect: yes
<oneinsect>
hello montjoie: yes i was reading your work in previous irc logs
<montjoie>
but it works well
<montjoie>
not finalized since not in mainline
<montjoie>
oneinsect: the ethernet patch works
<montjoie>
Amit_T: yes but it is a spetial clock register (not like others in the CCU subsystem)
<montjoie>
for H3 inernal PHY, if you search for ephy in datasheet, you will find the clk register and the reset register
<montjoie>
For each compoment you need to read the datasheet
<montjoie>
not sure, I think
<montjoie>
and you could also have a reset controller:)
<montjoie>
clk is mandatory, a regulator is optionnal (some board have one, some not)
<montjoie>
no
<montjoie>
so after clk/regulator setup
<montjoie>
I think it is done after phy_connect()
<montjoie>
I am not a PHY expert, I believe that it is the "libphy" who send a PHY command to do that when PHY is detected
<montjoie>
autoignition ?
<Amit_T>
montjoie: Just for my better understanding, PHY autoignition will automatically starts once PHY is initialized with proper 25mz clock, right?
<montjoie>
and 0x24 have nothing related to emac/clk
<montjoie>
because it is a "misc register space" only 0x24 and 0x30 are used
<Amit_T>
montjoie: ok Thanks, I was thinking why this address "0x01C00000" was not chosen.
<montjoie>
Amit_T: perhaps wens will have a better answer
<montjoie>
Amit_T: because the other address space are for totally different thing
<montjoie>
Amit_T: not only clock, it is where we choose the MII type
<Amit_T>
montjoie: why it has been choosen "ethernet-phy@01c00030", when EMAC-EPHY Clock Register sits an offset of 0x30 from base address 0x01C00000 ?
2016-04-14
<scream>
montjoie, thanks for the rgmii info. I will try to use the opiplus dts
<montjoie>
you need to create it, with sunxi_defconfig
<montjoie>
scream: so you need to do the same than opiplus
<montjoie>
scream: the opione seems to have an rgmii in fact
<montjoie>
scream: could you paste the dts diff ?
<montjoie>
scream: the reset timeout is bad
<scream>
montjoie, sorry got it working with your .config
<scream>
montjoie, I still get net eth0: PHY already attached
<montjoie>
(adding ephy and emac)
<montjoie>
at least the same content
<montjoie>
so you could use the same patch
<scream>
montjoie, that's what I thought. the only difference is soldered port count and 512MB ram
<montjoie>
scream: opione seems to have only 10/100 ethernet so the same as opipc
<scream>
montjoie, how is it different from opi pc in the ethernet part?
<montjoie>
scream: I dont think have done dts patch for opione, but adding it should be easy
<montjoie>
basicly, what's your board ?
<montjoie>
gentoo crosscompiling
<montjoie>
scream: yes my github sun8i-emac-wip should work
<willmore>
montjoie, *highfive* Well done!
<scream>
montjoie, so the one on your github works well now? :)
<montjoie>
willmore: the sun8i-emac driver is working
<willmore>
Isn't montjoie working on eth and I thought I saw someone else was working on the USB driver where the issue was the reset lines.
<montjoie>
I have some idea on tx locking also
<montjoie>
i need "ethtool -S eth0" after to check
<montjoie>
I think it could be better
<montjoie>
tkaiser I have updated my emac driver if you want to bench with GbE
<montjoie>
a sort of "If they are set, just ask the kernel to do CRC itself"
<montjoie>
wens: rx_payload_error and rx_header_error are in fact counter about non-basic-IP frame that MAC cannot handle CRC (like ARP :)). I believe that I will perhaps can do better than just ignoring them latter
<montjoie>
basicly
<montjoie>
when tx_stop_queue raise, try to increase nbdesc_tx and for rx_dma_ua try increase nbdesc_rx and see if perf raise also
<montjoie>
rx_dma_ua
<montjoie>
wens: I am interested in the other stat counter like rx_dma_stop and tx_stop_queue
<wens>
montjoie: ethtool -S shows rx_payload_error & rx_header_error going up
<wens>
montjoie: iperf running between cubietruck and cubietruck plus gives 300 Mbps / 500 Mbps and no errors :)
<wens>
montjoie: one thing i run into is if you bring the interface down, then up again, it stalls
2016-04-13
<montjoie>
I have updated my github branch for sun8i-emac, if someone with GbE could run some iperf and send me ethtool -S eth0
<tkaiser>
montjoie: :)
<montjoie>
and without the rx errors rate
<montjoie>
tkaiser: my current tree should be ok for external GbE, but I will release tonight a new version with ethtool stats support for tuning better performance
<tkaiser>
montjoie: So all that's needed is adoption of jernej's fixes for external GbE PHY? When I did testing on BPi M2+ I got 462 MBits/sec in both directions when testing in parallel (iperf -d). But I reverted a few of wen's fixes by mistake before :\
<montjoie>
tkaiser: the BSP ethernet driver does not use those two error bit for rx frame. solution confirmed
<montjoie>
tkaiser: I use official allwinner sdk (Draco H3_SDK_20150601_lichee)
<tkaiser>
montjoie: Which BSP source? Don't you rely on ssvb's initial import or Yann Dirson's?
<montjoie>
I need to build a kernel from the BSP source I got
<montjoie>
I know it seems weird
<montjoie>
not the same
<tkaiser>
montjoie: You said people using 3.4 kernel are not using BSP Ethernet driver, right?
<montjoie>
tkaiser: think about ?
<tkaiser>
montjoie: Why do you think so?
<montjoie>
and probabbly all people running 3.4 have different driver than the BSP source code
<tkaiser>
montjoie: Ok, then by looking into BSP the last missing pieces can be added?
<montjoie>
so the two error bit could be ignored
<montjoie>
the other is for "unsupported header" (so why ARP is)
<montjoie>
one bit is "reserved"
<montjoie>
I just see it
<montjoie>
for the rx error rate the solution is in the BSP source code
<tkaiser>
montjoie: Ok, different story. All the GbE H3 boards use 8211E
<montjoie>
my h8homlet with A83T have the AC200 PHY
<montjoie>
for the moment I have only internal PHY board working
<tkaiser>
montjoie: Did you also do some testing with external GbE PHY on your own?
<lennyraposo>
montjoie
<wens>
technically montjoie is working on it :)
<montjoie>
I have added ethtool stats to the sun8i-emac driver, now detailled errors stats are availlable. but still no clue for the high rx error rate:(
2016-04-12
<montjoie>
lennyraposo: H3 and A64 have the same ethernet MAC
2016-04-11
<montjoie>
I always stack all my patch against linux tree, perhaps its bad
<plaes>
montjoie: why don't you just use hans's sunxi-wip?
<montjoie>
it seems that the missing patch does not apply cleanly on 4.6:(
<montjoie>
I will recheck
<montjoie>
I believed to grab all those patch
<montjoie>
mine:)
<montjoie>
hello does someone have any idea of what I miss to made USB work on opipc ? hci logs and CONFIG here http://pastebin.com/9upqJKUH
<wens>
montjoie: ephy driver needs a bit of rework to build as a module
2016-04-10
<alain__>
montjoie: thanks for your work on this driver and for adapting to the opi plus, will test and let you know how it goes
<montjoie>
hello I have just updated my sun8i-emac branch with proper patch for phy regulator of opi plus
2016-04-08
<kdubious>
montjoie: 4.5 rc3 has working Ethernet on A20?
<montjoie>
oups rc3 in fact
<montjoie>
and in rc2 it workd
<tkaiser>
kdubious: IIRC montjoie said Ethernet with A20/4.5 would be broken
<montjoie>
wens: ok
<wens>
montjoie: but if you mean regulator for external phy, then no, that has to be added to the ethernet driver
<wens>
montjoie: i'll check the schematics
2016-04-07
<tkaiser>
ssvb: I allowed it to decrease down to 240MHz and won't spend any more time on this board (just testing GbE to help montjoie, wens et al.)
<montjoie>
wens: the phy regulator must go via your driver ?
<scream>
montjoie, can I have the kernel .config you use when you compile sun8i-emac-wip?
<montjoie>
oh it revert sun8i_hack:)
<tkaiser>
montjoie: With these patches a bidirectional iperf3 run results in 461 Mbits/sec in both directions and using the older iperf (version 2) you can kill reliably network :)
<montjoie>
but the main problem is emac reset timeout
<montjoie>
scream: which hardware ?
<scream>
montjoie, i have compiled your tree branch sun8i-emac-wip with the usb patches and i get "net eth0: PHY already attached" oops when i try to bring up the interface
2016-04-04
<wens>
montjoie: the rx error rate is quite high :|
<wens>
montjoie: updated both my a83t and h3 branches
<wens>
montjoie: ok
<montjoie>
solved
<plaes>
montjoie: You don't have permission to access /ethernet/0108-ARM-dts-sun8i-Add-support-for-H3-usb-clocks.patch on this server.
<montjoie>
but tx is stabble, no timeout
<montjoie>
wens: sorry I misread you. Still rx errors
<alain__>
montjoie: btw I'm getting errors when building the kernel straight from your tree
<jernej>
montjoie: probably you should remove pins PD6, PD11 and PD14 from emac_rgmii_pins definition, because they don't have any functionality (RGMII_NULL) and at least PD6 is used for other stuff
<montjoie>
iperf in parallel with compile on NFS
<tkaiser>
montjoie: So no more lockups when testing bidirectional traffic? Nice
<montjoie>
but the tx queue seems very stable now, I need to publish latest patch
<montjoie>
alain__: sorry no work at all on rgmii, too busy debuging tx timeout
<alain__>
montjoie: any changes to the emac external PHY code?
<montjoie>
scream: I just need a final test after removing debug and some memory barrier
<montjoie>
scream: yes, since it seems working for more than one hour I will release them
<scream>
montjoie, nice! can you share the patches?
<montjoie>
apart from that 95Mbit/s in reception and 85Mbit/s transmittion (not bad)
<montjoie>
the probability of a frame with all errors is too low:)
<montjoie>
I think the best way(suggestive) is to set all error bit to said "dont touch it"
<montjoie>
testing my last try, champagne for 3h of iperf without problem
<montjoie>
but I am near from a solution (49minute of iperf without problem)
<montjoie>
but I need to clean all frames, if I hit a case where I left a skb and no network during 5s ... boum
<montjoie>
because 0 is also the value for (I am setting all values on other part of descriptor)
<montjoie>
the design of setting a bit (dma can work on this) and the same bit at 0 said it is sent is bad
<montjoie>
and I hit some case where interrupt fire when preparing a frame
<montjoie>
because it is hard to know if a frame is sent or in preparation
<montjoie>
I begin to understand why EMAC BSP driver use only NAPI
2016-04-03
<scream>
montjoie, it helped with rtl_tcp. no more lockups there
<montjoie>
strange the issue disapear with that (at least extremly less frequent)
<montjoie>
more than that, users complains
<montjoie>
never more than 2000 bugs:)
<montjoie>
uncomment smp_{rw}mb and set DESC_BUG_MAX to 2000
<montjoie>
scream: I am currently trying to solve this issue
<montjoie>
:)
<montjoie>
NETIF_F_HIGHDMA
<montjoie>
it exist a net flag if driver handle HIGHMEM
<longsleep>
montjoie: yeah, i am new to this maybe i misinterpreted and the mm functions somehow handle it internally if there is no need for mapping
* montjoie
need to re-read DMA doc
<montjoie>
interesting the dma_single problem since I use it for sun8i-emac...
2016-04-02
<tkaiser>
montjoie: AFAIK this is done in u-boot: u-boot.cfg:#define SUNXI_SID_BASE 0x01c14200 (has to be adjusted for H3/A83T anyway)
<montjoie>
but I believe to have read something with SID
<montjoie>
I need to see how it is done on other board (A20 stmmac)
<tkaiser>
montjoie: I think the issue will be resolved when Ethernet support in u-boot is ready and MAC address will be generated from SID?
<montjoie>
tkaiser: EMAC have no storage for MAC address, so the only solution for now is to store it in DT
<montjoie>
I was searching for network testing tool at the moment
<montjoie>
I will try iperf
<montjoie>
tkaiser: the sun8i-emac timeout was not properly tested for the moment
<tkaiser>
montjoie: I found one way to kill network: On another machine doing 'iperf -s' and then on the OPi PC: iperf -c $other-machine -d
<montjoie>
just I need to release my few modifications since last github update
<montjoie>
tkaiser: wens branch have just PHY clk patch in addition
<montjoie>
apart from that, it is very stable (compiling forever my gentoo over nfs)
<montjoie>
tkaiser: for the moment no, still rx errors bit set but frame is good
<tkaiser>
montjoie: Any progress with sun8i EMAC in the meantime? :)
<laga>
montjoie: okay. i don't know if I want them to merge it :) i figured I'd try going through linux-sunxi, but going through them may also be feasible
<montjoie>
laga: if the patch is about power subsystem and you want them to merge it, perhaps it is better to "TO" them
<montjoie>
Since the DTS patch is about the power subsystem, CC them
<montjoie>
if the serie is about the same subject, it is better that all people see the whole serie
<montjoie>
laga In my first tries, I was trying to "segment" mail. It is not worth the time.
<laga>
montjoie: Should I have different people receiving the mail for the patches in a series? I assume I should not CC the power subsystem people for the related DTS change.
<montjoie>
laga: yes
<laga>
Amit_T, montjoie: duh, yes, I am using mainline, but the sunxi-next branch.
<montjoie>
the issue is known but the patch is still not merged
<montjoie>
laga: you have a kernel > 4.5?
2016-04-01
<montjoie>
I think
<willmore>
montjoie, are you sure you're holding it right?
<montjoie>
something set error bit even if all is good
<montjoie>
lol if I detect all error bit, all my frames are in error no RX at all
<montjoie>
I will republish an update
<montjoie>
:) I have just removed that line
<Amit_T>
montjoie : Sorry again , why we have /*v |= BIT(30);*/ commented on line 753
<montjoie>
Amit_T: I was using it, but yes in final driver I think it is useless
<Amit_T>
montjoie: Sorry to bother you , May be I am wrong here, you defined a macro named SUN8I_EMAC_TX_CUR_DESC but nowhere you used it , Shouldn't it be removed if we never going to use it ?
<montjoie>
so RX erros seems -EMYFAULT
<montjoie>
plaes: no errors on 3.4?
<montjoie>
thanks rds
<plaes>
montjoie: no errors ^^
<montjoie>
ok
<montjoie>
wens: I will integrate your PHY patch and with that I could send a first proper RFC version
<tkaiser>
montjoie: I know, but can't help since no free H3 device to test with. Just the OS image to test with for you (see link above)
<montjoie>
for knowing if its hardware or driver fault
<montjoie>
tkaiser: I ask also for 3.4 BSP
<tkaiser>
wens: ok, I thought montjoie was asking whether RX errors also occur with 3.4/BSP driver
<wens>
montjoie: mine (with my branch) has lots of RX errors
<montjoie>
does for reboot I need something ? like power control (AXP ?)
<montjoie>
I have tried to reboot my opipc but it is stuck after "system is rebooting" message (with or without FEL and uart that i tried in case of power leak)
<montjoie>
I will update my github this afternoon
<montjoie>
Amit_T: wens I has made a bad calculation, fixing it
<Amit_T>
montjoie: Sorry to bother you. As per your patch for dts, emac register range is given as reg = <0x01c30000 0x1054>; but its 64k region which should be written as reg = <0x01c30000 0x10000>; (Sorry if I am commenting on your older patch)
2016-03-30
<montjoie>
alain_: no sorry
<alain_>
montjoie: hi, any updates to the emac driver worth testing on the OPI Plus?
<montjoie>
it was the sdcard:(
<montjoie>
ok
<ssvb>
montjoie: in FEL mode, the BROM obviously takes care of initializing whatever is required for a working USB OTG hardware
<ssvb>
montjoie: for example, vishnup encountered some PLL setup problems in the past on A83, where things worked in FEL mode but not from the SD card
<ssvb>
montjoie: in theory, FEL boot is not exactly the same as SD card boot because the BROM may initialize the hardware in a slightly different way
<montjoie>
the device works fine with FEL, but I will try another SD
<jelle>
montjoie: I do
<ssvb>
montjoie: buggy software or unreliable hardware?
<tkaiser>
montjoie: Data corruption? SD card gone bad?
<montjoie>
nobody use opipc with mainline here ? and can report that I am alone
<montjoie>
so using zImage could help, but why I get bad CRC
<jelle>
montjoie: but my unknown u-boot build worked, don't remember which version it was
<montjoie>
jelle: ok
<jelle>
montjoie: I can test u-boot master tonight
<montjoie>
anybody here already got some "Verifying Checksum ... Bad Data CRC" wih u-boot ? On my opipc I cannot get kernel boot
<montjoie>
thanks:)
<willmore>
Goog work, montjoie!
<montjoie>
wens: but the default need to be good
<montjoie>
wens: making possible to change at runtime the number of descriptors is in my TODO
<wens>
montjoie: seems like this could be made a module option? then you could just unload/reload the module with a different setting to test
<montjoie>
wens: and soon I will bench for finding the right number to use
<montjoie>
wens: I have increse the number to 64
<wens>
montjoie: anything preventing you from increasing the number?
<montjoie>
forcedepth use 64 for TX and 128 for RX
<montjoie>
wens: reading documentation said that I need to stop txqueue if the number of free descriptors is below MAX_SKB_FRAGS(16). So a nbdesc of 16 is really too low:)
<montjoie>
I currently read all ethernet driver and they all use more than that