[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHCN7xLaGQMM67VC-2_G8XC7UuG4c+TbbYb4z=ibJwZsQF4YVw@mail.gmail.com>
Date: Tue, 10 Sep 2019 11:21:34 -0500
From: Adam Ford <aford173@...il.com>
To: Tony Lindgren <tony@...mide.com>
Cc: Pali Rohár <pali.rohar@...il.com>,
Linux-OMAP <linux-omap@...r.kernel.org>,
Tero Kristo <t-kristo@...com>,
Aaro Koskinen <aaro.koskinen@....fi>,
Adam Ford <adam.ford@...icpd.com>,
Benoît Cousson <bcousson@...libre.com>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Russell King <linux@...linux.org.uk>,
Paul Walmsley <paul@...an.com>,
devicetree <devicetree@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
arm-soc <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC] ARM: omap3: Enable HWMODS for HW Random Number Generator
On Tue, Sep 10, 2019 at 10:48 AM Adam Ford <aford173@...il.com> wrote:
>
> On Mon, Sep 9, 2019 at 11:35 AM Tony Lindgren <tony@...mide.com> wrote:
> >
> > * Pali Rohár <pali.rohar@...il.com> [190909 13:41]:
> > > On Monday 09 September 2019 08:37:09 Adam Ford wrote:
> > > > I applied this on 5.3 and it is working. I assume the same is true in for-next.
> >
> > Hmm I noticed I stopped getting RNG data after several rmmod modprobe
> > cycles, or several hd /dev/random reads. Anybody else seeing that?
> >
> > > > Do you want to submit a formal patch? I can mark it as 'tested-by'
> > > > This really helps speed up the startup sequence on boards with sshd
> > > > because it delays for nearly 80 seconds waiting for entropy without
> > > > the hwrng.
> > >
> > > Hi! When applying a patch, could you please disable this rng for n900?
> > >
> > > In omap3-n900.dts for rng should be status = "disabled" (as Tony already
> > > wrote), similarly like for aes.
> >
> > Yeah I'll post a proper patch after -rc1.
>
> FYI,
>
> By putting your node into omap34xx.dtsi and omap36xx.dtsi along with
> the following, I can get the RNG to work on an OMAP3530 and a DM3730.
>
>
> diff --git a/arch/arm/boot/dts/omap34xx-omap36xx-clocks.dtsi
> b/arch/arm/boot/dts/omap34xx-omap36xx-clocks.dtsi
> index 5e9d1afcd422..73f351e6d132 100644
> --- a/arch/arm/boot/dts/omap34xx-omap36xx-clocks.dtsi
> +++ b/arch/arm/boot/dts/omap34xx-omap36xx-clocks.dtsi
> @@ -259,7 +259,7 @@
> <&i2c1_ick>, <&uart2_ick>, <&uart1_ick>, <&gpt11_ick>,
> <&gpt10_ick>, <&mcbsp5_ick>, <&mcbsp1_ick>,
> <&omapctrl_ick>, <&aes2_ick>, <&sha12_ick>, <&icr_ick>,
> - <&des2_ick>, <&mspro_ick>, <&mailboxes_ick>,
> + <&des2_ick>, <&mspro_ick>, <&mailboxes_ick>,
> <&rng_ick>,
> <&mspro_fck>;
> };
> };
>
> I tried doing the same for am3517, but it doesn't appear to work. In
> fact, the board hangs at boot with no splat, so I assume that some
> clock isn't running and causing a hang. Figure 4-50 in the AM3517 TRM
> shows the security_l4_iclk2, so I wonder if the HW mods for AES, SHA,
> etc are doing something to enable this clock. Those HWmods are
> disabled on AM3517. I tried turning on the hwmods for them before
> without success, but I'll try it again.
According to a note in omap_hwmod_3xxx_data.c,
/*
* Apparently the SHA/MD5 and AES accelerator IP blocks are
* only present on some AM35xx chips, and no one knows which
* ones. See
* http://www.spinics.net/lists/arm-kernel/msg215466.html So
* if you need these IP blocks on an AM35xx, try uncommenting
* the following lines.
*/
I decided to uncomment the hwmod entries, and I got the following:
[ 0.263222] omap_hwmod: sham: _wait_target_ready failed: -16
[ 0.263248] omap_hwmod: sham: cannot be enabled for reset (3)
[ 0.265837] omap_hwmod: aes: _wait_target_ready failed: -16
[ 0.265851] omap_hwmod: aes: cannot be enabled for reset (3)
[ 6.208866] omap_hwmod: sham: _wait_target_ready failed: -16
[ 6.287732] omap_hwmod: aes: _wait_target_ready failed: -16
Based on this, I wonder if the sham and aes modules are not present.
If this is the case, it might explain why I cannot use the rng either.
adam
>
> adam
> >
> > Regards,
> >
> > Tony
Powered by blists - more mailing lists