2016-03-11

<cosm_> montjoie: thanks, good to know
<montjoie> cosm_: I confirm, do not update to rc7:)

2016-03-10

<cosm> montjoie: I see. It's a remote machine, so I'm not going to try to reproduce it since it might make it unreachable
<montjoie> I need to bisect to confirm
<montjoie> cosm: because I lost ethernet link since 4.5-rc7
<cosm_> montjoie: 4.5-rc2 IIRC
<montjoie> anybody with a cubieboard2 with kernel > 4.5rc6 ? (and a working ethernet)
<montjoie> x is for any number, allwinner call their SoC sun4i sun8i etc..

2016-03-03

<montjoie> but still no ping answer (only arp)
<montjoie> it seems that I got full duplex now from my EMAC
<montjoie> and ac200:)

2016-03-01

<wens> montjoie: i also did a bunch of cleanup on your driver, though haven't tested it
<wens> montjoie: sun8i-emac should be fine
<montjoie> apritzel: for a general name I agree, but all binding name I see have always 3 part
<apritzel> montjoie: what about "sun8i-emac" as the generic name in your driver and then every SoC can use a more specific name in addition in case it needs specific settings/fixes/workarounds?
<montjoie> wens: for the official name (and binding) of the ethernet driver, should I use sun8i-h3-emac or sun8i-a83t-emac ?
<montjoie> if someone want a true RNG, my uptime is a good choice

2016-02-25

<montjoie> lots of memory barrier doesnt change that fact
<montjoie> so strange the first descriptor is zeroed and them reset to be used
<apritzel> I will rather debug montjoie driver
<tkaiser> I think montjoie didn't applied all the available patches. They're not scattered that much around but all in one place: https://github.com/ssvb/linux-sunxi/commits/20151223-h3-mainline-smp-hack
<tkaiser> montjoie: Ok, I already applied the necessary patches and enjoy USB on H3 and now your patches break (dtc)
<montjoie> plaes: ok
<plaes> montjoie: hex_dump_to_buffer
<montjoie> tkaiser: because mainline h3 doesnt have usb
<montjoie> apritzel: I will do both, because I hate to bundle too much different patch (opipc base dt and my driver)
<apritzel> montjoie: this is easier to maintain and spread around
<apritzel> montjoie: btw: if you paste several patches together (cat 000?-*.patch > driver.mbox), you get a single mbox file which "git am" takes as well
<tkaiser> montjoie: Thx, why temporarely disable USB?
<montjoie> tkaiser: The rebased patch could be found at http://sunxi.montjoie.ovh/patchs_current/
<jelle> montjoie: I only have the orange pi pc
<jelle> montjoie: cool!
<montjoie> oh thanks but keep it for the moment, I have enought work now something begin to work with opipc
<montjoie> I own no other board to test:)
<tkaiser> montjoie: Wouldn't it make more sense to test with a device with external 8211E GbE PHY instead of the h8homlet?
<montjoie> apritzel: yes you could send feedback
<montjoie> jelle: opipc and h8homlet(A83T)
<jelle> montjoie: cool work on which device do you work?
<apritzel> montjoie: do you want feedback on the list now about the driver in general?
<montjoie> ok
<tkaiser> montjoie: If you start over with clean 4.4 I would apply these 16 patches here: https://github.com/ssvb/linux-sunxi/commits/20151223-h3-mainline-smp-hack
<montjoie> certainly I hacked too much the circular buffer
<montjoie> I had the time to made only one test, so tonight I will investigate why it work only for a few packet
<apritzel> montjoie: old hdegoede branch> yeah, I was thinking so ...
<montjoie> apritzel: I need to rebase my patch, I am based on an old hdegoede branch
<montjoie> apritzel: one undocumented bit, mentionned in Krzysztof Adamski today's mail
<apritzel> montjoie: great, who was the culprit?
<montjoie> hourrah arp replies
<montjoie> in this state, they burnt me
<montjoie> I have already lots of things to do before showing it to netdev
<montjoie> oh yes, a reply on my driver

2016-02-23

<mpmctoo> montjoie: I know, just mentioning the software used :p
<montjoie> that change nothing, it is just like linux mint yesterday (same problem)
<mpmctoo> montjoie: It's running Nginx IIRC.
<montjoie> if apache doesnt have right to write the backdoor, then no backdoor
<montjoie> another web site without selinux/proper rights
<montjoie> ok
<montjoie> It is complicated because I have changed lots of things for debugging
<wens> montjoie: using stmmac as template seems to have made your emac driver very complicated

2016-02-22

