am335x crypto module clocks

am335x crypto module clocks

[Matthijs van Duin]

Hi all,

To my surprise, the am335x clock tree (am33xx-clocks.dtsi) currently
lists the functional clock of the AES accelerator and other crypto
modules to be the (max 26 MHz) main osc. This struck me as rather
unlikely, since the AES module is clocked much higher on other
devices, and such a slow clock would condemn it to being slower than a
software AES implementation.  As usual the TRM is silent on the crypto
accelerators and their clock management, but I did some preliminary
tests.

The AES module turned out far from slow.  I actually had a lot of
trouble keeping the module continuously fed with data with a simple
non-dma test from userspace, since for most modes of operation the AES
module could even keep pace with a tight loop using 128-bit neon
load/store without even checking its status register for readiness.

Although I haven't been able to get obtain a very reliable measurement
yet as a result, it appears to be clocked at ~200 MHz. This also
matches the fact that it is hooked up to the L3F (which would be
rather pointless if it had a separate low-rate fck).

It seems very likely to me the other crypto modules will also have a
unified fck/ick (L3F for the hash accelerator, L4LS for the RNG and
PKA). This should preferably still be double-checked of course.

Matthijs

Re: am335x crypto module clocks

[Tony Lindgren]

* Matthijs van Duin <matthijsvanduin@gmail.com> [150404 21:26]:
> Hi all,
> 
> To my surprise, the am335x clock tree (am33xx-clocks.dtsi) currently
> lists the functional clock of the AES accelerator and other crypto
> modules to be the (max 26 MHz) main osc. This struck me as rather
> unlikely, since the AES module is clocked much higher on other
> devices, and such a slow clock would condemn it to being slower than a
> software AES implementation.  As usual the TRM is silent on the crypto
> accelerators and their clock management, but I did some preliminary
> tests.
> 
> The AES module turned out far from slow.  I actually had a lot of
> trouble keeping the module continuously fed with data with a simple
> non-dma test from userspace, since for most modes of operation the AES
> module could even keep pace with a tight loop using 128-bit neon
> load/store without even checking its status register for readiness.
> 
> Although I haven't been able to get obtain a very reliable measurement
> yet as a result, it appears to be clocked at ~200 MHz. This also
> matches the fact that it is hooked up to the L3F (which would be
> rather pointless if it had a separate low-rate fck).
> 
> It seems very likely to me the other crypto modules will also have a
> unified fck/ick (L3F for the hash accelerator, L4LS for the RNG and
> PKA). This should preferably still be double-checked of course.

Tero, got any ideas about this one?

Regards,

Tony

Re: am335x crypto module clocks

[Tero Kristo]

On 04/09/2015 06:13 PM, Tony Lindgren wrote:
> * Matthijs van Duin <matthijsvanduin@gmail.com> [150404 21:26]:
>> Hi all,
>>
>> To my surprise, the am335x clock tree (am33xx-clocks.dtsi) currently
>> lists the functional clock of the AES accelerator and other crypto
>> modules to be the (max 26 MHz) main osc. This struck me as rather
>> unlikely, since the AES module is clocked much higher on other
>> devices, and such a slow clock would condemn it to being slower than a
>> software AES implementation.  As usual the TRM is silent on the crypto
>> accelerators and their clock management, but I did some preliminary
>> tests.
>>
>> The AES module turned out far from slow.  I actually had a lot of
>> trouble keeping the module continuously fed with data with a simple
>> non-dma test from userspace, since for most modes of operation the AES
>> module could even keep pace with a tight loop using 128-bit neon
>> load/store without even checking its status register for readiness.
>>
>> Although I haven't been able to get obtain a very reliable measurement
>> yet as a result, it appears to be clocked at ~200 MHz. This also
>> matches the fact that it is hooked up to the L3F (which would be
>> rather pointless if it had a separate low-rate fck).
>>
>> It seems very likely to me the other crypto modules will also have a
>> unified fck/ick (L3F for the hash accelerator, L4LS for the RNG and
>> PKA). This should preferably still be double-checked of course.
>
> Tero, got any ideas about this one?

This seems like just improperly modelled clock data. Looking at some 
PRCM documentation, the proper parent for aes/sha seems to be l3_gclk.
pka/rng/des is using l4ls_gclk.

The separate aes/sha clock nodes should just be deleted from the clock 
data, and instead use the proper main_clk definition under the hwmod data.

-Tero

Re: am335x crypto module clocks

[Matthijs van Duin]

On 13 April 2015 at 12:27, Tero Kristo <t-kristo@ti.com> wrote:
> pka/rng/des is using l4ls_gclk.

Does any instance of subarctic actually have a working DES
accelerator? Looking at the L4LS memory map, the only plausible
location for it would be 0x48315000 (sec context) / 0x48316000 (pub
context), but after enabling it manually in PRCM I still get a bus
error on attempt to read the version register (offset 0x30) through
either context.

(Of course it doesn't seem likely that anyone will miss it anyway...)


The PKA does appear to work, but it's missing from the hwmod data and
device tree. Given the TRM's (annoying) usual silence on crypto
modules, I'll summarize the relevant integration info I have:

For device-tree:
        pka: pka@48318000 {
                reg = <0x48318000 0x4000>;
                interrupts = <110>;
        };

Relevant wrapper registers:
0x1fe0  revision (highlander format)
0x1ff0  sysconfig
0x1ff4  sysstatus
0x1ff8  irq rawstatus
0x1ffc  irq enabled

For sysconfig, looks like bit 0 is autoidle, bit 1 reset, bits 4-5
(oddly) seem to be idlemode, though any mode other than force-idle
(the reset default) behaves like no-idle.

Clkctrl register is at offset 0xa4.

To be honest I don't understand all the hwmod stuff well enough yet to
attempt a patch myself.