2014-10-17

<patap> Montjoie: is your driver using dma?
<patap> Montjoie: nice!
<Montjoie> I trun the hash bench, because It could perhaps be less than last test, due to solving some issue reported
<arokux> Montjoie: cool
<Montjoie> arokux, the AES bench is finish, up to 50% gain

2014-10-16

<arokux> Montjoie: I see
<Montjoie> accelerated is better than non accelerated but I need to retry a bench against the lastest neon driver
<arokux> Montjoie: I see :), have you maybe updated the graphs accelerated vs non-accelerated encryption?
<Montjoie> I just need to re-test it against 3.18rc
<Montjoie> I need to send my last patch, but each time my finger go to enter for send it, my children send an interupt
<arokux> Montjoie: have you finished your work on crypto interface?
<Montjoie> hey arokux
<arokux> hey Montjoie
<Montjoie> too late, is gone

2014-10-02

<montjoie[home]> yeah updated my git sources, now time to go back to work

2014-09-08

<arokux> Montjoie: oh, I meant not that detailed info :)
<Montjoie> more entropy of choice, but for world conquest I wait for 128, all devs becoming mad (/lib /lib32 /lib64 /lib128)
<Montjoie> depends of the size of the word 32 or 64 ?

2014-09-01

<montjoie[home]> thanks Turl for the 8250_DW, now I see all boot

2014-08-31

<montjoie[home]> thanks Turl I will try to enable it
<Turl> montjoie[home]: I think you don't have 8250_DW enabled
<montjoie[home]> no
<diego71> montjoie[home]: can you ping it, or ssh to it?
<montjoie[home]> I suspect also a problem in userspace, but I want to see it
<diego71> montjoie[home]: I suspect a problem in userspace
<diego71> montjoie[home]: the kernel configuration looks fine
<Turl> montjoie[home]: and your .config
<Turl> montjoie[home]: hmm do you have the uart driver enabled?
<montjoie[home]> last message is 1.095703] bootconsole [earlycon0] disabled
<Turl> montjoie[home]: how far do you get?
<Turl> montjoie[home]: that config is ok
<diego71> montjoie[home]: it shoulds work
<montjoie[home]> I got the beginning of boot but not more
<montjoie[home]> hello I use a cubieboard2 with a mainline kernel, could someone confirm that console=ttyS0,115200 is a good way to config output via a ttl cable ?

2014-08-11

<sehraf> montjoie[home]: that sounds promising :)
<montjoie[home]> I just need to answer mripard reviews and to be sure to not have forgotten anything
<montjoie[home]> sehraf: I expect to send the patch this week
<sehraf> hey montjoie[home] .. how is the security system going?
<montjoie[home]> need to bench nbd for IO without SATA
<Turl> montjoie: there's usb3, but yeah
<montjoie> What is the interest of such power without storage...

2014-08-04

<montjoie> thanks wens
<montjoie> with it I can enable KVM
<montjoie> no, and it was that the problem
<montjoie> already read, he say that 3.16-rc6 support kvm, I dont see such thing
<nedko> montjoie: you may find this useful: http://blog.flexvm.es/?p=91
<montjoie> I have I have red that 3.16 have such support but I see nothing in menuconfig
<montjoie> Does someone here use kvm on some A20 SoC ?

2014-08-01

<montjoie[home]> stress testing Security System... making 1024 update() of 1 byte

2014-07-30

<montjoie[home]> yeah ss driver near ready for v5

2014-07-22