<apritzel> montjoie: that would be good, please post it the URL then to the linux-sunxi ML
<montjoie> I need to create a linux github repo also
<montjoie> plaes: If I could avoid more posting until I reduce crappiness
<montjoie> apritzel: Curently based on a git checkout from hans repo. I need to rebase all my stuff on mainline
<apritzel> montjoie: what kernel version was this driver against? something older?
<plaes> montjoie: could you resend to linux-arm mailinglist too?
<montjoie> In general it is when I ask a question that I found the solution, so perhaps tonight...:)
<montjoie> I hope so
<apritzel> also montjoie just posted the Ethernet driver
<apritzel> montjoie: thanks for posting this!
<montjoie> alea jacta est

2016-02-18

<montjoie> I will made a final test tonight for be sure that I wont forgot a debug that break all, and release it after
<apritzel> montjoie: I just briefly looked over it and the code looks reasonable enough to be released
<apritzel> montjoie: just downplay your code in the cover letter or commit message ;-)
<montjoie> but I really hate to release so bad code
<montjoie> yes I know, I will do that since I dont get any progress actualy
<apritzel> montjoie: don't be afraid: just release it as an RFC (if that is what your are thinking about)
<montjoie> apritzel: do you have tested ethernet driver on pine64 ?
<montjoie> Ok now I understand
<montjoie> plaes: yes I suscribed to linux-sunxi. why ?

2016-02-17

<tkaiser> plaes: montjoie: Maybe additional info regarding data corruption: http://forum.armbian.com/index.php/topic/698-a20-hardware-crypto/
<plaes> montjoie: are you subscribed to linux-sunxi?
<plaes> montjoie: o/

2016-02-14

<montjoie> apritzel: you could share it
<apritzel> montjoie: do you care to share the link to your H3 Ethernet driver in development with longsleep?

2016-02-13

<mossroy> montjoie, is there a way to check that hardware encryption is really used? (with cryptsetup benchmark)
<montjoie> mossroy: ok we speak about the same patch
<mossroy> montjoie : I think he's talking about https://lkml.org/lkml/2015/11/16/46 , which I needed to apply to have sun4i-ss drivers in /proc/crypto
<montjoie> if this one, it will be in 4.5, and for stable I do not know
<montjoie> plaes: which patch ? the patch for solving "failed to register md5" ?
<plaes> montjoie: any idea whether that patch has made mainline?
<montjoie> mossroy: the benchmark was done on A20
<montjoie> happy to see sun4i-ss happy user
<mossroy> montjoie : if you're around, you might have an idea?

2016-02-11

<montjoie> If I still found nothing, I will do that
<montjoie> plaes: i2c
<montjoie> ok, but I have no electronic tools at all
<mripard> montjoie: no, I mean a logical analyser :)
<plaes> montjoie: what frequency ranges?
<montjoie> mripard: logical analyzer, do you mean an osciloscope ? (in any case I have nothing)

2016-02-10

<montjoie> exactly ac200 DLDO4 set to 3.3
<montjoie> same log for PH0/1/2/3
<montjoie> and PH2/3 are enabled "sun8i-a83t-pinctrl 1c20800.pinctrl: request pin 226 (PH2) for 1c2b000.i2c"
<montjoie> mripard: I have enabled ac200 power in uboot
<montjoie> this is my DT patch for i2c https://bpaste.net/show/0ce616b1e0e1
<montjoie> and I still have the bus locked
<montjoie> but i2cdetect still detect nothing
<montjoie> mripard: I have just found a thread where you say to use PULL_UP instead of NO_PULL
<mripard> montjoie: have you checked your muxing ?
<montjoie> hello anyone got i2c working on A83T ? I have enabled it but got "i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0"

2016-02-01

<igraltis1> montjoie: http://paste.debian.net/378055/
<igraltis1> montjoie: yes
<montjoie> igraltis1: thanks for the test, have you tested rngtest ?
<igraltis1> montjoie: the hwrng on cubietruck is now working

2016-01-31

<igraltis1> montjoie: i found a md5 patch for sun4i-ss and no error
<igraltis1> montjoie: ok
<montjoie> igraltis1: a have sent a patch, the patch is present on 4.5 and perhaps it will reach stable

2016-01-29

<montjoie> and all others R_device, and pinctrl-r also
<montjoie> So I could ignore it ?
<wens> montjoie: r_twi is an i2c controller in the r_ block
<montjoie> there are lots of R_device (and a pinctrl-r), whats does means R ?
<montjoie> the a83t just give the memory address and nothing more
<montjoie> I see that it exist also a R_TWI, does is this the same as a31 p2wi ?
<montjoie> wens: like this https://bpaste.net/show/a52422b3fbec ?
<montjoie> so I need to split it in two
<montjoie> hello I have done https://bpaste.net/show/b4bb6173d51f for adding i2c on a83t, but I am puzzled the usermanual give two set of 2 pin for twi2_xxx. normal ?

