OMAP36 AES and SHA addresses and hwmods

OMAP36 AES and SHA addresses and hwmods

[Adam Ford]

According to the dm3730 reference manual, there are supposed to be two
AES and SHA engines, but the addresses of their IP doesn't appear in
the reference manual.

The AM35xx has references to two memory locations for each:

   AES1 shows it's at 0x480A 6000
   AES2 shows is 0x480C 5000 (matches omap3630 entry)

   SHA1MD5 2 shows it's at 480c 3000 (matches omap3630 entry)
   SHA2MD5 shows it's at 0x480A 4000

Is it reasonable to think the other IP block addresses for the
am3630/dm3730 would match the am35xx?

Currently in the OMAP3630, there are hwmods setup for AES and SHA
engines, but the rng uses the newer approach with ti,sysc and
sysc-omap2.

I tried to just copy the existing blocks to the other addresses, but I
got some errors. I assume it's due to hwmods.  It seems like we should
be able to convert the hwmods out, and add the additional addresses
for the omap36, but before I go too far, I want to know if it'll even
be possible.

thanks

adam

Re: OMAP36 AES and SHA addresses and hwmods

[Tero Kristo]

On 03/05/2020 18:48, Adam Ford wrote:
> According to the dm3730 reference manual, there are supposed to be two
> AES and SHA engines, but the addresses of their IP doesn't appear in
> the reference manual.
> 
> The AM35xx has references to two memory locations for each:
> 
>     AES1 shows it's at 0x480A 6000
>     AES2 shows is 0x480C 5000 (matches omap3630 entry)
> 
>     SHA1MD5 2 shows it's at 480c 3000 (matches omap3630 entry)
>     SHA2MD5 shows it's at 0x480A 4000
> 
> Is it reasonable to think the other IP block addresses for the
> am3630/dm3730 would match the am35xx?
> 
> Currently in the OMAP3630, there are hwmods setup for AES and SHA
> engines, but the rng uses the newer approach with ti,sysc and
> sysc-omap2.
> 
> I tried to just copy the existing blocks to the other addresses, but I
> got some errors. I assume it's due to hwmods.  It seems like we should
> be able to convert the hwmods out, and add the additional addresses
> for the omap36, but before I go too far, I want to know if it'll even
> be possible.

All omap3 family should share identical address space for these IPs.

-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: OMAP36 AES and SHA addresses and hwmods

[Tony Lindgren]

* Tero Kristo <t-kristo@ti.com> [200504 06:29]:
> On 03/05/2020 18:48, Adam Ford wrote:
> > According to the dm3730 reference manual, there are supposed to be two
> > AES and SHA engines, but the addresses of their IP doesn't appear in
> > the reference manual.
> > 
> > The AM35xx has references to two memory locations for each:
> > 
> >     AES1 shows it's at 0x480A 6000
> >     AES2 shows is 0x480C 5000 (matches omap3630 entry)
> > 
> >     SHA1MD5 2 shows it's at 480c 3000 (matches omap3630 entry)
> >     SHA2MD5 shows it's at 0x480A 4000
> > 
> > Is it reasonable to think the other IP block addresses for the
> > am3630/dm3730 would match the am35xx?
> > 
> > Currently in the OMAP3630, there are hwmods setup for AES and SHA
> > engines, but the rng uses the newer approach with ti,sysc and
> > sysc-omap2.
> > 
> > I tried to just copy the existing blocks to the other addresses, but I
> > got some errors. I assume it's due to hwmods.  It seems like we should
> > be able to convert the hwmods out, and add the additional addresses
> > for the omap36, but before I go too far, I want to know if it'll even
> > be possible.
> 
> All omap3 family should share identical address space for these IPs.

For configuring the accelerators, the dts entries needed should be
very similar to the other SoCs. AFAIK, there are no "ti,sysc-omap4"
compatible devices for omap3 though, and they should be configured
as "ti,sysc-omap2". I could be wrong though, but this can be seen
from the module revision register.

For omap3, you need to specify both "fck" and "ick" for the ti-sysc
config. Not sure what's up with the multiple addresses or instance,
it's best to check what works.

