Hi,
I was investigating Qualcomm Crypto Engine support on my sdm630
smartphone and found out that the already-present driver is
compatible. In meantime I found two issues:
1. The driver doesn't seem to have a maintainer? drivers/crypto/qce
doesn't seem to exist in the MAINTAINERS file..
2. The person who first submitted it likely faced an issue with memory
allocation. On downstream (taking sdm630 as example) Qualcomm decided
to allocate 0x20000@1de0000 for the device and 0x24000@1dc4000 for
BAM, which isn't something upstream driver agrees with (these memory
regions overlap and the driver straight up doesn't probe..).
I "fixed" it by giving (QCE register) - (DMA register) memory size to
the DMA (which doesn't seem to cause any issues) and changing all the
registers in the header file by 0x1A000 (just like it is downstream
[1]), but the former person "fixed" it by offsetting the QCE node in
qcom-ipq4019.dtsi by 0x1A000.
Which fix is more correct? I'd advocate for my one as the more
accurate, but I can adapt to what's already been invented.. Test
results ("cryptsetup benchmark") don't differ between these two
(though they are worse than without the QCE, which is most likely
related to unimplemented bus bandwidth scaling).
[1] https://github.com/sonyxperiadev/kernel/blob/aosp/LA.UM.7.1.r1/drivers/crypto/msm/qcryptohw_50.h
Konrad Dybcio
Hi Konrad,
On Fri, Oct 23, 2020 at 01:55:13PM +0200, Konrad Dybcio wrote:
> Hi,
>
> I was investigating Qualcomm Crypto Engine support on my sdm630
> smartphone and found out that the already-present driver is
> compatible. In meantime I found two issues:
>
> 1. The driver doesn't seem to have a maintainer? drivers/crypto/qce
> doesn't seem to exist in the MAINTAINERS file..
>
> 2. The person who first submitted it likely faced an issue with memory
> allocation. On downstream (taking sdm630 as example) Qualcomm decided
> to allocate 0x20000@1de0000 for the device and 0x24000@1dc4000 for
> BAM, which isn't something upstream driver agrees with (these memory
> regions overlap and the driver straight up doesn't probe..).
> I "fixed" it by giving (QCE register) - (DMA register) memory size to
> the DMA (which doesn't seem to cause any issues) and changing all the
> registers in the header file by 0x1A000 (just like it is downstream
> [1]), but the former person "fixed" it by offsetting the QCE node in
> qcom-ipq4019.dtsi by 0x1A000.
>
> Which fix is more correct? I'd advocate for my one as the more
> accurate, but I can adapt to what's already been invented.. Test
> results ("cryptsetup benchmark") don't differ between these two
> (though they are worse than without the QCE, which is most likely
> related to unimplemented bus bandwidth scaling).
>
>
> [1] https://github.com/sonyxperiadev/kernel/blob/aosp/LA.UM.7.1.r1/drivers/crypto/msm/qcryptohw_50.h
>
> Konrad Dybcio
Out of curiosity, what use cases do you have in mind for drivers/crypto/qce/ on
SDM630? I can't help you with that driver, but it may be worth mentioning that
that the SDM630 (and most other Snapdragon SoCs) also includes an Inline Crypto
Engine (ICE) as part of the eMMC host controller. The "Inline Crypto Engine" is
very different from the regular "Crypto Engine" which drivers/crypto/qce/ is
for. And in practice, ICE is what is used on Snapdragon-based Android devices
to accelerate the storage encryption; drivers/crypto/qce/ isn't used.
So if your goal is to run Android with an upstream kernel on SDM630, ICE support
would probably be more useful. On the other hand, dm-crypt doesn't currently
support inline encryption, so if your goal is just to run other Linux distros,
ICE wouldn't be as useful (since outside Android, dm-crypt is more commonly used
than fscrypt, which is what Android uses).
FWIW, I'm interested in adding support for the eMMC interface to ICE, but I
haven't had hardware with upstream support to use. (I was able to add upstream
support for the UFS interface to ICE, since there is a SDM845 development board
with upstream support, and upstream Linux now has a framework "blk-crypto" for
supporting inline encryption hardware.) I see there's been recent upstreaming
work on SDM630 by yourself and others. I haven't had much luck getting a Sony
Xperia 10 to boot with an upstream kernel, though -- and I've also tried some of
the branches at https://github.com/SoMainline/linux, including yours I think.
If you're able to give some tips to getting it working (probably off-list, since
it's a bit off-topic for linux-crypto) I'd appreciate it -- thanks!
- Eric
Hi Eric,
First of all, I am EXTREMELY sorry for my long overdue response..
I just wanted to bring up that piece of HW so as to offload crypto
tasks from the CPU, but it ended up being slower (which I suspect is
due to bw scaling not being implemented, but I might be wrong, maybe
A53+crypto is just superior..)
The goal is to have the phone run Mainline Linux *at least* at
functional parity with the BSP kernel. Both ICE and CE support are
welcome.
Thanks for your interest and the patches you sent. There is more
sdm630 (and not only, keep watching :D) work coming. I suppose you
managed to boot your Xperia by now, but if you had issues, you should
try out my v5.10-rc3 branch from the repo you linked with the supplied
ninges_defconfig. Then you append the DTB to Image.gz and create an
Android boot image (or put Image.gz+dtb into an existing one with
abootimg -u boot.img -k Image.gz+dtb) and the phone should boot.
Thanks once again for your interest and apologies for the time it took..
Konrad
Hi Konrad,
On Thu, Nov 12, 2020 at 09:26:30PM +0100, Konrad Dybcio wrote:
> Hi Eric,
>
> First of all, I am EXTREMELY sorry for my long overdue response..
>
> I just wanted to bring up that piece of HW so as to offload crypto
> tasks from the CPU, but it ended up being slower (which I suspect is
> due to bw scaling not being implemented, but I might be wrong, maybe
> A53+crypto is just superior..)
A while ago, I benchmarked the QCE on an older SoC, and it was much slower than
just using the ARMv8 crypto extensions. So I'm not surprised. I don't think
QCE is really used anymore. But almost everyone uses ICE.
> The goal is to have the phone run Mainline Linux *at least* at
> functional parity with the BSP kernel. Both ICE and CE support are
> welcome.
>
> Thanks for your interest and the patches you sent. There is more
> sdm630 (and not only, keep watching :D) work coming. I suppose you
> managed to boot your Xperia by now, but if you had issues, you should
> try out my v5.10-rc3 branch from the repo you linked with the supplied
> ninges_defconfig. Then you append the DTB to Image.gz and create an
> Android boot image (or put Image.gz+dtb into an existing one with
> abootimg -u boot.img -k Image.gz+dtb) and the phone should boot.
>
> Thanks once again for your interest and apologies for the time it took..
I'm already using your v5.10-rc3 branch, but ninges_defconfig isn't working for
me. (Though I couldn't find the firmware file "qcom/a530_zap.elf", so I had to
remove it from CONFIG_EXTRA_FIRMWARE.) Instead I'm using a kconfig based on
https://github.com/SoMainline/linux/blob/marijn/android/arch/arm64/configs/defconfig
which is working for me.
I haven't been able to get a full Android userspace to work, and currently I'm
instead just replacing the kernel in a TWRP image and booting into recovery.
It's enough to get adb shell access and chroot into a Debian chroot on the
userdata partition, which is enough to run android-xfstests to test the ICE
support. Earlier I tried AOSP using the instructions at
https://developer.sony.com/develop/open-devices/guides/aosp-build-instructions/build-aosp-android-android-11-0-0,
and also LineageOS using the instuctions at
https://wiki.lineageos.org/devices/kirin/build, but neither worked. That was a
couple weeks ago though, so I haven't tried the very latest kernel with full
Android. Let me know if you have any suggestions!
Thanks,
- Eric
> I'm already using your v5.10-rc3 branch, but ninges_defconfig isn't working for
> me. (Though I couldn't find the firmware file "qcom/a530_zap.elf", so I had to
> remove it from CONFIG_EXTRA_FIRMWARE.) Instead I'm using a kconfig based on
> https://github.com/SoMainline/linux/blob/marijn/android/arch/arm64/configs/defconfig
> which is working for me.
That's kind of expected, but Marijn's defconfig is fine. I just like
baking my firmware into the kernel for faster boot times.
> I haven't been able to get a full Android userspace to work, and currently I'm
> instead just replacing the kernel in a TWRP image and booting into recovery.
> It's enough to get adb shell access and chroot into a Debian chroot on the
> userdata partition, which is enough to run android-xfstests to test the ICE
> support. Earlier I tried AOSP using the instructions at
> https://developer.sony.com/develop/open-devices/guides/aosp-build-instructions/build-aosp-android-android-11-0-0,
These instructions are meant for use with Sony Open Devices trees
available at github.com/sonyxperiadev, currently with CAF-based kernel
4.14.
> and also LineageOS using the instuctions at
> https://wiki.lineageos.org/devices/kirin/build
This one is for use with stock-based (BSP 4.4 kernel) trees.
> but neither worked. That was a
> couple weeks ago though, so I haven't tried the very latest kernel with full
> Android. Let me know if you have any suggestions!
First of all, you're going to need to retrieve gpu firmware (530
pfp/pm4 and 508 ZAP) like I do here (please flash the latest ODM image
from here to the oem partition [1] with fastboot) [2].
We are successfully booting Android but need multiple patches around,
in particular to enable A508 in Mesa (basically find "case 510:" and
add "case 508:" above it, like here [3]. For basic functionality,
we're working on proper 508/509/512 support) and the android device
trees aren't in the best state.. We're going to focus on these when
other components are ready.
Konrad
[1] https://developer.sony.com/file/download/software-binaries-for-aosp-android-11-0-kernel-4-14-ganges/
[2] https://gitlab.com/postmarketOS/pmaports/-/blob/b249d76d95107c7eeaf64ef6b58c1dc08cf3ca2b/device/testing/firmware-sony-ninges/enable_firmware.initd
[3] https://github.com/SoMainline/mesa/commit/13c197d956a7bf1761242a7d29e1a43904ecc9b3