Re: [PATCH] ARM: i.MX93: ele: start TRNG on i.MX93 rev a1

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

 



On Mon, Mar 11, 2024 at 09:20:07AM +0100, Ahmad Fatoum wrote:
> Hello Sascha,
> 
> On 11.03.24 09:06, Sascha Hauer wrote:
> > On i.MX93 a0 the TRNG seems to be started automatically. On rev a1 it's
> > not and OP-TEE panics with "Cannot retrieve random data from ELE". Start
> > the TRNG to let OP-TEE startup successfully.
> > 
> > Signed-off-by: Sascha Hauer <s.hauer@xxxxxxxxxxxxxx>
> > ---
> >  arch/arm/mach-imx/ele.c | 20 ++++++++++++++++++++
> >  1 file changed, 20 insertions(+)
> > 
> > diff --git a/arch/arm/mach-imx/ele.c b/arch/arm/mach-imx/ele.c
> > index ab3958cbd3..f8093fc694 100644
> > --- a/arch/arm/mach-imx/ele.c
> > +++ b/arch/arm/mach-imx/ele.c
> > @@ -165,6 +165,23 @@ int ele_get_info(struct ele_get_info_data *info)
> >  	return ret;
> >  }
> >  
> > +static int ele_get_start_trng(void)
> > +{
> > +        struct ele_msg msg = {
> 
> strange indentation.

Fixed.

> 
> > +		.version = ELE_VERSION,
> > +		.tag = ELE_CMD_TAG,
> > +		.size = 1,
> > +		.command = ELE_START_RNG,
> > +	};
> > +	int ret;
> > +
> > +	ret = ele_call(&msg);
> > +	if (ret)
> > +		pr_err("Could not start TRNG, response 0x%x\n", msg.data[0]);
> > +
> > +	return ret;
> > +}
> > +
> >  int imx93_ele_load_fw(void *bl33)
> >  {
> >  	struct ele_get_info_data info = {};
> > @@ -204,6 +221,9 @@ int imx93_ele_load_fw(void *bl33)
> >  		pr_err("Could not start ELE firmware: ret %d, response 0x%x\n",
> >  			ret, msg.data[0]);
> >  
> > +	if (rev == 0xa1)
> > +		ele_get_start_trng();
> 
> Does it hurt to start it unconditionally, even if it's already enabled?

I don't know and I don't have the a0 board available at the moment. I'll
test this once I have the board connected again, but for now I think
I'll only do this for the a1 board where I know it's needed.

> At the least, I'd prefer this to be rev >= 0xa1, so it need not be debugged
> again in the future.

Changed that. We don't know what we have to do on a new SoC revision anyway,
so it could be wrong either way. Note this is directly below this code:

	switch (rev) {
	case 0xa0:
		get_builtin_firmware_ext(mx93a0_ahab_container_img, bl33, &firmware, &size);
		break;
	case 0xa1:
		get_builtin_firmware_ext(mx93a1_ahab_container_img, bl33, &firmware, &size);
		break;
	default:
		pr_err("Unknown unhandled SoC revision %2x\n", rev);
		return -EINVAL;
	}

So we'll need to touch this place anyway once we get a new SoC revision.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |




[Index of Archives]     [Linux Embedded]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux