i.MX ProcessorsのトピックRe: Boot ROM API on IMXRT1176

Boot ROM API on IMXRT1176

ericklein — Tue, 14 Jun 2022 18:55:32 GMT

I am trying to invoke the ROM boot after changing values in the fuse shadow memory as suggested in one of the security app notes. If I do it in the debugger, the ROM ends up in an endless loop after loading R0 with what appears to be the version of the OCOPT. Looking at IMXRT117X Security Reference, there isn't an entry point for initializing the ROM, and none for getting events like some of the other chips have. Has anyone had success with this? Should one of the registers have an error code as well?

Re: Boot ROM API on IMXRT1176

jeremyzhou — Wed, 15 Jun 2022 00:21:25 GMT

Hi,
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
To be honest, I'm not very clear with your question, whether you can describe a testing process of replicating the phenomenon.
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

Re: Boot ROM API on IMXRT1176

ericklein — Wed, 15 Jun 2022 14:32:23 GMT

I am calling the runBootloader() API as described in section 10.13.3 of the i.MX RT1170 Processor Reference Manual Rev. 1. My code is pasted below. As you can see, had to blow the BT_FUSE_SEL fuse to get this to work when not run from the debugger. My goal is to be able to set the SRK hash in the fuse shadow before calling the ROM to test my boot code.

When run from the debugger, the debugger goes straight to the start address, bypassing the ROM. I assume that is why it gets stuck in the ROM code, as I show in the original post.

Since posting I found the High Assurance Boot Version 4 Application Programming Interface Reference Manual. I assume, based on its features that the RT1170 is HAB4, even though I can not find a manual that explicitly states that. Much of the HAB4 document seems to line up with the RT1170 security reference, but the API part does not, nor does it seem to match what I see in the ROM vector table.

I feel like I am missing an important piece here and hope you can help me find it.

(looks like I don't have permission to paste pictures for some reason now, so here is the messy text paste of the code)

typedef struct BootloaderTree
{
void (*runBootloader)(const uint32_t *arg);
uint32_t version;
const char *copyright;
// const flexspi_nor_flash_driver_t *flexspiNorDriver;
} bootloader_tree_t;

uint32_t __attribute__((section(".secure_ram_data"))) arg;
uint32_t __attribute__((section(".secure_ram_data"))) first;

static void testBoot()
{
#if 0
if (SCB_CCR_IC_Msk == (SCB_CCR_IC_Msk & SCB->CCR))
{
SCB_DisableICache();
}
if (SCB_CCR_DC_Msk == (SCB_CCR_DC_Msk & SCB->CCR))
{
SCB_DisableDCache();
}

ARM_MPU_Disable();

OCOTP_Init(OCOTP, 0);
uint32_t version = OCOTP_GetVersion(OCOTP);
printf("Version=%d\n", version);

// Blow BT_FUSE_SEL to ignore pads for boot config (can't just update in shadow since SRC uses it)
uint32_t addr = ((0x960 - 0x800) >> 4);
status_t otpStatus = OCOTP_WriteFuseShadowRegister(OCOTP, addr, 0x10);
printf("optStatus=%d\n", otpStatus);

#endif

// try to set the SRK HASH in shadow
// *((uint32_t*)0x40CACB00) = 0x12345678;

const uint32_t romApiPtr = 0x21001c;
bootloader_tree_t *blTree = *((bootloader_tree_t**)romApiPtr);
arg = 0xEB000000;

(*(blTree->runBootloader))(&arg);
}

int main(int argc, char **argv)
{
if (first != 0xBADCAFE)
{
first = 0xBADCAFE;
testBoot();
}

Re: Boot ROM API on IMXRT1176

jeremyzhou — Thu, 16 Jun 2022 01:53:38 GMT

Hi,

Thanks for your reply.
According to your clarification, it seems to you want to use the ROM API to initiate a HAB secure boot manually, there's no similar application, unfortunately, I've zero experience with it, however, to implement the HAB secure boot, the SRK table should contain 8 words.
Lastly, I'd like to apply for further support via the NXP professional services.
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

Re: Boot ROM API on IMXRT1176

ericklein — Tue, 21 Jun 2022 14:31:36 GMT

Perhaps my initial post was too specific. I am mainly just looking for the address of the ROM APIs on the RT1176. In section 4.5 of the High Assurance Boot Version 4 Application Programming Interface Reference Manual it says:

"The ROM Vector Table consists of a Header followed by a list of addresses as described further below. For details on the location of the please refer to the System Boot chapter of the relevant NXP processor reference manual."

The only location in noted the RT1170 reference manual is 0x0021_001C but its layout does not match what is described in the HAB API manual, and it only includes the single runBootloader() entry point.

Re: Boot ROM API on IMXRT1176

jeremyzhou — Wed, 22 Jun 2022 01:16:28 GMT

Hi,
Thanks for your reply and clarification.
All RT series MCUs only support the below struct of the ROM APIs.

Hope this is clear.
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

Re: Boot ROM API on IMXRT1176

ericklein — Thu, 07 Jul 2022 20:12:50 GMT

I think I found the answer. Poking around the ROM, the pointer after the documented address 0x0021_001C, address 0x0021_0020 points to a structure that seems to line up with the documented ROM Vector table (the first byte is 0xDD). Calling the RVT entries for enter(), get_version(), and report_status() return values that seem to make sense. However, calling enter() followed by runBootloader() still results in the same hang, so apparently my theory that the ROM was uninitialized was wrong. It turns out that calling the RVT entry for failsafe() puts me at the same loop as runBootloader, so perhaps I just mis-interpreted what that entry does. In any case, with this information it looks like I may be able to proceed with updating the fuse shadows and testing the boot process.