<sehraf> montjoie[home]: now everything is working :)
<montjoie[home]> you need both patch
<montjoie[home]> I will work on a better solution this week with crypto_queue
<montjoie[home]> quik and dirty but it would work
<montjoie[home]> sehraf: try http://pastebin.com/eDDVWRv9
<sehraf> montjoie[home]: i get the same result with sha1, too ^^
<montjoie[home]> sehraf: I understand, I have solved the probleme only for hash, but for some mistery, benchmarking md5 "test" ciphers also
<sehraf> Montjoie: this is everything i (additionally) get http://pastebin.com/ZPgDKpSB
<Montjoie> sehraf, yes
<sehraf> Montjoie: just for the record ... i apply your 3 patches from the mailing list and than you fix, right?
<Montjoie> Security System
<Montjoie> argggg
<sehraf> Montjoie: i've removed sunxi-ss, loaded sunxi-ss and then loaded cryptodev: issue still exists ..
<Montjoie> just for me sure, could you rmmod and re-modprobe sunxi-ss ?
<Montjoie> so a 3.16-rc4
<Montjoie> mripard sunxi-next
<sehraf> Montjoie: what kernel source are you using?
<Montjoie> for openssl speed md5 , gnutls not tested
<Montjoie> sehraf, strange, my patch solved issue for myself
<sehraf> Montjoie: same locking issue ( http://pastebin.com/8atze7bE )
<sehraf> Montjoie: i'll give it a try and report back
<Montjoie> But I am afraid that I would certainly need to use crypto_queue
<Montjoie> sehraf, try http://pastebin.com/MF1ektq2
<Montjoie> and it seems openssl try to do it multiple time but for some reason it do not update after init
<Montjoie> for openssl, it is a mutex problem, the SS can handle only one request at a time
<Montjoie> since the test is in-kernel, it was faster than my test in user space
<Montjoie> but with 3.16 a test for sha1 was added and it fail
<Montjoie> and until 3.16 it worked all the time
<Montjoie> the SS have a register which give the numer of word you can write, for md5/sha1 I wasnt care about it
<Montjoie> no
<sehraf> Montjoie: :) when you have a new version let me know and i'll test it
<Montjoie> sehraf, I am able to reproduce your problem
<Montjoie> whooooh with 3.16 some crypto test fail with sunxi-ss, It work too fast...:)

2014-07-21

<Montjoie> sehraf, Which gnutls do you use ? 3.x ?

2014-07-20

<sehraf> montjoie[home]: modprobe: ERROR: could not insert 'tcrypt': Resource temporarily unavailable ... not sure if this is usefull ...
<sehraf> montjoie[home]: i found the config to build tcrypt .. i'll rebuild the kernel and let you know if i can load it
<sehraf> montjoie[home]: i don't have that module
<montjoie[home]> sehraf: does modprobe tcrypt works ?
<sehraf> montjoie[home]: here you go http://pastebin.com/WDg697Ve
<montjoie[home]> sehraf: could you tell me more about your config kernel/cryptodev/openssl/etc..version
<montjoie[home]> sehraf: strange
<sehraf> montjoie[home], or anybody else: i still have the dead lock issue with the security system driver (v4) ... any ideas how to debug / fix this? http://pastebin.com/RC805xAg

2014-07-17

<mripard_> montjoie[home]: I don't know ...
<montjoie[home]> I read that A80 will not have datasheet, does it true?

2014-07-10

<montjoie[home]> no
<Zboonet> montjoie[home], does your nick have something to see with "Les Contamines Montjoie" ?
<montjoie[home]> if you need help for some sysadmin do not hesitate, I perhaps can help
<sehraf> montjoie[home]: this is what i get when using cryptodev + openssl: http://0bin.net/paste/1r1FhN5zwWuwWsAE#IfNDi0u9FYN9uG-bsNRftjTae3JQ1im+Pn8ZqWvNjmi

2014-07-09

<Montjoie> yes
<Montjoie> yes
<sehraf> montjoie[home]: have you ever tried to use your ss driver with cryptodev?

2014-07-08

<montjoie[home]> the driver is for A20
<montjoie[home]> yes
<montjoie[home]> cubieboard2
<montjoie[home]> minor speakin functionnality
<montjoie[home]> the v3 is stable, only minor changes comes with v4
<montjoie[home]> v4 will comme soon (this week)
<montjoie[home]> yes
<sehraf> montjoie[home]: v3 is the latest version, isn't it?
<montjoie[home]> sehraf: the driver with speed is already public
<sehraf> plaes: the first "draft" was slow but montjoie could speed things up :)
<mripard> montjoie[home]: is working on one

2014-06-12

<Montjoie> Does some people are trying the eudyptula challenge here ?
<Montjoie> thanks mripard
<mripard> Montjoie: I'm using maz's repo: https://git.kernel.org/cgit/linux/kernel/git/maz/u-boot.git/?h=wip/psci-v4
<Montjoie> Could someone point me where is hans u-boot repo for having smp on mainline ? I cannot find it on wiki

2014-06-10

<Turl> Montjoie: I am cleaning up my dma code, I will give you a branch in a bit
<Turl> Montjoie: :)
<Montjoie> Now I prepare myself to get burned by crypto people
<Turl> Montjoie: hey :)
<Montjoie> wens, if you want to test I have sent the patch v3
<Montjoie> TheSeven, thanks wens for the report, I will send an updated patch soon
<Montjoie> I sense shame
<Montjoie> oups I reproduce it
<Montjoie> with a mix of modules/static
<Montjoie> strange I cannot reproduce for the moment
<Montjoie> could you paste the errors ?
<Montjoie> old driver or new ?
<wens> Montjoie: I'm getting multiple function definition errors when I build SS with all options enabled

