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.
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.
-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
