tiboot.h for K2H/K2K and RBL Entry Address

HRC

Prodigy 150 points

Other Parts Discussed in Thread: 66AK2H14

Dear TI supporters,

Is it possible to get tiboot.h for Keystone-II series like tiboot_c66x.h of C6670?

We are planning to migrate C6670 to TCI6638 (I believe TCI6638 RBL should be same as 66AK2H14 ?).

I have successfully used C6670 native RBL to do multi-core boot.

I plan to leverage same Multi-core boot mechanism on new platform to boot DSPs and ARM u-boot, that is, DSP core of TCI6638 will be the boot master.

I need to know the entry address of C66x RBL of TCI6638 to do 2-stage boot process.

Also, can the tool chain of C6670 be used for K2H/K2K (b2ccs, b2i2c, romparse, hex6x...)?

It will save us a lot of time if I can leverage same method to do Multi-core boot process.

Thanks a lot for your kindly help.

Looking forward to seeing good news.

Best regards,

Henry

over 9 years ago

0 Raja over 9 years ago

TI__Guru* 81335 points

Hi Henry,

For keystone II devices, please use the MCSDK 3.x for development. Please find the download and MCSDK user guide link below my signature.

Thank you.

0 Michael Scherban over 9 years ago

TI__Genius 12320 points

Hi Henry,

The tool chain is expected to remain the same.

There are two address you can use to re-enter back into the DPS boot ROM:
0x20b00000: Initial boot address. This will likely re-latch boot pins and boot the same way your first boot did. Probably not what you want.

0x20b00008: This branch address should let you re-enter boot without re-latching pins. So you can modify the DSP boot parameter table and boot with those new parameters.

Let me know if you have an issue with the following link to tiboot.h: txn.box.com/.../f3vj5ettn5fm1wuei4x9h50r3av51kyl

Regards,
Mike

0 Michael Scherban over 9 years ago

TI__Genius 12320 points

Since you mention you will be using ARM U-boot: Is U-boot going to be used to get to Linux? If that is the case there is the option available for you to use Multi-Proc-Manager (MPM) in Linux (preinstalled in the MCSDK), which allows you to load DPS images onto DPS cores and execute them.

0 HRC over 9 years ago in reply to Michael Scherban

Prodigy 150 points

Hi Michael,

Thanks for your help.
I can get tiboot.h via your link and the entry address information is really helpful while implementing DSP RBL 2-stage boot procedure.

Regarding u-boot, yes, we will use it to load Linux kernel for ARM.
I'll look into MPM you mentioned for further preparation.
Personally, I intend to use DSP as the boot master, because I've spent a lot of time to make C6670 SPI Multi-core boot workable.
And it will save us time for booting.
Anyway, thanks for all of you, your great support will help our projects to go much more smooth and faster.

Sincerely,
Henry

0 HRC over 9 years ago in reply to Raja

Prodigy 150 points

Hi Raja,

Thanks for your quick response, I've installed MCSDK3.x in my PC.
But it didn't have bootloader utility that had tiboot.h included.

Best regards,
Henry

0 Michael Scherban over 9 years ago in reply to HRC

TI__Genius 12320 points

You're welcome.

I should warn you about a complication you'll run into with that method. When U-boot executes it will shut down each DSP. This can be stopped by getting into U-boot once and at the command line typing "setenv debug_options 1; saveenv". Or the code can be removed in function misc_init_r: arch/arm/cpu/armv7/keystone/keystone_common.c.

Regards,

Mike

0 HRC over 9 years ago in reply to Michael Scherban

Prodigy 150 points

Hi Mike,

Thanks for the valuable information.
It's really helpful.

Thank you,
Henry

0 HRC over 9 years ago in reply to Michael Scherban

Prodigy 150 points

Hi Mike,

Sorry to bother you.

Do you have a workable value of xxx.map for TCI6638 used by romparse.exe, just looks like :

section {
boot_mode = 50
param_index = 0
options = 1
core_freq_mhz = 1000
exe_file = "multicore.i2c.ccs"
next_dev_addr_ext = 0x0
sw_pll_prediv = 29
sw_pll_mult = 472
sw_pll_postdiv = 2
sw_pll_flags = 1
addr_width = 24
n_pins = 4
csel = 0
mode = 1
c2t_delay = 0
bus_freq_mhz = 1
bus_freq_khz = 0
}

Or is it same as C6670?

Also, can you provide a workable structure value of BOOT_PARAMS_SPI_T used for second stage boot process?

typedef struct boot_params_spi_s
{
    /* common portion of the Boot parameters */
    UINT16 length;
    UINT16 checksum;
    UINT16 boot_mode;
    UINT16 portNum;
    UINT16 swPllCfg_msw; /* CPU PLL configuration, MSW */
    UINT16 swPllCfg_lsw; /* CPU PLL configuration, LSW */
    UINT16 swPll2Cfg_msw; /* CPU PLL configuration, MSW */
    UINT16 swPll2Cfg_lsw; /* CPU PLL configuration, LSW */
    UINT16 sysFreqMhz;    /* System clock frequency, MHz */
    UINT16 coreFreqMhz;   /* Core clock frequency, MHz   */
     BOOL   bootMaster;    /* True if the core is the boot master */
    UINT16 options;
     UINT16 addrWidth;          /* 16 or 24 are the only valid values */
     UINT16 nPins;              /* 4 or 5 pins are the only valid values */
     UINT16 csel;               /* only values 0b10 (cs0 low) or 0b01 (cs1 low) are valid */
     UINT16 mode;               /* Clock phase/polarity. These are the standard SPI modes 0-3 */
     UINT16 c2tdelay;           /* Setup time between chip select assert and the transaction */
     UINT16 busFreq100Khz;      /* The SPI bus frequency in units of 100 kHz */
     UINT16 read_addr_msw;      /* The base address to read from the SPI, upper 16 bits */
     UINT16 read_addr_lsw;      /* The base address to read from the SPI, lower 16 bits */
     UINT16 next_csel;          /* The next chip select to use if in boot config mode, when the config is complete */
     UINT16 next_read_addr_msw; /* The next read address to use if in boot config mode */
     UINT16 next_read_addr_lsw; /* The next read address to use if in boot config mode */
} BOOT_PARAMS_SPI_T;

I've tried to load the first boot stage program on CCS and run just like I did for C6670, but it didn't read out SPI program data.

The boot parameter address is 0x008fff00 and reentry address is 0x20B00008.

Thanks a lot for your help

Best regards,

Henry

0 Michael Scherban over 9 years ago in reply to HRC

TI__Genius 12320 points

Hi Henry,

I will have to check on the romparse value. I haven't seen this utility used before so I'll see if I can find someone who knows.

Here is an example for the BOOT_PARAMS_SPI_T, which will read data off the spi at offset 0x1000 in the second stage.

#include "tiboot.h"

#define SYS_PLL_CONFIG					0x40290802
#define SEC_PLL_CONFIG					0x00000000
#define STAGE_2_BRANCH_ADDRESS			0x00001000

const BOOT_PARAMS_SPI_T params = {
	
	sizeof(BOOT_PARAMS_SPI_T),					/* length */
	0,											/* checksum */
	50,											/* boot_mode */
	0,											/* portNum (used to be 1) */
	(SYS_PLL_CONFIG >> 16) & 0xffff,			/* CPU PLL configuration, MSW */
	(SYS_PLL_CONFIG & 0xffff),     				/* CPU PLL configuration, LSW */
												
	(SEC_PLL_CONFIG >> 16) & 0xffff,			/* CPU PLL configuration, MSW  */
	(SEC_PLL_CONFIG & 0xffff),      			/* CPU PLL configuration, LSW  */
												
	0x04E2,										/* System clock frequency, MHz */ 
	0x04E2,										/* Core clock frequency, MHz   */ 
												
	1,											/* True if the core is the boot master */
													
	BOOT_PARAMS_SPI_OPTIONS_GPHDR,				/* Options */
												/*
												* SPI Specific Options
												* Bit 01-00: BT:                                      
												*            00 - Boot Parameter Mode                            
												*            01 - Boot Table Mode                     
												*            10 - Boot Config mode
												*            11 - GP header blob
												* Other bits:  Reserved 
												*/ 
	24,											/* 16 or 24 are the only valid values */
	0x0008,										/* 4 or 5 pins are the only valid values */
	0xFFFE,										/* only values 0b10 (cs0 low) or 0b01 (cs1 low) are valid 0xE = 1110 = CS0 (0xB = 1011 = CS2) */
	0,											/* Clock phase/polarity. These are the standard SPI modes 0-3 */
	1,											/* Setup time between chip select assert and the transaction */
													
	5,											/* The SPI bus frequency in units of 100 kHz */
											
	(STAGE_2_BRANCH_ADDRESS >> 16) & 0xffff,	/* The base address to read from the SPI, upper 16 bits */
	(STAGE_2_BRANCH_ADDRESS & 0xffff),      	/* The base address to read from the SPI, lower 16 bits */
											
	0x0000,										/* The next chip select to use if in boot config mode, when the config is complete */
	0x0000,										/* The next read address to use if in boot config mode */
	0x0000,										/* The next read address to use if in boot config mode */
             
};

