<montjoie>
need to finish my mini datacenter with relay for powering up
<montjoie>
certainly, I await for test it, but my bpim3 is down
<montjoie>
no
<montjoie>
I will try after work with your tip, but without polling I was stuck with 300/400
<montjoie>
jmcneill: what's your performance for 100 and 1G ?
<jmcneill>
montjoie: I implemented polling last night and it didn't make any measurable improvements in rx performance :/
<jmcneill>
montjoie: great!
<montjoie>
jmcneill: for 100Mbit it made transmi from 84 to 94Mbit/s
<montjoie>
jmcneill: thanks for the BIT(2), I confirm the speed gain, at least on 100Mbit, will test Giga later
2016-06-28
<montjoie>
I will try it
<montjoie>
bit(24) ?
<montjoie>
jmcneill: good idea
<montjoie>
I think polling is really necessary for >=1000Mbit/s cards
<montjoie>
because without NAPI I got the same numbers
<montjoie>
jmcneill: do you are full interupt or BSD could do the same than linuxNAPI
<montjoie>
trying 2 or 3 client paralell
<montjoie>
both tcp and udp
<montjoie>
jmcneill: net-misc/iperf-3.0.12
<montjoie>
jmcneill: iperf
<montjoie>
for giga, tx:400Mo/s rx:700Mo/s in my memory
<montjoie>
jmcneill: for 100 tx: 80 rx:90
<montjoie>
good but could be better
2016-06-26
<montjoie>
oh already done... one less to do
<jmcneill>
montjoie: ethernet driver?
<montjoie>
porting my driver to xBSD is on my todo list but lack of time...
2016-06-25
<Da_Coynul>
getting sun4i-usb-phy: probe of 1c19400.phy failed with error -22 with Orange Pi PC (Allwinner H3) using montjoie's kernel
2016-06-24
<montjoie>
apritzel and for better parano, never compile as your usual user
2016-06-21
<montjoie>
Amit_T: see my v2 branch, dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
<montjoie>
the only call added for 64bit is the dma mask
<montjoie>
my driver is the same for a64 and h3/a83t
<montjoie>
I think
<Amit_T>
montjoie: I tried it on A64 but it didn't work, is this cache invalidation api's same for both armv7 and armv8 ?
<montjoie>
Amit_T: Setting syscon is the only thing to do
<Amit_T>
montjoie: Hello, wanted to know what extra changes are required to make external PHY work(Enable RMII Module bit needed to set , apart from it)
2016-06-19
<apritzel>
montjoie: very impressive work on your driver! Just saw the fixes in your new branch
<Da_Coynul>
montjoie, I spoke too soon...unplugged and replugged ethernet cable and now looks like it's working
<Da_Coynul>
montjoie, with your kernel the link is down and I cannot bring it up at all
<montjoie>
try mine
<montjoie>
Da_Coynul: which kernel do you use ?
<montjoie>
any dmesg related to phy/emac ?
<longsleep>
so if that would just work with montjoie driver for those people then its a nice reason to use mainline
<montjoie>
and now emac run faster with mainline:)
<montjoie>
and since grsec doesnt care about drivers/*, I see no obstacle to use grsecurity with any sunxi board
<montjoie>
planned to try, but grsec for arm is not really supported ?
<montjoie>
yes it boots thanks, now come the HARD part, finding a correct hostname for it:)
<apritzel>
montjoie: does adding "select PINCTRL" in arch/arm64/Kconfig.platforms fix it for you?
<montjoie>
but clearly something is missing, since I cannot even see pinctrl via menuconfig
<montjoie>
:)
<montjoie>
I use the a64-v5, not the good one ?
<apritzel>
montjoie: ah yes, did you use the a64-v5 branch? The fix is to add "select PINCTRL
<montjoie>
perhaps related to the warning for PINCTRL_SUN50I_A64
<montjoie>
no pinctrl builded
<apritzel>
montjoie: did you use defconfig? I Put everything in defconfig and try to avoid magic configs
<montjoie>
apritzel: I got no message about mmc does I need to enable something ? could you share your .config (perhaps put it on github)?
<montjoie>
boot successfull but waiting for ever for mmc
<montjoie>
yes I read that in the commit log:)
<apritzel>
montjoie: yeah, we only need one, because I told boot0 to load U-Boot from sector 80 instead of 38192
<montjoie>
just have read the commit.. so normal
<montjoie>
apritzel: how many partitions does your new pine64_firmware-20160601.img.xz need to have ? after dd I see only one
2016-06-17
<dave0x6d>
but yeah, montjoie is right, the holocaust isn't really talked about much over there.
<dave0x6d>
montjoie: is it china or thailand that randomly puts hitler in weird contexts?
<montjoie>
for chinese SS is foreign history, i dont think they think about it
<montjoie>
Security System for older one
<montjoie>
for H3 its named crypto engine
<dave0x6d>
montjoie: oh cool, what should terms should I be google'ing?
<montjoie>
the hard work is handling scattered/non aligned data
<montjoie>
dave0x6d: willmore: yes H3 crypto is under work, the easy part is done (aes/md5/shax)
<willmore>
montjoie was working on the hardware crypto engine in the H3, IIRC. I don't know if he(?) posted benchmarks yet. It was a WIP last I heard.
2016-06-16
<montjoie>
KotCzarny: could you retry with only one CPU under BSP ?
<montjoie>
but I do not think that the problem is that
<montjoie>
they do less memory barriers
<montjoie>
good question
<montjoie>
it is why I am not happy
<montjoie>
alain_: with BSP KotCzarny give me results of 600Mbit/s
<alain_>
montjoie: at least good news is that I've been running your driver for 10+ days on my OPiPlus and that it is stable, no issues to report.
<alain_>
montjoie: how much can the hardware deliver with the BSP driver?
<montjoie>
380/280Mbit/s
<montjoie>
even with NAPI for TX and RX, the performance are not what I expected:(
2016-06-13
<montjoie>
I try
<montjoie>
raaah I have done NAPI for RX but get only 280/380mbit/s
<tkaiser>
jrg: In Armbian forum someone wanted to use his OPi as AppleTalk device. Not possible with this 3.4.x BSP kernel. Switching to mainline kernel --> everything works perfectly now (and this must've been a very early version of montjoie's driver since this has happened months ago)
2016-06-11
<apritzel>
unfortunately montjoie seems to have removed his branch with those patches from his github
2016-06-10
<montjoie>
BSP use NAPI, so NAPI seems necessary
<longsleep>
montjoie: without any tweaks, just default settings
<longsleep>
montjoie: well Pine64 GMAC does 680MBit/sec sending with BSP Kernel
<montjoie>
yes
<KotCzarny>
montjoie: you mean, gmac ?
<montjoie>
really curious to know if emac could do more than 300Mb, perhaps with NAPI
2016-06-09
<montjoie>
no, and the last patch is old
<montjoie>
oneinsect: ethernet driver was submitted and I have mostly finished corrections (soon v2)
<oneinsect>
usbs working and ethernet montjoie:
<montjoie>
like my feature matrix for Crypto on sunxi.montjoie.ovh
<montjoie>
:)
<montjoie>
i have an idea for mainlining page, how about a feature matrix (SoC x feature) (with direct link to the wiki info) and beautifulcolor like green(mainline) yellow(driver done) red(nothing)
<montjoie>
oneinsect: see the mainlining wiki page, I dont know what feature you expect
<montjoie>
gentoo \°/
2016-06-07
<montjoie>
apritzel: yes lots of work
<apritzel>
montjoie: wow, just skimmed over Florian's review, _now_ you got work ahead ;-)
2016-06-05
<montjoie>
thanks, I didnt see it
<montjoie>
Dodger78: could you give the commercial name of your product ?
<montjoie>
Dodger78: strange, I got the same problem, but at final my hdd burn...
2016-06-04
<montjoie>
boobypi could you pastebin the diff that made it work ?
<montjoie>
boobypi you copu code from emac_init to emac_open but where ? at start or end..
<montjoie>
boobypi you use openwrt ? (which version)
<montjoie>
boobypi: I have sent the last version yesterday so yes the link is good
<apritzel>
montjoie: be brave and just fix what he suggests ;-)
<montjoie>
apritzel: :) I fear the comment from dmiller...
<apritzel>
montjoie: thanks for the post! will comment on it later
<montjoie>
wens: I will send the first 4
<montjoie>
but I will integrate your comment:)
<montjoie>
wens: I didnt work on last 3 since I will not send them:)
<montjoie>
could you give me your comments about "commit messages"
<montjoie>
wens: I have update my emac branch with your comments
<montjoie>
ok
<montjoie>
for the board, only opipc could be sent, since opiplus use the regulator
<montjoie>
ok
<wens>
montjoie: do 1 thing per patch
<montjoie>
why ?
<wens>
montjoie: i suggest splitting emac device node and emac rgmii pin into 2 patches
<montjoie>
now time to prepare cover letter for emac
<montjoie>
wens: perhaps
<wens>
montjoie: your branch included a merge of some scsi fixes?
2016-06-02
<alain>
montjoie: bad news, I had another occurence of my OPI Plus network connectivity dropping, solved by a simple ifdown && ifup. No specific kernel messages.
<montjoie>
alain: you could also try to bisect the problem
<montjoie>
so keep wens one for the moment:)
<montjoie>
probably
<alain>
montjoie: I understand your kernel has been more recently rebased than wens', means the USB disk timeout issue I'm having is likely gone in the mainline tree, correct?
<montjoie>
alain: thanks for the info, nothing prevent me for sending it:)
<alain>
montjoie: regarding the systemd issue I mentioned earlier, after further investigation this is linked to timeouts in mounting disk devices, so nothing to do with the emac driver.
<apritzel>
montjoie: works on the 100MBit Pine64 as well
<montjoie>
ok
<apritzel>
montjoie: I think it's safe to drop any pins that are labelled as "R*MII_NULL"
<montjoie>
ok, i will also add that as comment
<apritzel>
montjoie: oh yeah
<montjoie>
apritzel: I think I will try monday to send it
<montjoie>
I just wait for alain issue to be resolved
<montjoie>
apritzel: now nothing
<apritzel>
montjoie: wens: is there anything that prevents us from posting the sun8i-emac driver?
<montjoie>
wens: seems that I need to remove thoses pins:)
<alain>
wens: going at it a 3rd time, same issue. With your kernel I get a clean boot, with montjoie's systemd times out on [ OK ] Found device /sys/subsystem/net/devices/eth0.
<alain>
montjoie: rebooting on wens' kernel solves the issue
<alain>
montjoie: times out waiting for the eth0 interface to come up and drops me into emergency mode, by then the interface has had the time to come up and works fine.
<montjoie>
alain: what is the issue with systemd ?
<alain>
montjoie: yours is sun8i-emac-wip and wens is bpi-m2p-emac
<montjoie>
alain: which exact branch do you use from wens and I (could you diff the sun8i-emac.c on pastebin ?)
<alain>
montjoie: just tested your latest sun8i-emac driver, it works, however compared to wens' driver it takes more time to initialise and creates issues with systemd at boot time.
<boobypi>
montjoie: I trying your EMAC driver with linux4.6 uboot2016-05 and it's great. Only little bug i see, i must plug an ethernet cable at startup if not : Could not attach to PHY. Thanks a lot
2016-06-01
<montjoie>
I have updated it with wens fix
<montjoie>
alain does it work with mine branch ?
<alain>
montjoie, wens : happy to report success for sun8i-emac driver on OrangePI Plus (running wens' latest version). You guys rock!!
<apritzel>
montjoie: then compile a64-v5 with defconfig and put the resulting "Image" to the FAT partition on the microSD
<apritzel>
montjoie: so for the time being: just use the firmware image, that has everything you need: boot0, ATF with PMIC enablement and the latest U-Boot
<apritzel>
montjoie: but you can't rebuild the firmware stuff without my ATF patches
<montjoie>
apritzel: which uboot branch I need to use your a64-v5 ?
<montjoie>
wens: yesterday alain with your fix have the emac timeout problem, so probably a regulator problem for opiplus
<wens>
has a fix from last night that montjoie hasn't included
<jonkerj>
I've tried wens' h3-emac, jwr's sunxiwip, and montjoie emac-wip, but they all fail
<apritzel1>
montjoie: yes! Could ssh in yesterday
<montjoie>
apritzel1: so the ethernet works now ?
<montjoie>
wens: your fix also made some progres on opiplus of alain
<montjoie>
wens: cool, was my fault to not reread syscon patch
<alain_>
montjoie: same error messages, nothing new
<apritzel>
montjoie: and now I have to clean up all the debug mess from the last two weeks ... ;-)
<alain_>
montjoie: here we go, rebooting with dev_info
<montjoie>
just for knowing if I can test it also
<montjoie>
apritzel: but you have done also something in uboot right ?
<apritzel>
montjoie: until I get your driver working: yes ;-)
<montjoie>
apritzel: a64-wip is still the good branch to use ?
<montjoie>
alain_: probably
<montjoie>
wens: ok
<wens>
montjoie: let me do a fix for you, but i won't be able to test until tomorrow
<montjoie>
alain_: could you replace dev_dbg by dev_info on regulator mesages ?
<montjoie>
apritzel: yes
<apritzel>
wens: montjoie: the error message looks very similar to the one I got
<wens>
montjoie: but the default value selects internal phy......
<wens>
montjoie: right, so the bug is that for external phys, it was only resetting the syscon to the default value
<alain_>
montjoie: looks like adding the debug statement didn't change anything
<wens>
montjoie: might have found the bug, let me dig through some code
<montjoie>
#define DEBUG:)
<montjoie>
could you add #DEBUG on top of sun8i-emac.c and recompile
<alain_>
montjoie: same error as yesterday
<montjoie>
for fatest build you could just get sun8i-emac.c file
<montjoie>
on regulator
<montjoie>
yes some report from wens
<montjoie>
alain_: could you retry my new branch ?
<alain_>
montjoie: did you ever get reports of the sun8i-emac driver working on the OPI Plus?
<wens>
montjoie: ARCH_SUNXI || COMPILE_TEST
<montjoie>
mripard: wens for NET_VENDOR_ALLWINNER, I want to permit COMPILE_TEST, do you think the best is just replace ARCH_SUNXI (since other driver already have depend on ARCH_SUNXI) or to put ARCH_SUNXI || COMPILE_TEST
2016-05-30
<alain>
montjoie, tkaiser: anything else you'd want me to try before I switch my opiplus back to legacy kernel?
<montjoie>
alain: no other message from emac (dmesg |grep -i emac) ?
<montjoie>
alain: it worked before right ?
<montjoie>
alain: we change the handling of phy from external driver to internal
<montjoie>
alain: perhaps I forgot something in the dt
<montjoie>
alain for which board ?
<montjoie>
tkaiser: KotCzarny thanks for the info
<tkaiser>
montjoie: Micro USB is 1.8A max by design/specs. That is the first problem (since under heavy load and especially with connected peripherals the board needs more). And then USB cables are prone to voltage drops (resistance) and encourage people to use the wrong 'PSU' (eg. crappy phone chargers or 'smart' chargers that do not provide more than 500mA if the device on the other end of the cable is too dumb to signal a need for
<alain>
I'm testing montjoie's latest sun8i-emac driver, getting the following error: sun8i-emac 1c30000.ethernet eth0: Could not attach to PHY, any ideas ?
<KotCzarny>
montjoie: because uUSB is limited to 1.8A at best
<ssvb>
montjoie: barrel DC is a bit more foolproof
<montjoie>
tkaiser: why do you prefer barrel DC than uUSB for power ?
<montjoie>
wens: apritezl I have updated my github emac branch
2016-05-27
<montjoie>
but I will try it on opipc
<montjoie>
apritzel1: I test on bpim3, so without PSCI only one core
<montjoie>
:)
<apritzel1>
montjoie: concurrently on all cores!!1!1!
<montjoie>
lets start a cycle of 10000 ifconfig down/up
<montjoie>
I throw up
<montjoie>
Before the Hash algorithm is operated, the SS controller need reset, which avoid the influence of other algorithms
2016-05-26
<montjoie>
apritzel: dont know
<apritzel>
oh, montjoie, wens: do you know if the Ethernet MAC retains a MAC address in the SUN8I_EMAC_MACADDR_* registers across initialisation?