On Tuesday 27 August 2019 13:10:38 Adam Ford wrote:
> On Tue, Aug 27, 2019 at 12:46 PM Pali Rohár <pali.rohar@xxxxxxxxx> wrote:
> >
> > On Tuesday 27 August 2019 20:42:35 Tero Kristo wrote:
> > > On 27/08/2019 16:54, Adam Ford wrote:
> > > > On Tue, Aug 27, 2019 at 8:49 AM Pali Rohár <pali.rohar@xxxxxxxxx> wrote:
> > > > >
> > > > > On Tuesday 27 August 2019 08:34:33 Adam Ford wrote:
> > > > > > On Tue, Aug 27, 2019 at 8:24 AM Pali Rohár <pali.rohar@xxxxxxxxx> wrote:
> > > > > > >
> > > > > > > On Tuesday 27 August 2019 08:17:55 Adam Ford wrote:
> > > > > > > > On Tue, Aug 27, 2019 at 3:12 AM Pali Rohár <pali.rohar@xxxxxxxxx> wrote:
> > > > > > > > >
> > > > > > > > > On Monday 26 August 2019 11:00:21 Tero Kristo wrote:
> > > > > > > > > > On 24.8.2019 0.46, Aaro Koskinen wrote:
> > > > > > > > > > > Hi,
> > > > > > > > > > >
> > > > > > > > > > > I was looking at N900 boot logs from the current mainline (v5.3-rc),
> > > > > > > > > > > and noticed this:
> > > > > > > > > > >
> > > > > > > > > > > [ 3.297668] omap3_rom_rng: initializing
> > > > > > > > > > > [ 3.301940] omap3_rom_rng: unable to get RNG clock
> > > > > > > > > > > [ 3.307006] omap3-rom-rng: probe of omap3-rom-rng failed with error -2
> > > > > > > > > > >
> > > > > > > > > > > It seems some clock data was deleted with 0ed266d7ae5e ("clk: ti: omap3:
> > > > > > > > > > > cleanup unnecessary clock aliases"), including one for omap3-rom-rng.
> > > > > > > > > > > How this driver is supposed to work now? I guess it has been broken for
> > > > > > > > > > > a while. :-(
> > > > > > > > > >
> > > > > > > > > > You should have a DT node for the device, which contains the clock handle.
> > > > > > > >
> > > > > > > > I am interested in enabling the RNG too, because sshd takes a long
> > > > > > > > time to initialize without the hwrng.
> > > > > > > >
> > > > > > > > I am not able to find addresses in either the DM3730 TRM nor the
> > > > > > > > OMAP3530 TRM. Can someone from TI make a recommendation as to what
> > > > > > > > the node address should be? Having this would be a nice starting
> > > > > > > > point. Also looking at the other omap RNG nodes there are references
> > > > > > > > to hwmods, but looking at the platdata in pdata quirks, I am not
> > > > > > > > seeing anything.
> > > > > > > >
> > > > > > > > There is also chunks of code that exist insdie
> > > > > > > > arch/mach-omap2/omap-secure.c which appear to only be referenced from
> > > > > > > > this driver, so I wonder if there might be some way to
> > > > > > > > combine/condense this once it's been converted to device tree and
> > > > > > > > functional again.
> > > > > > >
> > > > > > > This part of code calls N900's PPA function via SMC instruction, which
> > > > > > > is provided by closed Nokia bootloader NOLO/X-Loader. So it is needed.
> > > > > >
> > > > > > I am arguing that there is open source code for OMAP2 and OMAP4 RNG, I
> > > > > > don't understand why we can't have support for everyone. The TRM
> > > > > > references the RNG, but it doesn't give much info. There are other
> > > > > > RNG's supported in the open source so I would think if the IP is
> > > > > > present in the chips, we should be able to use it without a custom
> > > > > > bootloader.
> > > > >
> > > > > I do not know about general solution for OMAP3.
> > > > >
> > > > > But Nokia N900 is HS device, has signed and closed bootloader (Nokia
> > > > > X-Loader) which is running in secure mode and it does not enable L3
> > > > > firewall (or how it is called in OMAP world) for accessing RNG blocks
> > > > > outside of secure mode. It just export PPA function which "other side"
> > > > > can use to get access to RNG.
> > > > >
> > > > > Accessing blocks which are not allowed by that firewall cause immediate
> > > > > reset of board. So kernel must avoid such things.
> > > > >
> > > > > So for OMAP3 HS devices, like N900, we need signed bootloader which
> > > > > either enable direct access to RNG (which we do not have) or bootloader
> > > > > which provide custom PPA call for RNG (which we have).
> > > > >
> > > > > Exactly same problem is with AES acceleration on N900. See for details:
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=69540a7c277d96382257216436f41abc040cc878
> > > >
> > > > I have an OMAP3 and I am able to access the AES and SHA acceleration
> > > > using the cryptodev instructions following:
> > > > http://processors.wiki.ti.com/index.php/AM335x_Crypto_Performance
> > > >
> > > > I am able to load the SHA and AES modules without signed bootloaders.
> > > >
> > > > >
> > > > > Later I played a bit with that L3 firewall and reading its configuration
> > > > > is also disabled. After trying to read it 3 or 4 times from userspace I
> > > > > got immediate reset of board. I was told that this is normal (firewall
> > > > > violation) and reset is there for security reasons.
> > > >
> > > > If you're using secure world, I would expect this behaviour, but I am
> > > > just not seeing why access to the HWRNG would be limited to secure
> > > > world when I can use HWRNG for other processors families without it.
> > > >
> > > > >
> > > > > Public GP TRM does not provide information because RNG is part of crypto
> > > > > IP and it is for HS devices. And IIRC TRM for HS devices is (or was)
> > > > > available only under NDA and only for licensed customers.
> > > >
> > > > I agree, yet the omap2 and omap4 rng have open source code. I wonder
> > > > how different the omap3 version is from the omap2.
> > > >
> > > > >
> > > > > Somebody from TI should really provide up-to-date information about this
> > > > > topic. All those information are from time when I played with AES which
> > > > > is from year 2014.
> > > >
> > > > I could not agree more.
> > >
> > > Delving on the topic of NDA chip features is dangerous area for TI people...
> > > as we might be violating NDA ourselves and get into trouble for it.
> >
> > Is really GP TRM under NDA? I was thought that only HS documentation is
> > under NDA.
>
> I was able to download the am3517 TRM:
> http://www.ti.com/lit/ug/sprugr0c/sprugr0c.pdf
>
> >
> > > I would prefer someone outside TI reverse engineers the support somehow
> > > against omap2/omap4, and sees what works out. AM35x public TRM might have
> > > some info on it, that chip is basically a copy of omap3.
>
> I am going under the assumption that the omap-rng driver that supports
> omap2 and omap4 could be modified to support the omap3 based on the
> fact that the AES and SHA drivers work on omap2, omap3, and omap4. If
> we can do that, I would think we could deprecate the existing omap3
> version which requires platdata and pdata-quirks.
We cannot deprecate it for HS devices where direct access to RNG is not
allowed by firewall, like for N900.
> I have the AM35 doc, but the AM35 doc shows the IP address blocks for
> RNG, AES and SHA match the omap2 and not omap3, so I assume that the
> RNG will probably be different as well. I checked the IRQ mapping for
> AES and SHA, and RNG on the AM3517 IRQ also matches the OMAP2 (not
> OMAP3), so I also assume the IRQ won't match OMAP3 either.
>
> Looking at the omap-rng driver (not the omap3 version), it appears as
> if the omap2 version doesn't appear to use an ISR, so the actual
> interrupt may be less important. If I was to guess what the address
> would be, I would guess the address for omap3 to be 480c1000, and I am
> also guessing the omap2/omap4 driver would work once the device tree
> is addressed, but it's just a guess based on the addresses of AES and
> SHA.
>
> Using the 4.19 kernel, I wasn't able to get it working due to missing
> hwmods for omap3, but I am hoping with hwmods going away, we might be
> able to address this easier in the future.
>
> omap34xx-omap36xx-clocks.dtsi shows rng_ick, but I am not sure if it's
> fully functional. If it is, I would assume that it would.
Thanks for quick investigation. I was hoping that somebody from TI could
bring some light and help with these details...
> adam
> > >
> > > -Tero
> > >
> > > >
> > > > adam
> > > > >
> > > > > > adam
> > > > > >
> > > > > > >
> > > > > > > > adam
> > > > > > > > >
> > > > > > > > > Hello, I have not tested new kernel on N900 for a longer time. And at
> > > > > > > > > that time (4.9) it worked fine. So it is just missing DT node? Maybe you
> > > > > > > > > could fix it when you testing it?
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Pali Rohár
> > > > > > > > > pali.rohar@xxxxxxxxx
> > > > > > >
> > > > > > > --
> > > > > > > Pali Rohár
> > > > > > > pali.rohar@xxxxxxxxx
> > > > >
> > > > > --
> > > > > Pali Rohár
> > > > > pali.rohar@xxxxxxxxx
> > >
> > > --
> > > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> >
> > --
> > Pali Rohár
> > pali.rohar@xxxxxxxxx
--
Pali Rohár
pali.rohar@xxxxxxxxx
Attachment:
signature.asc
Description: PGP signature
