i.MX6 IVT structure -- question

cancel
Showing results for 
Search instead for 
Did you mean: 

i.MX6 IVT structure -- question

Jump to solution
5,418 Views
dmitryv
Contributor II

Hello,

I have a generic question regarding i.MX6 IVT structure. I will refer to i.MX6 Platform SDK apps and u-boot binaries.

DCD section is used for setting up DDR memory both in SDK tests and in u-boot. DCD section itself is linked to DDR memory address space. Also if you look inside a binary you can find that ivt.dcd is pointing to DDR memory location:

# ./ivt_dump ./power_modes_test.bin

DCD: 0x10000430 (DDR)

# ./ivt_dump ./u-boot.bin

DCD: 0x2780042C (DDR)

So it looks like we should have DCD placed in DDR, but DDR is not yet initialized by DCD. I know that DCD should reside in initial load region and thus ti will be loaded to OCRAM. But how ROM will find the real DCD location based only on ivt.dcd, which is poiniting to non-initialized DDR?

Labels (1)
1 Solution
525 Views
AnsonHuang
NXP Employee
NXP Employee

Hi, Dmitry

     DCD table will be copied to OCRAM within the first 4K copy from SD/MMC. And the "dcd" and "self" will be used to count the "offset" of DCD table address, and ROM will read DCD table using this offset from OCRAM. For your case, the offset will be "0x10000430 - 0x10000000 = 0x430". I just dump my uboot, I can see the "dcd" is 0x2780042c, and "self" is 0x27800400, so the offset would be 0x2c = 44, which means the real dcd table is at the 44 / 4  + 1= 12nd data of the first 4K data(containing the IVT offset) copied to OCRAM, below is my ivt header definition, you can see the dcd table is at 12nd.  So, ROM will use these two value to count the offset, so there will be no DDR address accessed before DCD table is executed.

43 ivt_header:       .word 0x402000D1 /* Tag=0xD1, Len=0x0020, Ver=0x40 */

44 app_code_jump_v:  .word _start

45 reserv1:          .word 0x0

46 dcd_ptr:          .word dcd_hdr

47 boot_data_ptr:    .word boot_data

48 self_ptr:         .word ivt_header

49 #ifdef CONFIG_SECURE_BOOT

50 app_code_csf:     .word __hab_data

51 #else

52 app_code_csf:     .word 0x0

53 #endif

54 reserv2:          .word 0x0

55

56 boot_data:        .word TEXT_BASE

57 #ifdef CONFIG_SECURE_BOOT

58 image_len:        .word __hab_data_end - TEXT_BASE + CONFIG_FLASH_HEADER_OFFSET

59 #else

60 image_len:        .word _end_of_copy  - TEXT_BASE + CONFIG_FLASH_HEADER_OFFSET

61 #endif

62 plugin:           .word 0x0

63

64 #if defined CONFIG_MX6DL_DDR3

65 #if defined CONFIG_DDR_32BIT

66 dcd_hdr:          .word 0x40E001D2 /* Tag=0xD2, Len=59*8 + 4 + 4, Ver=0x40 */

View solution in original post

0 Kudos
5 Replies
525 Views
AnsonHuang
NXP Employee
NXP Employee

Hi, Dmitry

     Did you have other question about this IVT? Anything you need me to help? If no, could you please check the correct answer and close this ticket? Thanks in advanced!

0 Kudos
525 Views
AnsonHuang
NXP Employee
NXP Employee

Hi, Dmitry

     When power up the board, ROM will be executed first, then it will scan the boot mode setting to get which boot mode it should run, take SD/MMC boot for example, if user set the board to boot from SD/MMC, ROM will read first 2K data from SD/MMC to OCRAM, and the IVT header will be contained in this 2K data, then execute the DCD to initialize the DDR, then copy rest of uboot to DDR and jump to DDR to run. That means we always need to put IVT header in front of uboot binary and need to program this ivt+uboot into dedicated place of boot media. You can read the DCD header definition, you will see

525 Views
dmitryv
Contributor II

Hi Yongcai,

I understand the process of booting but I was asking another question. Let me explain in more details.

Here's the structure of boot stream (first 4K which will be loaded to OCRAM). On left side there are absolute addresses from the beginning of the file. On right side I placed values that are stored in this file.

01.png

Now when the boot ROM fetches the stream from boot source, the same 4K bytes are placed to some location in OCRAM (I will assume that they are placed from the beginning just for easy of understanding).

02.png

You can see that DCD physycal location is 0x0900_0430, but the pointer is pointing to location in DDR which is even not yet initialized.

I have an assumption that ROM will calculate the real address as ( dcd - self + OCRAM_BEGIN ) in this case.

0 Kudos
526 Views
AnsonHuang
NXP Employee
NXP Employee

Hi, Dmitry

     DCD table will be copied to OCRAM within the first 4K copy from SD/MMC. And the "dcd" and "self" will be used to count the "offset" of DCD table address, and ROM will read DCD table using this offset from OCRAM. For your case, the offset will be "0x10000430 - 0x10000000 = 0x430". I just dump my uboot, I can see the "dcd" is 0x2780042c, and "self" is 0x27800400, so the offset would be 0x2c = 44, which means the real dcd table is at the 44 / 4  + 1= 12nd data of the first 4K data(containing the IVT offset) copied to OCRAM, below is my ivt header definition, you can see the dcd table is at 12nd.  So, ROM will use these two value to count the offset, so there will be no DDR address accessed before DCD table is executed.

43 ivt_header:       .word 0x402000D1 /* Tag=0xD1, Len=0x0020, Ver=0x40 */

44 app_code_jump_v:  .word _start

45 reserv1:          .word 0x0

46 dcd_ptr:          .word dcd_hdr

47 boot_data_ptr:    .word boot_data

48 self_ptr:         .word ivt_header

49 #ifdef CONFIG_SECURE_BOOT

50 app_code_csf:     .word __hab_data

51 #else

52 app_code_csf:     .word 0x0

53 #endif

54 reserv2:          .word 0x0

55

56 boot_data:        .word TEXT_BASE

57 #ifdef CONFIG_SECURE_BOOT

58 image_len:        .word __hab_data_end - TEXT_BASE + CONFIG_FLASH_HEADER_OFFSET

59 #else

60 image_len:        .word _end_of_copy  - TEXT_BASE + CONFIG_FLASH_HEADER_OFFSET

61 #endif

62 plugin:           .word 0x0

63

64 #if defined CONFIG_MX6DL_DDR3

65 #if defined CONFIG_DDR_32BIT

66 dcd_hdr:          .word 0x40E001D2 /* Tag=0xD2, Len=59*8 + 4 + 4, Ver=0x40 */

View solution in original post

0 Kudos
525 Views
simmisxu
Contributor III

Hi Yongcai,

     About image_len:        .word _end_of_copy  - TEXT_BASE + CONFIG_FLASH_HEADER_OFFSET

     Why there is the " + CONFIG_FLASH_HEADER_OFFSET".

     In my opinion, _end_of_copy  - TEXT_BASE has already been the length of uboot image.

     Does " + CONFIG_FLASH_HEADER_OFFSET" mean that ROM loads uboot image from the beginning of emmc instead of from IVT offeset?

Thanks,

Simmis.

0 Kudos