More about boot and ivt

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

More about boot and ivt

5,195 Views
mastupristi
Senior Contributor I

On page 377 of the RT1050 reference manual I find this figure:

ivt-mem.png

I need more explanation (since there's nothing in the document).
What is Boot Device Memory? Is it correct to assume that the memory is where the bootable image is stored (in my case the QSPI)?

What is the Dest. Memory? Is it correct to assume that it is the memory from which the binary is run (in my case the ITCM or DTCM)?

Setting as follows:

Istantanea_2018-11-15_22-45-13.png

I get an image that is all in ram but that is mapped in the flash.

Linker script (generated) is like this:

MEMORY
{
 /* Define each memory region */
 BOARD_FLASH (rx) : ORIGIN = 0x60000000, LENGTH = 0x200000 /* 2M bytes (alias Flash) */
 SRAM_DTC (rwx) : ORIGIN = 0x20000000, LENGTH = 0x20000 /* 128K bytes (alias RAM) */
 SRAM_ITC (rwx) : ORIGIN = 0x0, LENGTH = 0x20000 /* 128K bytes (alias RAM2) */
 SRAM_OC (rwx) : ORIGIN = 0x20200000, LENGTH = 0x40000 /* 256K bytes (alias RAM3) */
 }

ENTRY(ResetISR)

SECTIONS
{
 /* Image Vector Table and Boot Data for booting from external flash */
 .boot_hdr : ALIGN(4)
 {
 FILL(0xff)
 __boot_hdr_start__ = ABSOLUTE(.) ;
 KEEP(*(.boot_hdr.conf))
 . = 0x1000 ;
 KEEP(*(.boot_hdr.ivt))
 . = 0x1020 ;
 KEEP(*(.boot_hdr.boot_data))
 . = 0x1030 ;
 KEEP(*(.boot_hdr.dcd_data))
 __boot_hdr_end__ = ABSOLUTE(.) ;
 . = 0x2000 ;
 } >BOARD_FLASH

 /* MAIN TEXT SECTION */
 .text : ALIGN(4)
 {
 FILL(0xff)
 __vectors_start__ = ABSOLUTE(.) ;
 KEEP(*(.isr_vector))
 /* Global Section Table */
 . = ALIGN(4) ;
 __section_table_start = .;
 __data_section_table = .;
 LONG((LOADADDR(.data) - __base_BOARD_FLASH) + __base_SRAM_DTC);
 LONG( ADDR(.data));
 LONG( SIZEOF(.data));
 LONG((LOADADDR(.data_RAM2) - __base_BOARD_FLASH) + __base_SRAM_DTC);
 LONG( ADDR(.data_RAM2));
 LONG( SIZEOF(.data_RAM2));
 LONG((LOADADDR(.data_RAM3) - __base_BOARD_FLASH) + __base_SRAM_DTC);
 LONG( ADDR(.data_RAM3));
 LONG( SIZEOF(.data_RAM3));
 __data_section_table_end = .;
 __bss_section_table = .;
 LONG( ADDR(.bss));
 LONG( SIZEOF(.bss));
 LONG( ADDR(.bss_RAM2));
 LONG( SIZEOF(.bss_RAM2));
 LONG( ADDR(.bss_RAM3));
 LONG( SIZEOF(.bss_RAM3));
 __bss_section_table_end = .;
 __section_table_end = . ;
 /* End of Global Section Table */

 *(.after_vectors*)

 } > SRAM_DTC AT> BOARD_FLASH

 .text : ALIGN(4)
 {
 *(.text*)
 *(.rodata .rodata.* .constdata .constdata.*)
 . = ALIGN(4);
 } > SRAM_DTC AT> BOARD_FLASH

[...]‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

and map file is:

Istantanea_2018-11-16_00-21-06.png

As you can see ivt is placed in flash, while .text (and also vectors) in DTCM.

Image 8-14 on page 377 suggests that ivt should be copied to Dest. Memory (I suppose from the rom bootloader), in fact, it also appears there. In addition, the arrows refer to Dest. Memory. Is this argument correct?

The IVT structure is depicted here:

ivt.png

the file evkbimxrt1050_led_blinky/xip/fsl_flexspi_nor_boot.c contains the ivt structure:

#if defined(XIP_BOOT_HEADER_ENABLE) && (XIP_BOOT_HEADER_ENABLE == 1)
#if defined(__CC_ARM) || defined(__GNUC__)
 __attribute__((section(".boot_hdr.ivt")))
#elif defined(__ICCARM__)
#pragma location=".boot_hdr.ivt"
#endif
/*************************************
 * IVT Data
 *************************************/
const ivt image_vector_table = {
 IVT_HEADER, /* IVT Header */
 IMAGE_ENTRY_ADDRESS, /* Image Entry Function */
 IVT_RSVD, /* Reserved = 0 */
 (uint32_t)DCD_ADDRESS, /* Address where DCD information is stored */
 (uint32_t)BOOT_DATA_ADDRESS, /* Address where BOOT Data Structure is stored */
 (uint32_t)&image_vector_table, /* Pointer to IVT Self (absolute address */
 (uint32_t)CSF_ADDRESS, /* Address where CSF file is stored */
 IVT_RSVD /* Reserved = 0 */
};
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

As you can see IVT self is populated with the address of IVT structure itself, that is in FLASH, contrary to what the image 8-14 on page 377 suggests, from which it can be deduced that self should point inside the destination area.

And another inconsistency:
entry should be the address of the first executable instruction. Here it is valued as the address of the vectors:

//*****************************************************************************
// The vector table.
// This relies on the linker script to place at correct location in memory.
//*****************************************************************************
extern void (* const g_pfnVectors[])(void);
extern void * __Vectors __attribute__ ((alias ("g_pfnVectors")));

__attribute__ ((used, section(".isr_vector")))
void (* const g_pfnVectors[])(void) = {
 // Core Level - CM7
 &_vStackTop, // The initial stack pointer
 ResetISR, // The reset handler
 NMI_Handler, // The NMI handler
 HardFault_Handler, // The hard fault handler
 0, // Reserved
 0, // Reserved
[...]‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

This seems to me an error. I would have populated entry with the value ResetISR which is the actual entry point. Something like this:

extern void ResetISR(void);

#if defined(XIP_BOOT_HEADER_ENABLE) && (XIP_BOOT_HEADER_ENABLE == 1)
#if defined(__CC_ARM) || defined(__GNUC__)
 __attribute__((section(".boot_hdr.ivt")))
#elif defined(__ICCARM__)
#pragma location=".boot_hdr.ivt"
#endif
/*************************************
 * IVT Data
 *************************************/
const ivt image_vector_table = {
 IVT_HEADER, /* IVT Header */
 (uint32_t)ResetISR, /* Image Entry Function */
 IVT_RSVD, /* Reserved = 0 */
 (uint32_t)DCD_ADDRESS, /* Address where DCD information is stored */
 (uint32_t)BOOT_DATA_ADDRESS, /* Address where BOOT Data Structure is stored */
 (uint32_t)&image_vector_table, /* Pointer to IVT Self (absolute address */
 (uint32_t)CSF_ADDRESS, /* Address where CSF file is stored */
 IVT_RSVD /* Reserved = 0 */
};
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Is this conjecture correct?

There's still something to fix because trying to run this doesn't work. And there are a lot of mismatches that raise a lot of doubts.

best regards

Max

Labels (1)
5 Replies

4,109 Views
jay_heng
NXP Employee
NXP Employee

You can try this tool, with this tool you don't need to care about the header(ivt, boot data...) any more

GitHub - JayHeng/nxp-sec-boot-ui: A one-stop GUI tool to work with NXP MCU (Kinetis, i.MXRT, LPC) RO... 

0 Kudos
Reply

4,109 Views
Yuri
NXP Employee
NXP Employee

Hello,

   Use the following app notes:

"i.MX RT Flashloader Use Case".

https://www.nxp.com/docs/en/nxp/application-notes/AN12238.pdf 

“Security Application Note”

https://www.nxp.com/webapp/sps/download/mod_download.jsp?colCode=AN12079&appType=moderated&Parent_no... 


Have a great day,
Yuri

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

0 Kudos
Reply

4,109 Views
mastupristi
Senior Contributor I

All these documents have already been analyzed. And they're not useful.
Questions about IVT remain open:

What is Boot Device Memory? What is the Dest. Memory?

The rom bootloader expects to find a copy of IVT also in the Dest. Memory, or not?

and all other questions need answers.

Moreover, my board has no USB connectivity, so I can't use MfgTools to program the QSPI.

I use Segger J-Link to program and debug, so I need to have a raw image of the bootable image, which we can't get from elftosb.

Finally, the build takes place on a linux machine, with an automatic build system based on yocto. So I need every software tool, involved in the build, to be run from the command line and available on linux.

best regards

Max

0 Kudos
Reply

4,109 Views
Yuri
NXP Employee
NXP Employee

Hello,

  As I see, the following discussion provides further investigation regarding the issue.

 https://community.nxp.com/message/1084428 

Regards,

Yuri.

0 Kudos
Reply

4,109 Views
mastupristi
Senior Contributor I

Yeah, I wrote that post. ;-)