On 18.08.2015 15:02, Heiner Kallweit wrote:
> Am 17.08.2015 um 08:30 schrieb Krzysztof Kozlowski:
>> 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@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.
>>
>> 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
>>
> I'm primarily interested in the HW RNG and a closer look to ace_sfr.h of the vendor kernel
> revealed that Slim SSS doesn't seem to support the SEED / PRNG registers.
> Therefore I didn't follow the SSS path further.
> Instead I checked exyswd-rng.c, the driver for the TRNG. But no luck either.
> SMC calls in general work but exynos_smc(SMC_CMD_RANDOM, HWRNG_INIT, 0, 0) returns -1.
> Not sure whether the firmware is somehow restricted or whether Exynos 5422 doesn't support the TRNG.
> Is there any publicly available information?
I understand that you ported the vendor driver from SM-G900H and used
(0x81000030) as SMC_CMD_RANDOM? The only problem with that approach is
that this code was released for different device than Odroid XU3. They
could have different Secure firmware (the library or OS in secure world)
and maybe the one on Odroid does not implement this particular SMC?
That would be probably the question to Hardkernel as they received TZSW
from vendor.
>
> By the way: Seems like a bug in the driver, the return values of exynos_smc are defined as
> positive values (#define HWRNG_RET_INVALID_ERROR 1) but actually it returns negative values
> in error case.
Once again I assume you're looking at vendor code. Please have it mind
that it may contain anything...
The exynos_smc() call does not return a value. The extern declaration is
misleading. Instead the exynos_smc() just executes smc instruction and
first argument (value in R0) is used as a return value.
Best regards,
Krzysztof
--
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
