From: Krzysztof Kozlowski <k.kozlowski@samsung.com>
To: Heiner Kallweit <hkallweit1@gmail.com>
Cc: linux-samsung-soc@vger.kernel.org, linux-crypto@vger.kernel.org,
Jonghwa Lee <jonghwa3.lee@samsung.com>
Subject: Re: Issues with HW RNG / SSS on Exynos 5422
Date: Mon, 17 Aug 2015 15:30:40 +0900 [thread overview]
Message-ID: <55D17F90.80304@samsung.com> (raw)
In-Reply-To: <55D17AEF.9030706@gmail.com>
On 17.08.2015 15:10, Heiner Kallweit wrote:
> Am 17.08.2015 um 02:19 schrieb Krzysztof Kozlowski:
>> 2015-08-16 20:18 GMT+09:00 Heiner Kallweit <hkallweit1@gmail.com>:
>>> Am 15.08.2015 um 13:19 schrieb Heiner Kallweit:
>>>> I'm having issues making the hardware RNG work on a Samsung Exynos 5422 (Odroid XU4) with kernel 4.2rc6.
>>>> No random number generation is started if I write the appropriate value (0x18) to the hash control register.
>>>>
>>>> What I did so far:
>>>> Splitted the sss DT node in exynos5420.dtsi into one for the s5p-sss driver and one for the exynos-rng driver.
>>>> (s5p-sss doesn't seem to need the hash registers from offset 0x400)
>>>>
>>>> sss: sss@10830000 {
>>>> icompatible = "samsung,exynos4210-secss";
>>>> reg = <0x10830000 0x400>;
>>>> interrupts = <0 112 0>;
>>>> clocks = <&clock CLK_SSS>;
>>>> clock-names = "secss";
>>>> };
>>>>
>>>> rng: rng@10830400 {
>>>> compatible = "samsung,exynosrng-secss";
>>>> reg = <0x10830400 0x300>;
>>>> clocks = <&clock CLK_SSS>;
>>>> clock-names = "secss";
>>>> };
>>>>
>>>> The DT binding is just for testing and after adding some DT glue logic (of_device_id table) to the exynos-rng driver
>>>> it binds to the rng platform device.
>>>> The clock also seems to be ok with a rate of 266 MHz.
>>>> As is the driver hangs in a loop because the PRNG_DONE in the status register bit never gets set.
>>>>
>>>> I traced it back to the hash control register not accepting value 0x8 (or 0x18 incl. the start bit) for the PRNG.
>>>> Writing a value and reading it back works for values from 0 to 5 only.
>>>> As I have no SSS datasheet my only other reference is drivers/crypto/ace_sha.h in the uboot source code
>>>> which also uses the HW RNG.
>>>>
>>>> Any hint would be appreciated.
>>>>
>>> After some more testing it seems like SSS in general has problems on Exynos 5422.
>>> Also the AES implementation in s5p-sss doesn't work. dmesg output:
>>>
>>> [ 7.116739] alg: skcipher: encryption failed on chunk test 1 for ecb-aes-s5p: ret=22
>>> [ 7.123673] s5p-sss driver registered
>>
>> Have you tried or looked at vendor code for Samsung mobile devices?
>> The code can be downloaded from opensource.samsung.com. I think the
>> model with Exynos5422 is SM-G900H.
>>
>> I don't have any other hints...
>>
>> Best regards,
>> Krzysztof
>> .
>>
> Thanks for your feedback.
>
> I now took a look at the kernel code Odroid provides, especially the ACE crypto driver.
> It's a 3.10.82 kernel with a lot of Samsung code which is not (yet) upstreamed.
>
> There seem to be different revisions of SSS (ACE driver mentions v.4, v.5, v.6, and Slim SSS).
> The vendor kernel uses Slim SSS and the HW AES encryption works.
> The code there looks like Exynos 5422 should support also v.5, but it's disabled.
>
> I didn't test all SSS registers but for the ones I tested I can change the value.
> Having said that access to SSS registers is not forbidden.
>
> Then I changed the memory mapped region to 0x10900000, offset 0x800. According to the
> vendor kernel code there should be the registers for hash functions under Slim SSS.
>
> Not much luck either .. Maybe because Slim SSS uses another clock.
> The Slim SSS clock is defined in include/dt-bindings/clock/exynos5420.h already.
> I added a clock definition based on the one in the vendor kernel and changed the DT node to use it.
>
> GATE(CLK_SSS, "sss", "aclk266_g2d", GATE_IP_G2D, 2, 0, 0),
> + GATE(CLK_SLIM_SSS, "slimsss", "aclk266_g2d", GATE_IP_G2D, 12, 0, 0),
>
> But this didn't do the trick yet.
Try booting with "clk_ignore_unused" in command line to reduce the
chance that wrong clock-hierarchy causes some important clocks to be gated.
The clock hierarchy for SSS in mainline is not fully implemented. Beside
multiple SSS clocks in GATE_IP_G2D and other places, there are also SSS
bus clocks in GATE_BUS_G2D. By default (after reset) they are not gated
but who knows what bootloader does with them?
Best regards,
Krzysztof
next prev parent reply other threads:[~2015-08-17 6:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-15 11:19 Issues with HW RNG on Exynos 5422 Heiner Kallweit
2015-08-16 11:18 ` Issues with HW RNG / SSS " Heiner Kallweit
2015-08-17 0:19 ` Krzysztof Kozlowski
2015-08-17 6:10 ` Heiner Kallweit
2015-08-17 6:30 ` Krzysztof Kozlowski [this message]
2015-08-18 6:02 ` Heiner Kallweit
2015-08-18 6:49 ` Krzysztof Kozlowski
[not found] ` <55D07227.1010209@gmail.com>
2015-08-17 0:45 ` jonghwa3.lee
2015-08-24 0:33 ` Krzysztof Kozlowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55D17F90.80304@samsung.com \
--to=k.kozlowski@samsung.com \
--cc=hkallweit1@gmail.com \
--cc=jonghwa3.lee@samsung.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).