Regards,

Tony

Re: OMAP36 AES and SHA addresses and hwmods

[Adam Ford]

On Mon, May 4, 2020 at 10:06 AM Tony Lindgren <tony@atomide.com> wrote:
>
> * Tero Kristo <t-kristo@ti.com> [200504 06:29]:
> > On 03/05/2020 18:48, Adam Ford wrote:
> > > According to the dm3730 reference manual, there are supposed to be two
> > > AES and SHA engines, but the addresses of their IP doesn't appear in
> > > the reference manual.
> > >
> > > The AM35xx has references to two memory locations for each:
> > >
> > >     AES1 shows it's at 0x480A 6000
> > >     AES2 shows is 0x480C 5000 (matches omap3630 entry)
> > >
> > >     SHA1MD5 2 shows it's at 480c 3000 (matches omap3630 entry)
> > >     SHA2MD5 shows it's at 0x480A 4000
> > >
> > > Is it reasonable to think the other IP block addresses for the
> > > am3630/dm3730 would match the am35xx?
> > >
> > > Currently in the OMAP3630, there are hwmods setup for AES and SHA
> > > engines, but the rng uses the newer approach with ti,sysc and
> > > sysc-omap2.
> > >
> > > I tried to just copy the existing blocks to the other addresses, but I
> > > got some errors. I assume it's due to hwmods.  It seems like we should
> > > be able to convert the hwmods out, and add the additional addresses
> > > for the omap36, but before I go too far, I want to know if it'll even
> > > be possible.
> >
> > All omap3 family should share identical address space for these IPs.
>
> For configuring the accelerators, the dts entries needed should be
> very similar to the other SoCs. AFAIK, there are no "ti,sysc-omap4"
> compatible devices for omap3 though, and they should be configured
> as "ti,sysc-omap2". I could be wrong though, but this can be seen
> from the module revision register.
>
> For omap3, you need to specify both "fck" and "ick" for the ti-sysc
> config. Not sure what's up with the multiple addresses or instance,
> it's best to check what works.

I wasn't seeing both clocks, but I was able to migrate the AES from
hwmods by referencing aes2_ick and aes1_ick.

[    8.002349] omap-aes 480a6000.aes1: OMAP AES hw accel rev: 2.6
[    8.066375] omap-aes 480a6000.aes1: will run requests pump with
realtime priority
[    8.425506] omap-aes 480c5000.aes2: OMAP AES hw accel rev: 2.6
[    8.492614] omap-aes 480c5000.aes2: will run requests pump with
realtime priority

Feel free to reject if you think I missed something.  I will admit
that I am not fully understanding the migration path, but I used the
RNG stuff you did to help.

If / when this gets accepted, I'll do the same for the SHA engine, but
I wanted to start with one first, before moving on.

Tony - Is there value in doing the migration to other areas (like GPIO) as well?

adam
>
> Regards,
>
> Tony

Re: OMAP36 AES and SHA addresses and hwmods

[Tony Lindgren]

* Adam Ford <aford173@gmail.com> [200504 23:07]:
> I wasn't seeing both clocks, but I was able to migrate the AES from
> hwmods by referencing aes2_ick and aes1_ick.

Oh OK good to hear you got it working.

> [    8.002349] omap-aes 480a6000.aes1: OMAP AES hw accel rev: 2.6
> [    8.066375] omap-aes 480a6000.aes1: will run requests pump with
> realtime priority
> [    8.425506] omap-aes 480c5000.aes2: OMAP AES hw accel rev: 2.6
> [    8.492614] omap-aes 480c5000.aes2: will run requests pump with
> realtime priority
> 
> Feel free to reject if you think I missed something.  I will admit
> that I am not fully understanding the migration path, but I used the
> RNG stuff you did to help.

OK I'll check and see if it may need to be also blocked for
n900 and other HS SoCs.

> If / when this gets accepted, I'll do the same for the SHA engine, but
> I wanted to start with one first, before moving on.
> 
> Tony - Is there value in doing the migration to other areas (like GPIO) as well?

Sure, for most types of devices we already have examples so they
can be updated whenever suitable.

Regards,

Tony