2017-07-19

<montjoie> seems someone with communication problem https://linux-sunxi.org/User_talk:Libv

2017-07-16

<smaeul> montjoie: in my very much WIP dissection of the H5 BROM at http://dpaste.com/196Z1VK, the mysterious code is func_2de8, which turns bits 0 & 1 of the undocumented register on and off in a loop. it's called several different times with different parameters. I assume it's some sort of debugging feature, meant to be detectable from outside the CPU
<montjoie> smaeul: have you tried the datasheet/usermanual ?

2017-07-05

<mripard> montjoie: thanks :)
<montjoie> mripard: will send

2017-07-04

<mripard> montjoie: can you send a patch to fix this ?

2017-07-02

<montjoie> yes AC200 is a MFD
<montjoie> facilities ?
<montjoie> yes, just check PHY ID
<montjoie> MoeIcenowy: yes AC200 seems to work with RGMII
<montjoie> I have some hesitation to send a patch for hacing a new phy driver just to add "AC200" name
<montjoie> on opipc it works as generic phy
<montjoie> I got one
<montjoie> I saw
<MoeIcenowy> montjoie: I did a sun8i_emac on BPi M3 U-Boot
<luoyi> montjoie: yes, but I can't find the wip repo. so I just modify codekipper's branch and get a working one
<montjoie> luoyi: according to http://linux-sunxi.org/Linux_mainlining_effort someone work on it

2017-06-28

<montjoie> meta-sunxi ?

2017-06-26

<montjoie> by selecting the rigth option in make menuconfig
<montjoie> nvz: so just enable software twofish
<montjoie> and for h3 the hardware driver is still in progress
<montjoie> you can still compile it but it will done by softwate only
<montjoie> nvz: no hardware offload
<montjoie> nvz: twofish not supported by hardware

2017-06-12

<fromport> montjoie: maybe change title of this channel ? it is not clear (to me) that this channel is only for kernel development.
<fromport> montjoie: thanks for pointing that out, i will move to another channel ;-)
<montjoie> fromport: why not asking orangepilibra ? this is a buildsystem for non mainline kernel so offtopic
<fromport> montjoie: i am going afk, need be at a place 5 hours from now, time for some Zzzz
<fromport> montjoie: tried to follow https://github.com/OrangePiLibra/OrangePi
<montjoie> BSP mainline other...
<montjoie> fromport: what are your sources exactly ?

2017-06-10

<wens> montjoie: actually whitequark irc logs are searchable
<montjoie> wens: if you want I have 3 years of linux-sunxi logs:)
<montjoie> wens: and why?
<wens> montjoie: thanks

2017-06-09

<montjoie> grepped theobroma
<montjoie> confirm it!
<montjoie> wens: need to dig email
<montjoie> back to old irc time, mripard could I be half op ?
<montjoie> KotCzarny: who are op appart mripard ?
<wens> montjoie: do you remember who it was that noticed the DMA descriptor stuff for sun8i-emac was compatible to dwmac?

2017-06-08

<montjoie> wens: could I send your bpim3 dt patch ? for finish emac
<montjoie> but the second time the same patch apply, it should fail no?
<montjoie> the real question is how such double patch could be done
<montjoie> no luck
<montjoie> I compile always with warning... and each time I try to fix one it is just the start of a spaghetti patchs
<MoeIcenowy> I didn't understamd montjoie's joke until I realized this device node is emac ;-)
<montjoie> double the speed!
<montjoie> MoeIcenowy: strange get no mmc output and wait for mmc for ever

2017-06-07

<MoeIcenowy> montjoie: yes
<martinayotte> @montjoie, using her r40-v2 branch, I've even used eMMC
<montjoie> MoeIcenowy: do you have mmc working on R40 ?

2017-06-06

