Am 17.08.2015 um 02:19 schrieb Krzysztof Kozlowski:
> 2015-08-16 20:18 GMT+09:00 Heiner Kallweit <hkallweit1@xxxxxxxxx>:
>> 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.
Regards, Heiner
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