2016-01-27

<montjoie> For EMAC I need the PHY but the PHY is located on AC200 who need RSB (and perhaps PWM). I am going mad:)
<montjoie> yes it seems to change, thanks
<montjoie> thanks I will try it
<Turl> montjoie: compile it and with a bit of luck it will work
<montjoie> no it is not compiled
<Turl> montjoie: is that file being compiled?
<montjoie> drivers/clk/sunxi/clk-sun9i-cpus.c:CLK_OF_DECLARE(sun9i_a80_cpus, "allwinner,sun9i-a80-cpus-clk",
<Turl> montjoie: grep allwinner,sun9i-a80-cpus-clk on drivers/clk/sunxi
<montjoie> I use vishnup tree for a83t
<Turl> montjoie: looks like ahb0 is marked as a root clock or something
<Turl> montjoie: cat the clock tree
<montjoie> hello on A83T my apb0/ahb0 run a 0Mhz, how to change that ?
<apritzel> montjoie should know more about it, I guess

2016-01-25

<montjoie> wens: setting DLDO4 to 3300 is not sufficient
<montjoie> thanks for the link
<montjoie> how do you know that ?
<wens> montjoie: a83T homlet uses the phy in the AC200
<montjoie> and perhaps the problem is the same for H3 (like transmiting need more power than reception)
<montjoie> wens: you said that RGMII need 3.3 but A83T homlet board use the internal MII (according to script.bin), does the internal MII could also need it ? since for the moment I get nothing from it (no LED, EMAC reset timeout)
<wens> montjoie: it's a secondary supply for the gigabit phy

2016-01-24

<montjoie> so it is used by a regulator subsystem
<ilya-fedin> montjoie: Perhaps someone knows when it created? Or I can I can affect it? Or there is a beta? The matter is that the device rolls idle, it kill programs necessary to me.
<montjoie> grep in progress
<ssvb> montjoie: I mean, try to grep the Allwinner's SDK
<ssvb> montjoie: Use the Source Luke :-)
<montjoie> does someone know what means gmac_power1 = "vcc-ephy-io:3300000" in fex file ? what driver use/configure that ?
<wens> montjoie: remember the DT is a tree, with phandle references to labels
<wens> montjoie: you then reference it under the gmac/emac node in the board dts
<wens> montjoie: the definition is under "pio: pinctrl@01c20800 {"
<montjoie> and on a20 the gmac_rgmii is not under pio node
<montjoie> thanks wens it works. But still no emac on A83T:(
<wens> montjoie: see the other .dtsi files
<wens> montjoie: the pinctrl node should be under the pio node
<montjoie> does anyone see why with https://bpaste.net/show/ebe9a97e2e37 I stil got "sun8i-emac 1c30000.ethernet: could not find pctldev for node /soc/gmac_rgmii@0, deferring probe"
<montjoie> thats why my password is HELP:)

2016-01-22

<rds> montjoie: I think the H3 users are growing faster, and if you share the driver, like folks that wrote the HDMI did it, you may have more folks debugging and testing
<rds> montjoie: have you shared your Eth driver for H3 anywhere ?

2016-01-20

<wens> montjoie: you create a node under the pio / r_pio controller, list the pin you want to set, and the function to set it to, and the pull-up/down and drive strength

2016-01-19

<montjoie> Could someone help me with pinctrl, I try to test RGMII on a83T but I dont understand how pinctrl works
<montjoie> does someone with the a83t homlet could confirm that it boots from nand without network/dhcp ? (I need to know which PHY it have)
<apritzel> montjoie sent me his alpha version, which I will try later tonight

2016-01-18

<apritzel> montjoie: just sent a reply to your mail, don't be scared by the length of it: I agree with you at the end ;-)
<apritzel> montjoie: that would be great, can send it privately if you prefer that
<montjoie> just a bit of work for removing crapiness
<montjoie> apritzel: no but I could made it availlable
<apritzel1> montjoie: do you have your H3 MAC driver somewhere already?
<montjoie> since PHY clock are different between H3 and A83T I expect that it will help me to find the problem I got on H3
<montjoie> for the ethernet status: I booted up a83t yesterday and this week i will try to test my driver on it
<wens> network is getting there. it's the same emac as a83/h3, which montjoie is working on

2016-01-17