<montjoie> MoeIcenowy: I test my m2ultra and I see no emac node in your patch series:)
<montjoie> wens: at least the A83T DT could be merged in mripard tree
<montjoie> wens: bus-ce is the same on H3/A64
<montjoie> wens: tried to overclock some clock, no real change
<wens> montjoie: I don't think we'll be able to apply any more h3/a64 patches until the sun8i-dwmac device tree patches are dropped from net-next
<montjoie> oh no aes-arm on my pine64
<montjoie> gentoo nearly same CFLAGS (appart from 32 vs 64)
<montjoie> but some numbers are strange (why pine64 is lower than H3 for generic aes)
<montjoie> mini bench for fun https://pastebin.com/8WXnSV1x
<montjoie> anyway I note on TODO "redo bench"
<montjoie> when fs sector will be up to 4096, hardware crypto will rock
<montjoie> I need to recheck the people trying to patch dmcrypt and co to accept buffer of "not 512"
<montjoie> since SS/CE doesnt do XTS, it will always be outperformed
<montjoie> KotCzarny: I will try
<montjoie> sun8i-ce become cool > 4096
<montjoie> typical usage disk encryption (512)
<montjoie> crypto is always on small size
<montjoie> but
<montjoie> sun8i-ce perf rise with buffer size
<montjoie> it is why I never submitted DMA patch for it
<montjoie> perf/10
<montjoie> sun4i-ss with DMA is unusable
<montjoie> perhaps its DMA
<montjoie> good question, perhaps a sort of all answer
<montjoie> for sun8i-ce its not for the worth at all:)
<montjoie> or few
<montjoie> spoiler: "not the worth"
<montjoie> but yeah the same with pure userspace could be added as a third column
<montjoie> and compare with non-hardware algo
<montjoie> no it use the kernel crypto from user space via AF_ALG/cryptodev
<montjoie> with my cryptotest tool
<montjoie> the bench is in userspace
<montjoie> bench
<montjoie> aka bebcn numbers are old
<montjoie> I need to compare with libkcapi speed test also
<montjoie> but numbers must be updated
<montjoie> cubieboard2
<MoeIcenowy> montjoie: which chip did you use for http://sunxi.montjoie.ovh/ sun4i-ss benchmark?

2017-06-05

<montjoie> techping: lack mmc at least
<montjoie> no linux-next
<montjoie> MoeIcenowy: oh yeah when you said broken, its really broken:)
<montjoie> I love to see my automatic toolchain building all
<montjoie> updating ...
<montjoie> still on 0602
<MoeIcenowy> montjoie: the 24MHz xtal patch?
<montjoie> MoeIcenowy: do you want me to send the patch (or you in a v3s support serie)
<montjoie> right ?
<montjoie> and since all known boards/soc use it... it is simplier to allways enable it
<montjoie> MoeIcenowy: If I understand well, the default syscon value for V3S got BIT18 disabled but need it ?
<jelle> montjoie: but they also hardcoded python2 in the binman shebang so it might just work without it..
<montjoie> will try:)
<jelle> montjoie: but PYTHON=python2 should just work
<montjoie> my "toolcain" patch Makefile compile and revert just after
<jelle> montjoie: yup
<montjoie> pfff uboot need python2.7
<montjoie> techping: slot 0 is "anyphy" so if it not work on slot 1, perhaps slot>1
<MoeIcenowy> montjoie: I think we can just force the CLK_SEL to be 1 (24MHz)
<montjoie> missing _libfdt.so
<montjoie> I was trying to test your patch but unable to build recent uboot
<montjoie> I will check it
<MoeIcenowy> montjoie: have you read my words about syscon reg bit 18?
<montjoie> (or a bug)
<montjoie> oh uboot doesnt support KBUILD_OUTPUT:(

2017-06-04

<MoeIcenowy> montjoie: it seems that it's needed to have a dt property to control the syscon register's bit 18 (CLK_SEL)
<montjoie> hacked so many part of stmmac...
<montjoie> MoeIcenowy: didnt see better than that
<montjoie> MoeIcenowy: yes hidden:)
<montjoie> could you paste your modifications ?
<MoeIcenowy> montjoie: so strange... if I use newly added allwinner,sun8i-v3s-emac compatible, enabling eth0 will fail with "dwmac-sun8i 1c30000.ethernet eth0: Could not attach to PHY"
<montjoie> perhaps just a "bool external_phy" will do the trick
<MoeIcenowy> montjoie: sufficient.
<montjoie> MoeIcenowy: why current emac is not sufficient for v3s ?
<MoeIcenowy> montjoie: maybe I should now make V3s driver -- V3s is like the H3, but without external *MII interface, only ephy
<MoeIcenowy> montjoie: fix sent.
<MoeIcenowy> montjoie: oh I think just run assert on the reset line is OK even if it's already asserted
<MoeIcenowy> montjoie: the problem starts to become complicated
<MoeIcenowy> montjoie: please remove the if sentence in my patch when testing
<montjoie> thanks
<MoeIcenowy> montjoie: https://pastebin.anthonos.org/view/1c5b4587 bpi m2+ patch, if you want
<montjoie> MoeIcenowy: if it works I will updated all my dt patchs and send them
<montjoie> was just stuck in "test everywhere by design"
<montjoie> MoeIcenowy: right
<MoeIcenowy> P.S. montjoie: the code isn't needed to test on A64/A83T -- it's in the EPHY codepath.
<montjoie> removed it and nothin work
<montjoie> MoeIcenowy: yes
<montjoie> in 1 hour childs will sleep and i will test your patch also on pine64/a83t
<montjoie> MoeIcenowy: patchs are on my v6 github
<MoeIcenowy> montjoie: a fixed regulator in fact means a part of the board that can supply a fixed voltage to another part
<montjoie> and so opi+ and opipc2 are pending
<montjoie> mripard: reviewed the patch and said a comment that I need to address
<montjoie> MoeIcenowy: yes I need to understand regulator stuff
<montjoie> for the moment
<montjoie> paultag: yes only net-next/linux-next
<montjoie> yes
<montjoie> MoeIcenowy: could you paste it ?
<montjoie> anyway I will test it on all my boards
<montjoie> MoeIcenowy: yes how can i say no:)
<MoeIcenowy> montjoie: I added a ` reset_control_assert(gmac->rst_ephy); ` before ` ret = reset_control_deassert(gmac->rst_ephy); `
<MoeIcenowy> paultag: the someone is montjoie, who talked to you just before
<montjoie> paultag: emac is in linux-next
<montjoie> clearly lack of test from myself on "boot unplugged"
<MoeIcenowy> montjoie: with cable inserted at boot emac starts properly
<montjoie> MoeIcenowy will try
<MoeIcenowy> montjoie: current linux-next got "EMAC reset timeout" and "probe of 1c30000.ethernet failed with error -12" with no cable plugged at boot with Orange Pi PC

2017-06-03

<montjoie> not so serious, it just delay a bit my personnal "kernelci"
<willmore> montjoie, I have lots of relays, but you're probably not on my continent. :(
<montjoie> it was so few used also:(
<montjoie> pfff first time I power for long time my allwinner cluster, power relay die

2017-06-02

<montjoie> mripard: and syscon@ have a leading 0, so I will probably need to resend
<montjoie> because I forget to add the cover letter (wens> montjoie: you can send all 3, but explain in your cover letter that the 3rd is only for reference)
<mripard> montjoie: I'm confused, why do you send patches you don't want to be merged?
<montjoie> ok found it on schematics
<montjoie> for bpim2+ its PD6 but cannot find where to check why its it
<montjoie> same in schematics ?
<montjoie> and how to know if a regulator is necessary ?
<montjoie> I try to update properly my DT for bpim2+/opi+/opipc2 but how to know which pins is for "gpio_out" ? in schematics?
<wens> montjoie: because I have to reorder the patches and pull out a lot of stuff :/
<montjoie> why not send the bpim3 since it apply cleanly ?
<wens> montjoie: yup
<montjoie> wens: which of your branch should I use for a83t ? a83t-ccu-mmc-usb ?
<wens> montjoie: you can send all 3, but explain in your cover letter that the 3rd is only for reference
<montjoie> or I could just send 2 of 3 patchs (syscon + a83t only)
<montjoie> wens: could you send your patch for bpim3 ? it will permit that I send all dwmac-suun8i patchs for a83t
<montjoie> since the commit only speaked about sun8i-dwmac i thinked it was an error
<montjoie> it seems I see bad
<montjoie> and it seems that the column modifed was A20
<montjoie> dont know, just fixed en unrelated change
<rellla> montjoie: does A10s have GMAC?
<mripard> montjoie: well, I guess he'll be the one fixing up the merge conflicts then.
<montjoie> mripard: too late for DT, I see them in linux-next so certainly via net-next

2017-06-01

<willmore> montjoie, for reals? Yay! Congratulations!
<montjoie> possible, need to check net-next rules
<montjoie> started on 26/11/2015...
<montjoie> YEAH! dwmac-sun8i applied

2017-05-31

<montjoie> :)
<montjoie> lots of user reports the famous "reset EMAC timeout"... anyone here with it ?