2014-06-09

<Turl> Montjoie: as for DMA, ping me tomorrow, I will try to get you a branch you can play with
<Turl> Montjoie: do you still have issues with prng? I was just reading some old emails
<Turl> Montjoie: hi

2014-06-07

<montjoie[home]> Does someone has tested sunxi-ss on other SoC than A20 ?

2014-06-03

<Montjoie> answering just 12hours after:)
<Montjoie> Turl, yes interested on DMA

2014-06-02

<Turl> Montjoie: you were interested on DMA on mainline, weren't you?
<Montjoie> I will propose the actual state to linux-crypto, if they do not like it, I will make a monolithic one
<hramrach> Montjoie: if you really want choice make it possible to unregister the algo without actually loading/unloading anything
<Montjoie> I want to give choice, but yes I have pain for trying that
<Montjoie> "not doing it", you think trying to create a module for each algo is "too much work for nothing" ?
<Montjoie> does I need to stay like that or can I use a platfrom_driver
<Montjoie> for the moment each algo are in a simple module
<Montjoie> for each crypto algo I want a platform_driver who "attach" to the core module
<Montjoie> I explain more my problem: for the seucrity system I made a core platform_driver who own the device
<mripard> Montjoie: you can't
<Montjoie> it seems to not work
<Montjoie> I want to load 2 plaftorm_driver with the same .compatible = "" name
<Montjoie> you speak about which name ? the vamue of .compatible ="" ?
<rz2k> Montjoie: check what type is of_match_table, if it is then put to a linked list or something - you wont be able to make two with the same name. I bet guys who designed OF already thought it out.
<Montjoie> If I create two driver with the same exact of_match_table, only one will be loaded right ?

2014-05-30

<Montjoie> I will send a v2 version of my patch, if I could update the "other board" status
<Montjoie> yes
<Montjoie> Could you test with the driver ?
<Turl> Montjoie: it works just fine on A10, I have used MD5 and PRNG
<Turl> mnemoc: I didn't, Montjoie did :p
<Montjoie> for A10, no datasheet but I saw a diagram saying it was in
<Montjoie> arete74, thanks if you could try
<arete74> montjoie: i can try on A10 cubie1
<Montjoie> does someone have use the security system driver on SoC other than A20 ?

2014-05-28

<Montjoie> seems false:)
<Montjoie> I am trying sys-apps/watchdog from gentoo, I believed that the kernel module was sufficient
<Turl> Montjoie: eg busybox watchdog
<Turl> Montjoie: run any watchdog daemon
<Montjoie> What does I need to do, to enable the watchdog on cubieboard 2 ? I "volontary" crash it, but watchdog doesnt seems to reset the board

2014-05-25

<montjoie_[home]> I believed to CC it, ok for next time
<wens> montjoie_[home]: could you CC linux-sunxi for your next series? I think some of us don't watch LAKML that closely

2014-05-23

<montjoie_[home]> yeah, just finished splitting my driver

2014-05-22

<mripard> Montjoie: usually, it's just help
<Montjoie> checkpatch seems to ignore my ---help---
<Montjoie> hello for Kconfig does "---help---" is still acceptable or "help" is better ?

2014-05-17

<montjoie[home]> ioread is for io port, and writel for MMIO
<montjoie[home]> yes they both work (even memset/memcpy work) but it is better to use writel/readl
<montjoie[home]> use writel/readl only

2014-05-14

<montjoie[home]> thanks mripard could you test it on your non a20 boards ?
<mripard> montjoie[home]: your patch looks very good to me, I guess you can just submit it for real this time

2014-05-13

<ccaione> montjoie[home]: can you paste the links here? it is interesting
<montjoie[home]> I forgot to add links gived by mripard about that in the code
<montjoie[home]> No since all write/read goes to a single register
<montjoie[home]> I explain it a bit in the code
<montjoie[home]> no memory barriers with the latter
<montjoie[home]> writel vs writel_relaxed
<Turl> montjoie[home]: did you find the bottleneck? the numbers look good :)
<Turl> montjoie[home]: great :)
<montjoie[home]> alea jacta est, patch for Security System sent:)

2014-05-12

<Montjoie> lacking context about something that seems SELinux is good joke:)

