Issues with HW RNG on Exynos 5422

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.

Am 15.08.2015 um 13:19 schrieb Heiner Kallweit:

Quoted 32 lines

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.

Quoted 2 lines

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

2015-08-16 20:18 GMT+09:00 Heiner Kallweit <[email protected]>:

Quoted 33 lines

Am 15.08.2015 um 13:19 schrieb Heiner Kallweit:

Quoted 32 lines

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.

Quoted 7 lines

Quoted 2 lines

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
.

Am 17.08.2015 um 02:19 schrieb Krzysztof Kozlowski:

Quoted 46 lines

2015-08-16 20:18 GMT+09:00 Heiner Kallweit <[email protected]>:

Quoted 33 lines

Am 15.08.2015 um 13:19 schrieb Heiner Kallweit:

Quoted 32 lines

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.

Quoted 7 lines

Quoted 2 lines

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.

Quoted 6 lines

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.

Quoted 68 lines

Am 17.08.2015 um 02:19 schrieb Krzysztof Kozlowski:

Quoted 46 lines

2015-08-16 20:18 GMT+09:00 Heiner Kallweit <[email protected]>:

Quoted 33 lines

Am 15.08.2015 um 13:19 schrieb Heiner Kallweit:

Quoted 32 lines

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.

Quoted 7 lines

Quoted 2 lines

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.

Quoted 6 lines

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.

Quoted 8 lines

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

Am 17.08.2015 um 08:30 schrieb Krzysztof Kozlowski:

Quoted 81 lines · Heiner Kallweit

Quoted 68 lines

Am 17.08.2015 um 02:19 schrieb Krzysztof Kozlowski:

Quoted 46 lines

2015-08-16 20:18 GMT+09:00 Heiner Kallweit <[email protected]>:

Quoted 33 lines

Am 15.08.2015 um 13:19 schrieb Heiner Kallweit:

Quoted 32 lines

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.

Quoted 7 lines

Quoted 2 lines

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.

Quoted 6 lines

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.

Quoted 8 lines

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.

Quoted 8 lines

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?

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.

Am 16.08.2015 um 13:18 schrieb Heiner Kallweit:

Quoted 35 lines

Am 15.08.2015 um 13:19 schrieb Heiner Kallweit:

Quoted 34 lines

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.

Quoted 6 lines

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

Sorry, there was a typo in the mail agent cc line.

Am 15.08.2015 um 13:19 schrieb Heiner Kallweit:

Quoted 26 lines

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.

Quoted 3 lines

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.