| 08:04 | topi`_> | Ke: I think a x4 slot should take x16 cards just fine, but an adapter is probably needed |
| 08:06 | jnettlet[m]> | Ke: the big problem is the header that sits behind the PCIe slot. Most likely we wil change that orientation and provide an open backed pcie header for another revision. |
| 08:20 | jnettlet[m]> | topi`_: the other option is to cut the 16x header on the card. I do not recommend this at all, however I have seen it done for GPUs |
| 08:26 | topi`_> | doesn't sound a good option. However, for pure hack value, it would be nice to see if a Radeon would work on the macchiatobin :) |
| 08:27 | topi`_> | way back in 2001, I was working for a company that was producing powerpc 7400 based boards and they needed a graphics board (that could accelerate MPEG video playback) |
| 08:28 | topi`_> | so I tried to grab a regular ATI card at that era, and make it work in a PCI slot, but no avail. The reason was that the card had a video BIOS block that needed execution before anything appeared on screen and the Xorg, no, XFree86, could not do the init either |
| 08:28 | topi`_> | without the bios... |
| 08:29 | topi`_> | so all the commercial video cards were limited to x86 only computers. Disappointing, that was... |
| 08:29 | jnettlet[m]> | topi`_: I haven't tested it yet, but it is on my list. You need to run the tianocore uefi firmware to boot most graphics card. |
| 08:30 | topi`_> | yes, but we did not have that kind of software back in 2001 ;) |
| 08:30 | jnettlet[m]> | no |
| 08:30 | jnettlet[m]> | but marvell has tested some GPUs on the board. |
| 08:30 | topi`_> | AFAIK, UEFI was actually designed to be platform-agnostic |
| 08:30 | topi`_> | so it does not actually rely on an underlying x86 |
| 08:32 | jnettlet[m]> | it does not no |
| 09:16 | topi`_> | jnettlet[m]: have you already got any preview boards based on the i.MX8? I'm especially interested in the new AES instructions in armv8 architecture |
| 09:17 | topi`_> | which would be a perfect fit for our use case since we use encryption heavily and in some cases, it becomes a bottleneck on the i.mx6 |
| 09:17 | jnettlet[m]> | topi`_: not until later this year. Will keep you updated. |
| 09:18 | jnettlet[m]> | topi`_: are you using the NEON accelerated crypto for iMX6 or the crypto hardware? |
| 09:18 | topi`_> | do you know anything about the new AES instructions? afaik there are a bunch of instructions that you use in a sequence to do one AES round... |
| 09:18 | topi`_> | do we get NEON accelerated aes on libopenssl? |
| 09:18 | topi`_> | I guess it depends on distro, but say, debian |
| 09:19 | jnettlet[m]> | if you have libopenssl configured to use /dev/crypto then yes. |
| 09:19 | topi`_> | I would imagine NEON does not do wonders for AES... |
| 09:19 | topi`_> | oh! How do you do that? |
| 09:19 | jnettlet[m]> | yes you need to recompile openssl on debian for that. |
| 09:19 | topi`_> | I thought /dev/crypto is an interface to use the SoC internal encryption engine |
| 09:20 | jnettlet[m]> | https://www.linaro.org/blog/core-dump/accelerated-aes-for-the-arm64-linux-kernel/ |
| 09:21 | jnettlet[m]> | /dev/crypto is an interface to use the kernel crypto |
| 09:21 | jnettlet[m]> | the neon crypto is exported the same as the hardware crypto interfaces |
| 09:25 | Ke> | I once took a look into the source code, it was terribly abstract |
| 09:25 | Ke> | which is probably nice, if you are the maintainer, but initial investment is not trivial |
| 09:26 | jnettlet[m]> | topi`_: this is not production ready yet. But looks very promising. https://www.wireguard.io/ |
| 09:26 | jnettlet[m]> | I have been playing around with it on our clearfog platforms. |
| 09:39 | topi`_> | wtf, wireguard lives inside linux kernel?? |
| 09:40 | topi`_> | Linus is not going to be happy about that... |
| 09:40 | jnettlet[m]> | ipsec already has this model. |
| 09:40 | topi`_> | how are you supposed to hardware accelerate "exotic" ciphers like Chacha and others? |
| 09:41 | jnettlet[m]> | that is the fastest way to do encryption, so buffers don't need to be mapped in and out of kernel space |
| 09:43 | topi`_> | if buffers are large enough, that should not slow down much |
| 09:47 | jnettlet[m]> | but network buffers tend to be small. |
| 10:39 | topi`_> | I can't find any AES code on github or anywhere else that would use the new pmull.p64 and pmull2.p64 instructions of the aarch64 |
| 10:39 | topi`_> | the 8040 seems to have AES support enabled, so I could test on that platform |
| 10:42 | topi`_> | oh, actually this looks like it is using the aarch64 Crypto Ext: |
| 10:42 | topi`_> | https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/tree/arch/arm64/crypto/aes-ce-cipher.c?h=crypto-arm-v4.11 |
| 10:52 | topi`_> | oh, that patch was queued for 4.11, so definitely not in the 4.4-marvell tree |
| 11:07 | topi`_> | I'm running pthreaded stuff on my old and trusty quad core i.mx6 SoM, and /sys/class/thermal/temp shows 93 degrees... is it too hot? maybe I need a fan for the heatsink? |
| 11:07 | topi`_> | this room is too hot... |
| 11:17 | jnettlet[m]> | 93 if fine. although I am surprised it has gotten that hot. What kernel are you running? |
| 11:17 | jnettlet[m]> | if upstream, then it is possible the cpu-frequency scaling isn't throttling the speed. The iMX6 can run really hot. It will thermal shutdown if it gets too hot. |