2014-05-06

<TuxboxGuru> Montjoie: a chapter on readl/writel and friends
<Montjoie> no
<codekipper> Montjoie, do you know if there is a link to the project?
<Montjoie> codekipper, Turl will work on A20/DMA thought a GsoC
<TuxboxGuru> Montjoie: maybe marking the variables as Volatile will negate the cache (it should)
<Montjoie> I need to launch my crypt tester
<Montjoie> because by using memcpy, I have PERFORMANCE with SS
<Montjoie> thanks TuxboxGuru
<TuxboxGuru> Montjoie: keep in Mind writel/readl are not cached... memcpy might be
<Montjoie> it seems yes, but I fear to not handle all concequences
<Montjoie> does it is safe to replace writel/readl by memcpy ?
<Montjoie> Wizzup, I am writing the header of the mail:) I will sent it today I think
<Montjoie> oh at least 3DES is far better with SecuritySystem

2014-05-05

<montjoie[home]> time to work on Documentation and dt binding
<Wizzup> Montjoie: sure, so maybe start the timing *after* the write? :-)
<Montjoie> transferring the data is just a write
<Wizzup> Montjoie: can I find the code somewhere so I know what I am talking about?
<Montjoie> Wizzup, no DMA engine yet
<Montjoie> Wizzup, getting the data to SS ?
<Turl> Montjoie: try with more updates
<Montjoie> those values are gived by the tcrypt module
<Montjoie> test md5-sunxi-ss 21 ( 8192 byte blocks, 8192 bytes per update, 1 updates): 5013 cycles/operation, 0 cycles/byte
<Montjoie> test md5-generic 21 ( 8192 byte blocks, 8192 bytes per update, 1 updates): 2379 cycles/operation, 0 cycles/byte
<Montjoie> test md5-sunxi-ss 21 ( 8192 byte blocks, 8192 bytes per update, 1 updates): 4780 opers/sec, 39161856 bytes/sec
<Montjoie> test md5-generic 21 ( 8192 byte blocks, 8192 bytes per update, 1 updates): 10078 opers/sec, 82558976 bytes/sec
<Montjoie> example:
<Montjoie> I speak in CPU cycle
<Montjoie> md5 with SS is slow by a factor of 2 versus the generic implementation, I gonna be crazy
<Montjoie> when I said no major, I must said no difference
<Wizzup> Montjoie: That probably means the overhead is not in the SS
<Montjoie> PIO
<Turl> Montjoie: PIO or DMA?
<Montjoie> I have overclocked the SS clk from 150 to 300Mhz, no major performance changes:(
<ssvb> Montjoie: well, disabling is a bit of an overkill and not really necessary :) just relying on it would be a bad idea until we know how it works
<Montjoie> ssvb, all algorithm of SecuritySystem have their own sub-option, so if you dont want PRNG you could disable it
<ssvb> Montjoie: hmm, Richard_P has left already, so I can't ask him what kind of entropy improvement he expects from *P*RNG
<TuxboxGuru> Montjoie: http://www.wolfmud.org/journal/2013/2/6.html <-- There is an explanation on different RNG values and how to test for it
<huehner> Montjoie: if you need someone for testing stuff (a20/cubietruck) let me know
<TuxboxGuru> Montjoie: thanks.. I'll grab and see whats there for Crypto
<Montjoie> for the moment I test with sunxi-devel but my goal is real mainline
<huehner> Montjoie: for mainline you mean maybe merging to 3.16 (as 3.15 is now at -rc4 already), or meaning as sunxi-devel is now rebased to 3.15-rc1 ?
<Montjoie> but it is something I need to do
<Montjoie> no
<TuxboxGuru> Montjoie: do you have a usual GIT repo with your code changes in it ?
<Richard_P> Montjoie: If you need any assistance, please shout
<Montjoie> I got 634 without my driver:)
<Montjoie> cannot
<Montjoie> the driver load but I can tell if linux using it
<Montjoie> my work on the prng is minimal
<Montjoie> I just need to clean it a little before sending it to the mailinglist
<Montjoie> but if you can wait, I expect to release soon the driver for mainline (3.15)
<Montjoie> You can read the preliminary driver that I have sent for 3.4 kernel
<Richard_P> Montjoie: thanks... I can offer my services :D (programmer by day... err.. and by night) I just didnt want to start coding without knowing what is already working
<Montjoie> Richard_P, huehner I confirm on working on Security System of A20
<huehner> Richard_P: user working on that i think is Montjoie, maybe check irc history for his nick

