Re: OMAP3 ROM RNG probe failure on N900

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.

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




[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux