Secure boot on imx8m-mini

Technical Support
, , ,
1

Hi,

I want to use the secure boot on the imx8m-mini and having followed the various guides, the kernel boot fails after locking the device.
Currently I’m using the Toradex Yocto BSP v5.6.0 with some modifications for our baseboard and our specific application.

I have created the signed boot image and fitImage and programmed the SRK fuses. After doing this, the module boots up into Linux and there are no HAB errors reported in the bootloader.
If I then program the SEC_CONFIG fuse to close the device, the boot fails part way through the kernel boot. That is to say that the boot image still works OK and the fitImage authentication is still working (I can verify this by changing the fitImage for an unsigned one and then the authentication fails).
I have ensured that the CAAM MID is unlocked in the SPL CSF.

I am wondering whether anyone else has the secure boot working for the imx8m-mini using the Toradex BSP?
If necessary I can provide text output from the bootloader and the earlycon kernel ouptut (without earlycon there is no text output from the kernel, so the failure is relatively early in the kernel startup). Currently I don’t have a JTAG debugger so I’m limited to what is available on the serial console.

One other point is that directly after closing the device, the boot up worked OK… for a while. I think that I had powered off the board rather than just rebooting, but I can’t be absolutely certain of that.
When it did boot with the device closed I would get a couple of additional kernel messages related to the snvs-rtc not being accessible, but these did not prevent the board from operating normally.
Nothing was changed on the board between the boot working and it not working, in fact I wasn’t using the board for a few days and when I went back to it the boot fails consistently.

And one last thing is that if I program the FIELD_RETURN fuse on a board that fails when closed, then the board will boot normally again. This confirms to me that it is directly related to closing the device with the SEC_CONFIG fuse.

Thanks,
Andy

1 Like
2

Some additional information:
I decided to take a look at the SNVS registers and there are some differences between the closed device and an open one. Some to be expected such as the NPSWA_EN bit in the HP Command register (0x30370004), but others that I can’t explain, such as the low voltage detector register (0x30370064) being zero in the closed device. The latter should be set to 0x41736166 by software as described in section 6.4.2.2 of the imx8m-mini reference manual.
eg.
open device:
30370000: 00000000 80002100 00000000 00000000 …!..
30370010: 00000000 8000fb00 00002000 00000000 … …
30370020: 00000000 00000000 00000000 00000000 …
30370030: 00000000 00000000 00000021 00000000 …!..
30370040: 00000000 00000000 00000000 40000000 …@
30370050: 00000000 10680862 00000000 00000000 …b.h…
30370060: 00000000 41736166 00000000 00000000 …fasA…

closed device:
30370000: 00000001 00002020 00000000 00000000 … …
30370010: 00000000 8000bd00 80000000 00000000 …
30370020: 00000000 00000000 00000000 00000000 …
30370030: 00000000 00000000 00000020 00000000 … …
30370040: 00000000 00000000 00000000 00040008 …
30370050: 00000000 00000000 00000000 00000000 …
30370060: 00000000 00000000 00000000 00000000 …

I’m not sure why this is happening, nor am I sure why it would stop the kernel, but it seems as if it may be worth exploring.
Any suggestions are welcome.

As a side note, there appears to be a counter at 0x30370054, but this isn’t documented in the reference manual (or maybe it is but at a different address). That counter is not running in the closed device, but probably due to the low voltage detector?

3

Hi @andyha !

Right now we do not have much information about Secure Boot on Verdin iMX8M Mini.

I will check internally if we have something that could help you and answer back here.

Best regards,

4

Hi,

It turns out that the SNVS was the right place to look. I don’t think that this is a Toradex issue as much as an NXP issue.
With some help from a couple of NXP forum posts for other i.MX processors I think that I have resolved my issue. It is necessary to set the low voltage detector register to the correct value. I also set the SNVS to non-privileged mode.
I did this by adding a file arch/arm/mach-imx/imx8m/snvs.c in the bootloader based on the one in arch/arm/mach-imx/mx7
eg:
// SPDX-License-Identifier: GPL-2.0+
/*

  • Copyright 2018 Linaro
    */

#include <asm/io.h>
#include <asm/arch/imx-regs.h>
#include <linux/bitops.h>

#define SNVS_HPCOMR 0x04
#define SNVS_HPCOMR_NPSWA_EN BIT(31)
#define SNVS_LPLVDR 0x64
#define SNVS_LPLVDR_INIT 0x41736166
#define SNVS_LPSR 0x4C
#define SNVS_LPSR_RESET 0xFFFFFFFF

void init_snvs(void)
{
u32 val;

/* Ensure SNVS HPCOMR sets NPSWA_EN to allow unpriv access to SNVS LP */
val = readl(SNVS_HP_BASE_ADDR + SNVS_HPCOMR);
val |= SNVS_HPCOMR_NPSWA_EN;
writel(val, SNVS_HP_BASE_ADDR + SNVS_HPCOMR);

/* set LP low voltage detect register value */
writel(SNVS_LPLVDR_INIT, SNVS_HP_BASE_ADDR + SNVS_LPLVDR);

/* reset LP status register */
writel(SNVS_LPSR_RESET, SNVS_HP_BASE_ADDR + SNVS_LPSR);

}

The init_snvs function is then called from arch_cpu_init in /arch/arm/mach_imx/imx8m/soc.c

The links that helped me were:

This works for me at the moment because for my current usage it doesn’t matter that the SNVS is in non-privileged mode.

Andy

1 Like
6

Hi @andyha !

Thanks for the feedback!

Your reference might be helpful for other customers and I also brought it up internally as it might be useful for secure boot related documentation :slight_smile:

Best regards,

1 Like