2017-05-21

<montjoie> hard day, double bisect in linux-next
<montjoie> argh! someone fount it before https://lkml.org/lkml/2017/5/19/599

2017-05-18

<montjoie> mnemoc: my job is sysadmin if you want

2017-05-17

<montjoie> if all is backupped 1hour:)
<montjoie> for repartionning
<montjoie> why not reinstall ?
<montjoie> libv: for letting the owner knowthat its dead:)
<libv> montjoie: why?
<montjoie> yeah, who own the domain and server ?

2017-05-16

<montjoie> the two doc and the dwo DT patchs
<montjoie> wens: mripard does it is possible to apply/accept syscon patchs from my v5 series ?

2017-05-15

<montjoie> I expect the guy who sent me the "bug" report
<MoeIcenowy> montjoie: just built dwmac
<montjoie> MoeIcenowy: result?:)
<montjoie> dont know
<MoeIcenowy> montjoie: is there any strange difference between internal PHY on opi one and opi zero?
<montjoie> (and after with dwmac for confirming the good value)
<montjoie> if its faster for you
<montjoie> try with emac also
<montjoie> in sun8i_dwmac_reset() readl_poll_timeout
<montjoie> could you try with timeout of 100ms (1000ms?)
<montjoie> since the timeout value are the same
<montjoie> but probably it will do the same with old sun8i-emac
<montjoie> always latest:)
<montjoie> and see if an EMAC reset timeout occur please
<montjoie> boot with no wire plugged
<montjoie> Anyone with an opi zero ? (need a net test)
<qschulz> montjoie: just sent the fix for the bug you reported. I've slighlty changed the patch but that shouldn't impact the test you did. Feel free to retest it and add your Tested-by :)

2017-05-14

<montjoie> for my ethernet serie
<montjoie> mripard: could you accept all 4 syscon patchs for letting the next shot smaller ?

2017-05-13

<montjoie> qschulz: why not adding a delay for only the first one ?
<qschulz> montjoie: thanks for reporting the bug and testing the patch. I get also this ETIMEDOUT (-110) once when inserting the module, basically the first interrupt isn't received in the first second of delay I let him

2017-05-12

<montjoie> still get "thermal thermal_zone0: failed to read out thermal zone (-110)"
<montjoie> qschulz: your patch seems working (at least no crash since 30 min of "watch sensors")
<montjoie> so lost!
<montjoie> ouch an user answering to my first sun8i-emac driver serie...
<montjoie> need to finish the powercontrol by arduino
<qschulz> montjoie: okay, no worries
<montjoie> sorry, could reboot it only at lunch (in 3 hours)
<montjoie> qschulz: started the board just before going to work, forget that it crash few time after..
<qschulz> montjoie: did you have time to test it?
<swiftgeek> montjoie: i'm clueless ;D
<montjoie> swiftgeek: why dwmac will not fit in 4.12. I am near sure it will

2017-05-11

