<KotCzarny>
montjoie: fixing allwinner bugs and holes is like adventure game
<montjoie>
KotCzarny: I am just surprised it works, only H6 has it working until now
<KotCzarny>
montjoie: congrats! :)
<montjoie>
wow, the TRNG seems working on R40
2020-03-06
<montjoie>
wens: I will do a try later in the lab
2020-03-04
<montjoie>
but yes I know nobody use BE, A33 crypto was broken in BE and nobody never see it
<montjoie>
I want my drivers to be good at their maximum
<montjoie>
so in fact my BE kernel was LE...
<montjoie>
pffff I feared to be mad, disabling MACH_SUN7I made all my BigEndian kernel working.... just because MACH_SUN7I is the only one which select ARCH_SUPPORTS_BIG_ENDIAN...
2020-03-01
<montjoie>
for linux-meson I can poke some people to update it:) he is just 5m far on my right
<montjoie>
rockchip chart is worse than outdated, it is fakenews (at least for crypto)
<montjoie>
I fear CE detect the endianness only for hash (why ?) and badly read some value
<montjoie>
the ErrorReg report algo not supported AND length error
<montjoie>
on A33 hash was swapped for example, but on H6 it is not the problem
<montjoie>
for hashs
<montjoie>
but the hash result is not swapped
<montjoie>
wens: the ciphers are working well on H6/BE
<wens>
montjoie: maybe it's not byte swapped (or is) ?
<montjoie>
the same code work fine on A64/H3
<montjoie>
strange sun8i-ce hashs are broken on H6 in BE
2020-02-28
<montjoie>
in fact seems limited to a83t
<montjoie>
raah BE kernel fails on next on my sunxi boards
<montjoie>
keesj: you can download the final config from kernelci and hack it
2020-02-27
<montjoie>
I have a mainline boot on rpi4 on front of me, error festival
<montjoie>
lol
<montjoie>
JuniorJPDJ: I have worked on adding it on CI, just trying to boot it via network was a pain. but there are many other reason. rpi is perhaps the only one sbc where I saw a "top 5 or 10 of hardware design errors"
<JuniorJPDJ>
montjoie: why you say so?
<montjoie>
too expensive for such a s...
2020-02-26
<montjoie>
mass storage successfuly tested on it (read test)
<keesj>
montjoie: thanks a lot for this! I will try building mainline then
<montjoie>
keesj: mainline-master-v5.6-rc3-42-gc5f86891185c-arm-multi_v7_defconfig-gcc-8 booted fine today
<montjoie>
I just need to rebuild with massstorage to be sure USB works
<montjoie>
keesj: i have added an usb stick in our a10 lime, and it is detected by lsusb
<montjoie>
at least a crypto node!
2020-02-25
<wens>
montjoie: yell over in #armlinux ? :p
<montjoie>
wow, next is broken for all arm devices
2020-02-24
<Mangy_Dog>
oh certainly not in montjoie case
<montjoie>
willmore: a bit
<willmore>
I think we've oversolved montjoie's problem.
<willmore>
karlp, if he so decides to get the USB<>serial army, montjoie is about to be swimming in all the hardware he would need to program the bluepills.
<grey-bit>
montjoie: thanks. Do you think that 3.5Mbps on H3 is roughly about what should be expected from this hardware or may be I am doing something wrong here? I can't imagine what Allwinner guys would plan to do with some minuscule throughput......
<montjoie>
ppf on H6 ciphers length are now in bytes, but hash length are in bits...
<montjoie>
pfff H6 changes something about hash length...
<montjoie>
the hash support is nearly done, I will do a github branche
<montjoie>
grey-bit I expect better performance, but on H3 the sun8i-ce is less performant
<montjoie>
grey-bit the bug with rmmod is fixed and should land in stable
<grey-bit>
montjoie: I am not looking for acceleration and is ok with some slowdown, but 20x is a little bit harsh... If that's what CE can really do, then it's truly useless.
<grey-bit>
montjoie: there is also a bug during "rmmod sun8i-ce" getting non-fatal null dereference each and every time.
<grey-bit>
montjoie: is it reasonable that CE would limit to 3.5Mbps?
<grey-bit>
montjoie: I made some tests on kernel 5.5 on NanoPi R1 (H3). With sun8i-ce driver, on cbc(aes) with 256 bit keys, I am getting at most about 3.5Mbps with bandwidth controlled iperf3. If I let iperf3 to try and maximize the bandwidth, H3 completely stalls and I have to power cycle it.
2020-02-10
<montjoie>
kedder: yes
<tuxd3v>
montjoie, thanks
<willmore>
montjoie, gotcha. *thumbsup*
<montjoie>
tuxd3v: yes I bring back support for hash (shaxxx)
<montjoie>
willmore: yes PM is something I added and forgot that I have added it
<willmore>
montjoie, Does your driver support PM? I.e. turning power off when it's unused, etc?
<tuxd3v>
montjoie, hello , sun8i-ce-hash is crypto related?
<montjoie>
anyway, sun8i-ce-hash is now working
<montjoie>
willmore: yes
<willmore>
PM, montjoie? Power Management?
<montjoie>
5 days of debug of hash on sun8i-ce, I was mad, nothing worked and the solution was PM, I forgot that PM was enabled and everything was reseted when I sent request...
2020-02-07
<montjoie>
the pxe need to be managed via a serial console
<montjoie>
(pxe)
<montjoie>
can it boot via network ?
<montjoie>
I know that some will be hard to find like one on sparc niagara
<montjoie>
KotCzarny: I need to find one
<montjoie>
yes I try to collect all crypto hw
<montjoie>
ah ah ah ah ah ah ah ah each crypto driver I test is broken at least in next and/or mainline, rockchip, omap, virtio, caam ....
<montjoie>
I want offloaded acceleration
<KotCzarny>
montjoie: isnt it already in h5?
<montjoie>
my dream, H7 came with a sun8i-ce with four real parallel stream of AES(gcm/xts), bonus point for real acceleration (not just offload)
<montjoie>
2007 exactly, so sun8i-ce could have it
<montjoie>
GCM is 10years old
<MoeIcenowy>
montjoie: GCM is too new?
<montjoie>
willmore: grey-bit want offload and not acceleration, but I still dont understand why the CE does not have GCM (and have some other useless stuff)
<willmore>
montjoie, do the ARMv8 AES instructions help GCM? I would think so.
2020-02-06
<montjoie>
and sha256 fail test due to a bug in the cryptoAPI/selftest...
<montjoie>
doing ipsec for more testing is on my todolist
<montjoie>
perhaps it is possible to do some GCM(ecb)
<montjoie>
grey-bit: no GCM...
<grey-bit>
montjoie: does Allwinner have any CPU that offloads AES-GCM? All the hashing stuff would be irrelevant..
<grey-bit>
montjoie: do you have some git repo where I can grab it and test?
2020-02-04
<montjoie>
but let's try a simple version which fallback on all non modulo 64 size andd see what happens
<montjoie>
any other size will have lot of cpu wasted for handling the remaining buffer (and incresed complexity so bugs...)
<montjoie>
so basicly you will have shaxxx accelerated only if size % 64
<montjoie>
grey-bit: the night made me remember, due to crypto API contrainst, the useability is very low, cryptoAPI need that you always have the intermediate hash between update()
<grey-bit>
Thanks montjoie, that would be helpful
2020-02-03
<montjoie>
grey-bit: let me dig in my archive, I will try to bring them back tomorow
<grey-bit>
montjoie: I am looking to offload in the kernel for deploying ipsec - having Cisco esp-sha256-hmac on the other side. I don't mind if the throughput is slightly lower as long as I get some of the cores back for my other stuff...
<montjoie>
grey-bit you uneed offload for kernel or userspace ?
<montjoie>
but I have still the code so i can provide it
<montjoie>
grey-bit I have "abandonned" sha offload due to not being interesting (slow and few usage), what usage need their offload ?
<grey-bit>
montjoie: I am looking for SHAXXX offloads. I would be glad to test them and report the status. Shouldn't they show in /proc/crypto once sun8i-ce is loaded on 5.5 kernel?
2020-02-02
<montjoie>
I will uddate the status, Ok means they basicly work but need extended test
<montjoie>
CTS and CTS will be added later
<montjoie>
grey-bit: what cipher exactly do you want?
2020-02-01
<montjoie>
I have retried to made my pine64 working, but uboot is looping https://pastebin.com/6TYzjR3B does I need to delcare it dead ? (tryed recent uboot and still the same)
<montjoie>
but I will send it within few week
<montjoie>
tuxd3v: TRNG is WIP
2020-01-30
<tuxd3v>
montjoie, thanks it seems at least with rc7 it was..
<montjoie>
so probably the hub dont really shutdown this particular port
<montjoie>
using another port fixed the problem
<montjoie>
no problem
<montjoie>
yes
<montjoie>
and I am sure it works since I power switch the opi3 with it
<montjoie>
I am using an USB hub as power switch
<montjoie>
by port I mean the USB hub port is disabled
<montjoie>
since unplugin cable bring it down I am sure it came from the usb cable
<montjoie>
it is 1 hour now...
<montjoie>
no it gets powered for long
<montjoie>
and powering down the port works on this hub, since my opi3 is managed on it
<montjoie>
I checked the port with some USB dongle
<montjoie>
so the power came from it
<montjoie>
but removing the power cable bring it down
<montjoie>
nothing more
<montjoie>
network
<montjoie>
removing the serial does not change the behavour
<montjoie>
from where did it get power
<montjoie>
my bpim3 made me crazy, I have shutdown the port of the USB hub (via uhubctl) where it is connected and it is still powered. any other USB dongle dont work on this port when down
2020-01-17
<willmore>
montjoie, yay!
<montjoie>
and same for sun8i-ce \o/
<montjoie>
A83T PRNG back into business (it need to have the KEY register set...)
2020-01-16
<montjoie>
2020-01-15
<willmore>
montjoie, does tllim have the ability to get questions like that relayed?
<willmore>
montjoie, "kr kr kr" is that laughing? ;)
<montjoie>
I never got any answer from AW
<montjoie>
I have lost all hope in sun8i-ce PRNG, even after "fixing" the new-seed mechanism (using an offset for taking it in middle of output), rngtest continue to say failure
<montjoie>
a typo copy/paster on all datasheets kr kr kr
<montjoie>
willmore: note that 15bits could be a typo from 175...
<willmore>
montjoie, then you'd have an even worse RNG output. :)
<montjoie>
anyway if the prng is bad, I could xor it with the bad trng and who knows...
<willmore>
montjoie, your English is vastly better than my French, so, please don't feel any criticism!
<montjoie>
furthermore good in french
<KotCzarny>
montjoie, no shame, it was really good :)
<montjoie>
please I tried to shadow my typo
<willmore>
montjoie, then the question is did they cut and paste the silicon as well.
<montjoie>
175bit was the size for sun4i-ss
<montjoie>
since the datasheet speak about 15bit...
<willmore>
montjoie, yes.
<montjoie>
anyway I fear the copy/paste poblem on this part of doc
<montjoie>
for sun8i-SS giving a length not multiple of 5*4 produce no output, sun8i-ce seems to doesnt care
<montjoie>
32bites
<montjoie>
so I use the length given by linux for the dma mapping in case of
<montjoie>
anyway linux always give a seed of 32bytes
<willmore>
How montjoie made any sense out of that datasheet is beyond me. Well done.
<willmore>
montjoie, okay, I see some of the repitition. There is not context to the PRNG, is there? Its only state is what it receives in the request? (so the seed, and ask are all that should determine the output?)
<montjoie>
you can see that the initial seed (line 72 ) is the same than the new (line 87)
<montjoie>
I prend the initial SEED then the output and then the new SEED
<montjoie>
dlen is the length asked and todo is the size I ask (dlen + seedsize + xx)
<montjoie>
it appears twice since linux does it, and them it is my test which set a new seed
<montjoie>
sun8i_ce_prng_seed PRNG slen=32 is when I got a new seed
<montjoie>
yes I test with the seed "SEED" length of 32 64 128 256 511
<willmore>
montjoie, did you test that the seed works? By which I mean, did you repeat the same submission with the same seed to see that you got the same output? Then one-by-one, alter the seed bytes to ensure that they all effect the output.
<montjoie>
so if, in a few time, I found a cycle of only 128bytes (which is very few), other probably can be found
<montjoie>
but I found an example where the same seed appears after 128bytes
<montjoie>
my CE tests grab 12bytes
<montjoie>
willmore: yes I give a seed, but unlike sun4i-ss, nothing give a new seed so I grab the new seed from extra output
<willmore>
montjoie, how does it work? You feed the PRNG a seed, it feeds back data plus the new seed?
<montjoie>
something is weird
<montjoie>
and now I know why the PRNG is bad... it is cyclic, so I get the seed from the output and the new seed is ... the same than the one used
<willmore>
montjoie, that does not look very random.
<willmore>
montjoie, seems different can be good, then. (H6)
<montjoie>
wens: I have just restarted a job for it, lots of repetitions, seems to repeat some pattern
<montjoie>
wens: it seems that a83t TRNG burp zeros, so removing zero could produce something usable BUT how to make difference between good zeros and bad
<wens>
montjoie: maybe trng on older chips is just the raw output, and needs some whitening?
2020-01-14
<tuxd3v>
montjoie, I never understood why Allwinner and the Others difer so much between hardware releses..
<montjoie>
while with the same code, it fail on H3
<montjoie>
but a quick rngtest is full of success
<montjoie>
tuxd3v: I need to polish the patch and wil put it on github
<tuxd3v>
montjoie, you confirm TRNG is H6 working?
<montjoie>
confirmed, the TRNG on h6 is different than the others (differant aka it works)
2020-01-13
<montjoie>
I will push my code tomorow on github if people want to test
<montjoie>
I need to finish update on the crypto matrix
<montjoie>
a10/a20 have prng support since a long time (sun4i-ss)
<montjoie>
but H6 has different algo numbers for prng/trng, so perhaps a different than other sun8i-ce (vs h3 h5 r40 a64)
<montjoie>
my test are currently on h3 and h6
<montjoie>
willmore: the prng work on a83t (but trng burp 0 randomly)
<willmore>
montjoie, this is still on a bizarre chip, right?
<montjoie>
anyway, time to rngtest on lot of output
<montjoie>
if the TRNG really work, PRNG is useless
<montjoie>
at least the TRNG on H6 seems random for the moment
<montjoie>
but I have another change, the CTR entry got 4bytes random before, now only zeros
<montjoie>
willmore: some days ago it "worked" normaly, but I dont find any change on my side
<willmore>
montjoie, no chance the output has a 20 byte header or that a pointer is misaligned? (searching for a possiblity)
<montjoie>
note that a PRNG which works randomly is ...
<montjoie>
this PRNG made me mad, now the first 20bytes are always the same...then random
2020-01-10
<montjoie>
tuxd3v: no speeding crypto sun8i-ce
<tuxd3v>
montjoie, you mean fbturbo?
<montjoie>
ah ah ah sun8i-ce turbo patch near ready
<ElBarto>
montjoie: I don't understand some stuff in the bootlog from kernelci
<montjoie>
I think that if linux dont know the regulator it cannot touch it, but the AXP driver could probably do something like "disable all then ..."