This was pulled from an ARM program but I think it should be the same. I will be able to post these examples soon once they get updated.

Regards,

Mike

0 Michael Scherban over 9 years ago in reply to Michael Scherban

TI__Genius 12320 points

If you want to see the boot examples you can get them from this link: txn.box.com/.../1xzmg49h5lz15ct4ovy32lcsq2mbpbn5 They are all 2 stage ARM boot modes, however. But they can be used as a guide.

Regards,
Mike

0 HRC over 8 years ago in reply to Michael Scherban

Prodigy 150 points

Hi Mike,

Thanks a lot for your help.
Based on the material you provided, I can boot up DSP second stage boot process successfully, including loading u-boot for ARM Core.
But for the first stage boot process, it failed.
I think the romparse.exe tool for Keystone2 series need to be modified.
I'll try to modify the old C6670 romparse.exe.

It would be great if you can get the new romparse.exe for Keystone2 series and release for user.

Thanks again for the great support.

Regards,
Henry

0 HRC over 8 years ago in reply to Michael Scherban

Prodigy 150 points

Hi Mike,

I've modified romparse.exe based on the SPI parameter structure of tiboot.h that you provided.
Now I can do DSP master boot process for DSP and ARM u-boot.
Without your help, I wouldn't make this happen.
Thank you.

Best regards,
Henry

0 Michael Scherban over 8 years ago in reply to HRC

TI__Genius 12320 points

Hi Henry,

Sorry I couldn't get back to you yesterday. Glad to hear you were able to figure out and fix your issue.

The group I am in isn't the one that maintains romparse, so I am definitely happy you were able to resolve the issue yourself.

Regards,

Mike

0 HRC over 8 years ago in reply to Michael Scherban

Prodigy 150 points

Hi Mike,

I encountered another boot process problem of DDR3 memory map for ARM view and DSP view.
My situation is :
DSP Code segment allocation : Start from 0x80000000 and other DSP cores run in L2SRAM.
ARM Linux booted by uboot.

When u-boot excuted DDR3A initialization (I disabled DDR3B initial), DSP core0 will hang but ARM u-boot (linux) and other DSP cores running normally.
When I ignored DDR3A and DDR3B initial, ARM u-boot and DSP core0 are both hanged (crashed) but other DSP cores ran well.
I guess the problem should be that linux kernel was running from 0x80000000?
When I change DSP Code segment to start from 0x60000000, all DSP cores and ARM u-boot ran normally.
Does it mean that RBL of DSP is using SoC view to handle memory space? How so?
From data sheet, DSP view DDR3 is always DDR3B, am I right?
What can I do if I want to run DSP code on DDR3 from 0x80000000 and booted by DSP master boot?

Forgot to mention that DDR3_REMAP_EN pin is '1'. I'm using XTCIEVMK2X Rev3.0 board and all BMC boot mode set DDR3_REMAP_EN as '1'.
Unless the bootmode information in BMC is not reliable (bit 20 in BMC boot mode information : http://processors.wiki.ti.com/index.php/EVMK2H_Hardware_Setup#DIP_Switch_and_Bootmode_Configurations).

Thanks for your help.
Henry

0 HRC over 8 years ago in reply to Michael Scherban

Prodigy 150 points

Hi Mike,

I think I found out where the problem is. It's affected by MPAX remap settings.
I can modify the XMC remap settings to boot up at DDR3B memory space.
Here comes another problem that how can I set MPAX remap settings for other DSP cores ?
Each C66x CorePac has their own MPAX registers.
If I use Core0 to boot up other DSP cores that all run on DDR3B memory space, how can I set up each cores' MPAX remapping before activation?

Thanks for your support,
Henry

0 Michael Scherban over 8 years ago in reply to HRC

TI__Genius 12320 points

Hi Henry,

I think Linux will remap itself to execute from 0x80008000, and I believe the lower addresses even have some additional data the kernel uses. So it sounds like Linux is overwriting your DSP memory causing it to crash.

Then in your other scenario where you don't do the DDR initialization U-Boot will crash because it tries to relocate itself from MSMC to DDR. It might have some specific requirements that it sets up.

If you have enough memory, try linking your DSP application to run out of 0xa0000000 in DDR. This section is reserved for DSP usage. We restrict ARM to the first 512M of DDR by setting 'mem_reserve=1536M' in U-Boot. But this is a board specific setting and ours has 2GB of memory.

But this is why I had mentioned earlier the option of doing ARM master boot and load the DSPs from Linux. We typically don't do DSP master boots if we use Linux, so that path is untested.

Regards,

Mike

Processors

Processors forum

tiboot.h for K2H/K2K and RBL Entry Address