2014-05-03

<montjoie[home]> with clk_set_parent
<montjoie[home]> from pll1 to axi
<montjoie[home]> for AHB_SS I try some reparenting but failed
<ssvb> montjoie[home]: now I just wonder why it does not allow you to change the clock frequency to something else (if I understood you correctly)
<ssvb> montjoie[home]: that's good
<montjoie[home]> so by 4 and it is confirmed by /sys/kernel/debug/clk/clk_summary
<montjoie[home]> oups divided by 0x03
<montjoie[home]> no divisor
<montjoie[home]> ssvb I got 0x81000003 so the clock is on and the source is pll6
<ssvb> montjoie[home]: it just looks like the clock setting/reporting interface in the kernel needs a bit of extra verification before it can be trusted
<montjoie[home]> ssvb ok
<ssvb> montjoie[home]: mmap /dev/mem and read the SS_CLK_REG hardware register value, then decode it according to the A20 manual
<montjoie[home]> ala a10-meminfo ?
<ssvb> montjoie[home]: can you read the SS clock register ala a10-meminfo way and verify which clock frequency is in fact used for real?
<montjoie[home]> with 3.4 I cannot even get the current clock rate, actually I work on mainline
<ssvb> montjoie[home]: do you have this with sunxi-3.4 or the mainline kernel?
<ssvb> montjoie[home]: this seems to be some odd software issue, because the hardware register should support different divisors
<montjoie[home]> ssvb I have try to overclock SS_CLK from 100 to 320 Mhz, only 160 is accepted by clk_set_rate()

2014-05-02

<montjoie[home]> ssvb good remarks, I will retry
<ssvb> montjoie[home]: that's why nudging the clock speeds up and down may be interesting
<ssvb> montjoie[home]: we just want to know what exactly is limiting the performance. Is it the ss clock speed? Is it the ahb clock speed? Is it just the time for cache flush/invalidate to maintain coherence?
<montjoie[home]> but by default, the driver does not have to overclock
<montjoie[home]> ssvb yes I have tried to overclock but failed
<ssvb> montjoie[home]: oh, thanks, I see
<montjoie[home]> ssvb page 228
<montjoie[home]> ssvb at the end of ss section oh the manual
<montjoie[home]> 160 for the clock bus
<ssvb> montjoie[home]: 200MHz?
<montjoie[home]> each AES request already have 3 code path different for optimizing
<montjoie[home]> maximum as said by the datasheet
<montjoie[home]> one clock is already at maximum
<montjoie[home]> I failed at that Turl
<montjoie[home]> I am near to have tested anything
<montjoie[home]> I am not, I dreamed x2:D
<montjoie[home]> one request at a time for security system:)
<montjoie[home]> but a small gain is possible
<montjoie[home]> for sha1/md5 I need to redo my bench
<montjoie[home]> I developping a benching kernel module for comparing with crypsetup, for the moment simlilar values
<montjoie[home]> with the 3,4 kernel, the DMA was usefull only for request > 4k
<montjoie[home]> hypothalamus as I said, for AES only when using 256bits key and maximum gain is 10%
<montjoie[home]> Wizzup yes
<hypothalamus> montjoie[home]: do you know if security system will speed up openssl?
<montjoie[home]> since Security System does not support AES XTS mode
<montjoie[home]> but for my initial target case (cryptsetup) security system is bad
<montjoie[home]> I expect better perf when DMA would be availlable
<montjoie[home]> yes compared with neon implementation
<montjoie[home]> in other AES (128 / 192) the gain is negative up to 50% loss
<montjoie[home]> you do not loose performance only with AES256 and in that case the gain is at maximum 10%
<montjoie[home]> Wizzup yes me:)
<Wizzup> montjoie[home]: someone got the security system to work?
<montjoie[home]> i am stunned by the bad performance of the a20 security system

2014-04-26

<montjoie[home]> wens and for A10 ?
<bertrik> montjoie[home]: as I understand, hardware modules (like USB controllers, DRAM controllers, etc.) in many ARM SoCs is similar, so you can try to re-use and adapt an existing driver for example
<montjoie[home]> wens so how to develop driver for a31 ?
<wens> montjoie[home]: there is no "user manual" for A31, only a brief
<montjoie[home]> hello where I can find the A31 user manual and other AXX user manual ? I need to compare security system datasheet

2014-04-23

<Montjoie> cubear, no, only a patch on the mailing list