<qschulz> montjoie: ok, no reason it wouldn't work but better be sure. I'll send the patch tomorrow if you can confirm it works on your board
<montjoie> qschulz: I will test it in 4 hour, the board is off/remote
<qschulz> montjoie: http://code.bulix.org/v9yjri-131066 could you test this patch?
<qschulz> montjoie: thanks. I've been able to reproduce it with only sun4i-gpadc-iio built as module. So clear path now to debug :)
<qschulz> montjoie: so you built sun4i-gpadc-iio as a module
<montjoie> when you want, I could test patch
<qschulz> montjoie: investigating this bug you reported
<montjoie> qschulz: pong
<qschulz> montjoie: ping

2017-05-10

<montjoie> KotCzarny: confirmed, seems to need gcc6
<montjoie> hitted the same problem, grepping logs for solution:)

2017-05-09

<montjoie> at least the driver work on A83T
<montjoie> no next IV
<montjoie> pffff just finished cleaning the sun8i-ce driver and pan! just found a critical bug in the silicon...

2017-05-05

<montjoie> same zone ?
<montjoie> 4.5 is old:)

2017-05-04

<MoeIcenowy> P.S. octa core is found broken by montjoie, and I downgraded to quad, which works perfectly
<montjoie> wens: do you tested-by for your a83t ccu patchs ? (tested with all other patch from your branch + PSCI from MoeIcenowy )
<montjoie> hop dropping hash support for sun8i-ce

2017-05-03

<wens> montjoie: you could do it in U-boot, but I recommend not touching the bus clocks once in Linux
<wens> montjoie: maybe DMA can't keep up?
<montjoie> wens: sure that's impossible to put bus_clk to 300 ?
<montjoie> :)
<MoeIcenowy> wens: are you replying montjoie with 400MHz?
<montjoie> wens: very very little increase at 200Mhz
<montjoie> wens: what is the maximum safe value ?
<montjoie> but the parent is already at max 24Mhz
<montjoie> so I could tyr 48Mhz ?
<montjoie> oups wrongly read >=
<montjoie> pine64
<montjoie> 24Mhz
<montjoie> yes the "mod" clock but it is already at max
<montjoie> the datasheet said CE clk could be up to 300, so I expect better performance
<montjoie> ahb1_ce in DT
<montjoie> in /sys/kernel/debug/clk/clk_summary it is bus-ce
<montjoie> does I need to reparent to pll-periph0 ?
<montjoie> how to change bus_ce clock to 300Mhz ? clk_set_rate() end with success but no change
<montjoie> raaah still perf/4 for sun8i-ce (vs aes-generic)

2017-05-02

<montjoie> and I need to convert PRNG to crypto_rng also (for sun4i-ss also)
<montjoie> but ablkcipher is deprecated
<montjoie> I try to create a minimal version (only aes) for begin mainlining
<montjoie> MoeIcenowy: sun8i-ce
<MoeIcenowy> montjoie: updating sun4i-ss ?
<montjoie> ouch, converting ablkcipher to skcipher was not easy
<montjoie> so the last one
<montjoie> 4.11.0-rc8-next-20170428
<montjoie> linux-next
<qschulz> montjoie: hat is your kernel?
<montjoie> but cannot confirm until tonight
<montjoie> so probably crashed
<montjoie> qschulz: i have modprobed the module, then 5min after lost contact
<montjoie> qschulz: the touchscreen is disabled
<qschulz> montjoie: what do you mean by not stable? you see the same messages? what kind of errors? what is your kernel? the defconfig? the bootlog?
<qschulz> montjoie: do you have TOUCHSCREEN_SUN4I disabled in your kernel?
<montjoie> and didnt start the screenserial:(
<montjoie> it seems not stable, the board crash without module removed
<montjoie> I WANT sensor
<montjoie> yes just after see it, I try manual load:)
<montjoie> it seems that crash is enevitable, lost contact with it
<montjoie> but modprobed sun4i_gpadc_iio at hand (no autoload)
<montjoie> I didnt add anything spetial (for hwmon/adc/iio)
<qschulz> montjoie: I don't see any iio_hwmon entry in the device tree for the cubiboard2. Am I Missing something?
<montjoie> on cubieboard2
<montjoie> the name is iio_hwmon-isa-0000
<montjoie> just typing sensors