<montjoie> thanks rds I will compare them
<rds> montjoie, do you still need the 3.4 regs dump ?

2016-01-16

<montjoie> congrats, I wasnt believe that bootstrapping pine64 will be so fast
<montjoie> anybody with an orangepipc under linux 3.4 that can dump memory (0x01C20000 from 0 to 0x304) ?

2016-01-15

<ssvb> Ethernet is still not supported on H3, but montjoie is working on a driver for the Linux kernel

2016-01-14

<montjoie> x86 saves me
<montjoie> :)
<apritzel> (ask montjoie)
<montjoie> so according to rds dump, my EMAC problem is not EMAC_CLK_REG related
<montjoie> so I tested with LED_POL and it change only the way the green led works
<montjoie> thanks I will compare it with mine
<montjoie> rds: could you also dump 0x01c30000 ? 0 to 0xd0
<montjoie> :)
<montjoie> so the only missing part to be the same is to activate LED_POL
<montjoie> 0x12 was very puzzling me:)
<montjoie> rds: better:)
<wens> montjoie: not sure if the homlet board is easier to work with... since the phy is another x-powers chip :|
<montjoie> apritzel: if you could
<apritzel> montjoie: do you want to know the clock settings as well?
<montjoie> but it is good to know they do that also:)
<montjoie> bit 18 is the default but 17 not (I will try it but it is named LED_POL)
<montjoie> apritzel: yes it is what I do
<montjoie> I need to setup it
<montjoie> I have the A83T homlet
<montjoie> but only using 24Mhz works
<montjoie> what do you thing for bit 18 clk_sel 24 or 25 Mhz, for all my readings, all xMII wroks with 25Mhz
<wens> montjoie: right, i meant you shouldn't need to touch the clk bits, just the phy related bits
<montjoie> (desactivate in fact)
<montjoie> wens: yes but I need to activate bit 16 SHUTDOWN for example
<wens> montjoie: yeah, but isn't that the default?
<montjoie> and seems I am sure now the problem is from PHY, I blindly try all options
<montjoie> wens: the EMAC_CLK_REG is neede for selecting MII like the ETCS. register (00: Transmit clock source for MII)
<montjoie> strange because 0x12 meens 10: Internal transmit clock source for GMII and RGMII
<wens> montjoie: for 10/100 you shouldn't need to tweak emac clk bits, only the internal phy bits?
<apritzel> montjoie: what does "internal MII" mean here exactly?
<montjoie> thanks rds, just for info it is not a opipc ?
<montjoie> apritzel: orangepi pc is not with Gbit, only internal MII with 100M max
<montjoie> exactly I need 0x01c0 0000 + 0x30 the emac clk register
<rds> montjoie: dump of 0x01C0_0000 -> 0x12
<apritzel> montjoie: "I think you have connected Pine A64 board to Gbe line. As mentioned in forum, we still encounter issue when connected to some Gbe network, this is driver issue and software engineer currently fixing this issue. The 10/100Mbps works fine."
<apritzel> montjoie: by the way: I got an email from the pine64 guys yesterday: apparently they have issues with gigabit too
<wens> montjoie: furthermore, the reset bit in @0x4 works
<montjoie> wens: no hurry I am at work, so I cannot do any test before this night
<wens> montjoie: give me a sec to get my other a83 board
<montjoie> so it is the moment to begin to play with my a83t for testing the emac driver...
<montjoie> wens: if you could share register dump :)
<montjoie> wens: so not a stmmac ?
<wens> montjoie: a83 emac is likely the same as h3
<montjoie> only transmission failed
<montjoie> this is strange since all packet received are good
<montjoie> but just after it lost the link and re 100half
<montjoie> ONE time I got full duplex
<montjoie> I try to play with MDC and all MII parameters but nothing change
<montjoie> wens: yes communication with MDIO works
<wens> montjoie: is mdio working?
<montjoie> so if someone have an H3 with a 3.4 kernel for dumping content of 0x01C00030 register
<montjoie> seems that the PHY is unstable always got 100halfduplex
<montjoie> I have some good news for H3 EMAC, packet reception and transmission works, BUT packet was never sent by the PHY

2016-01-12

<montjoie> good news, I got interrupt from H3 emac...
<montjoie> maz_: apritzel thanks for the answers
<maz_> montjoie: it looks like your SoC is just limited to 32bit PAs.
<maz_> montjoie: VAs are always 64bit (well, 48bit).
<maz_> montjoie: you're confused. there is *only* LPAE on arm64.
<montjoie> apritzel: so no more than 4Gb RAM on arm64 without PAE ?
<montjoie> apritzel: for all arm64 or just A64 ?
<apritzel> montjoie: the whole SoC just has some kind of a "32 bit address bus"
<maz_> montjoie: looks like yet another brilliant piece of design...
<apritzel> montjoie: no, that is just how it is designed
<montjoie> copy/paste error or arm64 will have only memory adress 32 bit wide ?
<montjoie> since you speak about arm64, what do you think about 32bit register for storing a memory address in A64 user manual ?
<montjoie> sorry
<montjoie> I forgot to put emac in
<montjoie> yeah I just see that it is my function and not some of interupt controller:)
<mripard> montjoie: sun8i_dma_interrupt ?
<montjoie> and any idea on my crash stack ?
<montjoie> ok thanks
<mripard> montjoie: but on the allwinner datasheet, and the interrupts > 31 are SPI
<mripard> montjoie: it depends on the device
<montjoie> I do not see any hints in user manual for finding type of interrupt
<montjoie> but at least it seems a good news since I got interrupt working:)
<montjoie> mripard: thanks for the tips for -32/-16, but how to know the type of interrupt ? I ask that because now I got https://bpaste.net/show/4826f8575114

2016-01-10

<montjoie> I still get no interrupt but things progressing
<montjoie> yeah I checked others interupts values sometime -30 sometime -32
<mripard> montjoie: you have to substract 32 from the allwinner datasheet number
<montjoie> it seems that I badly choose my interupt number in dts, but all number doesnt fit with those in datasheet
<montjoie> and still no interupt for transmition like reception
<montjoie> good news, it seems that first frame was tryed to be transmitted by emac, but an error was caught:)
<montjoie> thanks
<mpmc> mripard:, montjoie I just tried on mine & I get file not found (for clk_summary).
<mripard> montjoie: there's no clk_summary in 3.4
<montjoie> could someone with an orangepipc runnig 3.4 kernel, pastebin the content of /sys/kernel/debug/clk/clk_summary and /proc/interrupts
<apritzel> wigyori: also montjoie is working on a driver from scratch
<apritzel> depending on the progress with montjoie's driver I may post it even next week
<apritzel> montjoie: OK, by now I rewrote good parts of their BSP driver (partly to appease checkpatch), fixed some bugs on the way and found some undocumented bits (like bit24 in the 2nd DMA descriptor word)
<montjoie> apritzel: no I am curently building a 3.4 sdcard for checking value like interrupt/clocks etc..
<apritzel> montjoie: are you around? Any success with your H3 ethernet driver?

2016-01-08

<montjoie> apritzel: yeah I believe that wens said that it was a stmmac but didnt find source of that in my irclogs
<apritzel> montjoie: tkaiser: looks like the A83T has the same MAC as the A20
<montjoie> this afternoon will be long, I found a typo who explain perhaps why nothing get transmitted but I can test only this evening
<montjoie> I am not sure than A83T have the same EMAC
<montjoie> basic network
<montjoie> transmit/recerive frames
<tkaiser> montjoie: How do you define 'success'?
<montjoie> perhaps I will change my way to do it, but I am near to success
<mripard> montjoie: and with bad documentation, starting from scratch becomes a problem
<montjoie> mripard: starting from scratch is not the problem, the bad documentation is
<apritzel> montjoie: mripard: do you mind if I take a look at adapting the original driver?
<montjoie> apritzel: driver is made from scratch
<montjoie> but after seems really garbarge
<montjoie> I receive arp request I send
<montjoie> But I still receive frame, but only the first one seems not garbarge
<apritzel> montjoie: is your driver from scratch or based on some BSP crap?
<montjoie> apritzel: for the moment the H3 Emac driver is not usable, not getting interupt for receiving frame, and nothing get transmitted
<apritzel> montjoie: ah, that's your nick ;-)
<montjoie> I have just get an ethernet dongle, so I will work faster on h3 EMAC driver now
<montjoie> :)
<patap> apritzel: afaik montjoie is working on h3 emac too.http://sunxi.org/Linux_mainlining_effort H3 Emac (WiP: LABBE Corentin)

2016-01-03

<bpi-user> @montjoie: I gotta go now. But I will check the irc logs later in case you post a reply. Thanks.
<bpi-user> @montjoie: Is there a reason your patch ("crypto: sun4i-ss: add missing statesize") wasn't applied yet? I mean this one https://lkml.org/lkml/2015/11/16/46

2015-12-18

<montjoie> I am writing it from scratch
<patap> montjoie: does the h3 emac look similiar to something existing, like A20 gmac stmac?
<montjoie> the crypto driver for h3 only give me zero output for the moment
<montjoie> emac h3