XIP_MUX0 boot problem

qiuxicj MESSN

Other Parts Discussed in Thread: CCSTUDIO

hello,all

In our project, we use nor flash to boot. According to the TRM chapter 4, We use the XIP_MUX0 pin group connected to the Nor flash chip. And we set the bootmode to 11010, and u-boot.bin is written in the correct palce in the nor flash(I am very sure about this). But when power is on, the console output is "CCCCCC......". I was new in the field, I am so confised. can any one help me?

The u-boot.bin I used is from EVM board. Do I have to changed the source file or anything else.

BR,

qiuxicj

over 11 years ago

0 Pavel Botev over 11 years ago

TI__Guru**** 170625 points

qiuxicj,

Are you on DM814x EVM or DM814x based custom board?

Are you on EZSDK 5.05.02.00 / PSP 04.04.00.01?

qiuxicj MESSN said:
But when power is on, the console output is "CCCCCC......".

The "11010" configuration order is:

1. XIP (MUX0) 2. UART 3. SPI 4. MMC

The "CCCCCC" output shows that the XIP (MUX0) is skipped (by some reason) and UART is selected!

Do you have wait monitoring configured for the XIP_MUX0 mode? If not, try with bootmode 11011.

Are you aligned with the Silicon errata advisory 3.0.33 XIP Boot: High-Order Address Handling (GPMC_A[27:13] Pins) ?

Have a look also in the DM814x datasheet, sections 3.2.1 Boot Configuration, 3.2.8 GPMC, 4.2 Boot Modes, 4.2.1 XIP (NOR) Boot Options

Regards,
Pavel

0 qiuxicj MESSN over 11 years ago in reply to Pavel Botev

Intellectual 760 points

hi, Pavel

1. I am in DM814x based custom board.

2. yes. I am on EZSDK 5.05.02.00 / PSP 04.04.00.01

3. I have been aligned with the Silicon errata advisory 3.0.33 XIP Boot: High-Order Address Handling (GPMC_A[27:13] Pins), DM814x datasheet, sections 3.2.1 Boot Configuration, 3.2.8 GPMC, 4.2 Boot Modes, 4.2.1 XIP (NOR) Boot Option.

In my design, The FPGA mux use GPMC_A[1....26], GPMC_NOE, GPMC_D[0...15] with Nor Flash.

And I have use tht chipscope to catch the GPMC_A[1....26], GPMC_NOE, GPMC_D[0...15].

When the GPMC_A[1....26], GPMC_NOE,GPMC_CS0 is active,the GPMC_D[0...15] pin ouput 0xFFFF constantly.

On the other side, when boot on SD card, I can read out nor flash data correctly use my our nor flash driver.

I am so confused.

BR,

qiuxicj

0 qiuxicj MESSN over 11 years ago in reply to Pavel Botev

Intellectual 760 points

hello, Pavel

according to DM814x datasheet 4.2 Boot Modes, GPMC_A[1:12] pulling state is IPD. Do I need to use external pulling resistors to pulling them down?

0 qiuxicj MESSN over 11 years ago in reply to Pavel Botev

Intellectual 760 points

hello, Pavel

according to DM814x datasheet 4.2 Boot Modes, GPMC_A[1:12] pulling state is IPD. Do I need to use external pulling resistors to pulling them down?

BR,

qiuxicj

0 Pavel Botev over 11 years ago in reply to qiuxicj MESSN

TI__Guru**** 170625 points

Qiuxicj,

Please see the below wiki page:

http://processors.wiki.ti.com/index.php/AM387x_/_C6A814x_Schematic_Review_Checklist

2. XIP boot GPMC High order address bit handling –

As described in section 4.7.2.2 of the DM814x TRM, the ROM code does not multiplex high order address lines gpmc_a[27:13] to their address functions, although the external memory device generally needs to see logic "0" on its higher order address bits to correctly address memory. Many of the high order address pads default to internal pull-down active; however, some pins will default to internal pull-up active and therefore will need to be driven or pulled low by external hardware for the duration of XIP boot operation. See the device data manual for specific details.

Then are two approaches to successfully perform XIP boot

a. Add external pull down resistors on GPMC lines which default to pullup so that the high order address lines will be logical 0 during ROM execution

b. Add an external mux on XIP memory address lines to force 0 state on high order address lines during ROM execution. Note that user code would need to control this mux in user code (via gpio control) before accessing GPMC address above 4KB. In both cases above the user code needs to re-mux the high order address lines appropriately within the first 4KB of execution (in code space where high order bits are supposed to be zero)

Regards,
Pavel

0 qiuxicj MESSN over 11 years ago in reply to Pavel Botev

Intellectual 760 points

hello pavel,

I use the approaches b, then the ti8148 can read data from Nor flash. The u-boot.bin is 0x270BC bytes. according to the chipscope, when booting on nor flash, the code can execute until addr 0x270BC, but console output only "CCCCCC", what is the problem? Is the UART configuration erro?

0 Pavel Botev over 11 years ago in reply to qiuxicj MESSN

TI__Guru**** 170625 points

Qiuxicj,

Yes, it might be UART console problem. Are you using UART0 for console (as in EVM) or other UART instance is used for console in your custom board?

Best regards,
Pavel

0 Pavel Botev over 11 years ago in reply to Pavel Botev

TI__Guru**** 170625 points

Qiuxicj,

Do you have correct console output (not just CCCCC) when booting from other source, different from the NOR/XIP_MODE0 ?

Best regards,
Pavel

0 qiuxicj MESSN over 11 years ago in reply to Pavel Botev

Intellectual 760 points

hello , Pavel

In the costomer board, when booting from SD, the console output is correct.

In the EVM board, when booting from NOR/XIP_MUX1, the console output is also correct.

Best Regards,

qiuxicj

0 Pavel Botev over 11 years ago

TI__Guru**** 170625 points

Qiuxicj,

Then the UART/console seems to be fine.

qiuxicj MESSN said:
We use the XIP_MUX0 pin group connected to the Nor flash chip.

Have you enable/select these pins in the PINCNTLx MUXMODE bits?

qiuxicj MESSN said:
The u-boot.bin I used is from EVM board.

Have you build the u-boot.bin with the ti8148_evm_config_nor config?

Are you aligned with the below user guide?

http://processors.wiki.ti.com/index.php/TI81XX_PSP_NOR_Driver_Guide

Best regards,
Pavel

0 Pavel Botev over 11 years ago in reply to Pavel Botev

TI__Guru**** 170625 points

Refer also to the below e2e threads which seems to be relevant:

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/172508.aspx

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/t/165279.aspx

Regards,
Pavel

0 qiuxicj MESSN over 11 years ago in reply to Pavel Botev

Intellectual 760 points

hello , Pavel

Pavel Botev said:

Have you enable/select these pins in the PINCNTLx MUXMODE bits?

since the evm nor flash is 64MB, my costomer board nor flash is 128MB, I add GPMC_A26, and since the costomer board use nor/XIP_MUX0,before I build the u-boot.bin I changed the pinmux setting in the following files:

1 lowlevel_init.S

#define GPMC_A12_MUX_VAL MODE(5)
#define GPMC_A13_MUX_VAL (MODE(2) | PULL_UP_EN)
#define GPMC_A14_MUX_VAL (MODE(2) | PULL_UP_EN)
#define GPMC_A15_MUX_VAL MODE(2)
#define GPMC_A16_MUX_VAL MODE(1)
#define GPMC_A17_MUX_VAL MODE(1)
#define GPMC_A18_MUX_VAL MODE(1)
#define GPMC_A19_MUX_VAL MODE(1)
#define GPMC_A20_MUX_VAL (MODE(1) | PULL_UP_EN)
#define GPMC_A21_MUX_VAL MODE(1)
#define GPMC_A22_MUX_VAL (MODE(1) | PULL_UP_EN)
#define GPMC_A23_MUX_VAL MODE(1)
#define GPMC_A24_MUX_VAL (MODE(2)| PULL_UP_EN)
#define GPMC_A25_MUX_VAL MODE(2)
#define GPMC_A27_MUX_VAL (MODE(8)| PULL_UP_EN)

changed to

#define GPMC_A12_MUX_VAL MODE(5)
#define GPMC_A13_MUX_VAL (MODE(5) | PULL_UP_EN)
#define GPMC_A14_MUX_VAL (MODE(5) | PULL_UP_EN)
#define GPMC_A15_MUX_VAL MODE(5)
#define GPMC_A16_MUX_VAL MODE(1)
#define GPMC_A17_MUX_VAL MODE(1)
#define GPMC_A18_MUX_VAL MODE(1)
#define GPMC_A19_MUX_VAL MODE(1)
#define GPMC_A20_MUX_VAL (MODE(1) | PULL_UP_EN)
#define GPMC_A21_MUX_VAL MODE(1)
#define GPMC_A22_MUX_VAL (MODE(1) | PULL_UP_EN)
#define GPMC_A23_MUX_VAL MODE(1)
#define GPMC_A24_MUX_VAL (MODE(2)| PULL_UP_EN)
#define GPMC_A25_MUX_VAL MODE(2)
#define GPMC_A26_MUX_VAL MODE(2)
#define GPMC_A27_MUX_VAL (MODE(8)| PULL_UP_EN)

add

....

gpmc_a25_addr:
.word GPMC_A25
gpmc_a26_addr: //add
.word GPMC_A26 // add
gpmc_a27_addr:
.word GPMC_A27

......

gpmc_a25_mux_val:
.word GPMC_A25_MUX_VAL
gpmc_a26_mux_val: //add
.word GPMC_A26_MUX_VAL //add
gpmc_a27_mux_val:
.word GPMC_A27_MUX_VAL

......

ezsdk_5_05\board-support\u-boot-2010.06-psp04.04.00.01\arch\arm\include\asm\arch-ti81xx\Cpu.h

#define GPMC_A1   (CTRL_BASE + 0x09D0)
#define GPMC_A2   (CTRL_BASE + 0x09D4)
#define GPMC_A3   (CTRL_BASE + 0x09D8)
#define GPMC_A4   (CTRL_BASE + 0x09DC)
#define GPMC_A5   (CTRL_BASE + 0x0A9C)
#define GPMC_A6   (CTRL_BASE + 0x0AA0)
#define GPMC_A7   (CTRL_BASE + 0x0AA4)
#define GPMC_A8   (CTRL_BASE + 0x0AA8)
#define GPMC_A9   (CTRL_BASE + 0x0AAC)
#define GPMC_A10  (CTRL_BASE + 0x0AB0)
#define GPMC_A11  (CTRL_BASE + 0x0AB4)
#define GPMC_A12  (CTRL_BASE + 0x0AB8)
#define GPMC_A12  (CTRL_BASE + 0x0AB8)
#define GPMC_A13  (CTRL_BASE + 0x0B8C)
#define GPMC_A14  (CTRL_BASE + 0x0B90)
#define GPMC_A15  (CTRL_BASE + 0x0B94)
#define GPMC_A16  (CTRL_BASE + 0x09A0)
#define GPMC_A17  (CTRL_BASE + 0x09A4)
#define GPMC_A18  (CTRL_BASE + 0x09A8)
#define GPMC_A19  (CTRL_BASE + 0x09AC)
#define GPMC_A20  (CTRL_BASE + 0x09B0)
#define GPMC_A21  (CTRL_BASE + 0x09B4)
#define GPMC_A22  (CTRL_BASE + 0x09B8)
#define GPMC_A23  (CTRL_BASE + 0x09BC)
#define GPMC_A24  (CTRL_BASE + 0x09EC)
#define GPMC_A25  (CTRL_BASE + 0x09E8)
#define GPMC_A27  (CTRL_BASE + 0x09CC)
#define GPMC_CS0_REG  (CTRL_BASE + 0x09E4)
#define GPMC_OEN  (CTRL_BASE + 0x0A00)
#define GPMC_WEN  (CTRL_BASE + 0x0A04)

changed to

#define GPMC_A1   (CTRL_BASE + 0x0BCC)
#define GPMC_A2   (CTRL_BASE + 0x0BD0)
#define GPMC_A3   (CTRL_BASE + 0x0BD4)
#define GPMC_A4   (CTRL_BASE + 0x0BD8)
#define GPMC_A5   (CTRL_BASE + 0x0BDC)
#define GPMC_A6   (CTRL_BASE + 0x0BE0)
#define GPMC_A7   (CTRL_BASE + 0x0BE4)
#define GPMC_A8   (CTRL_BASE + 0x0BE8)
#define GPMC_A9   (CTRL_BASE + 0x0BEC)
#define GPMC_A10  (CTRL_BASE + 0x0BF0)
#define GPMC_A11  (CTRL_BASE + 0x0BF4)
#define GPMC_A12  (CTRL_BASE + 0x0BF8)

#define GPMC_A13  (CTRL_BASE + 0x0BFC)
#define GPMC_A14  (CTRL_BASE + 0x0C00)
#define GPMC_A15  (CTRL_BASE + 0x0C04)
#define GPMC_A16  (CTRL_BASE + 0x09A0)
#define GPMC_A17  (CTRL_BASE + 0x09A4)
#define GPMC_A18  (CTRL_BASE + 0x09A8)
#define GPMC_A19  (CTRL_BASE + 0x09AC)
#define GPMC_A20  (CTRL_BASE + 0x09B0)
#define GPMC_A21  (CTRL_BASE + 0x09B4)
#define GPMC_A22  (CTRL_BASE + 0x09B8)
#define GPMC_A23  (CTRL_BASE + 0x09BC)
#define GPMC_A24  (CTRL_BASE + 0x09C0)
#define GPMC_A25  (CTRL_BASE + 0x09C4)
#define GPMC_A26  (CTRL_BASE + 0x09C8)
#define GPMC_A27  (CTRL_BASE + 0x09CC)
#define GPMC_CS0_REG  (CTRL_BASE + 0x09E4)
#define GPMC_OEN  (CTRL_BASE + 0x0A00)
#define GPMC_WEN  (CTRL_BASE + 0x0A04)

\ezsdk_5_05\board-support\u-boot-2010.06-psp04.04.00.01\board\ti\ti8148\Evm.c

static struct nor_pad_config nor_pad_cfg[] = {
...
  {GPMC_A1, MODE(2) | PULL_UP_EN},
  {GPMC_A2, MODE(2) | PULL_UP_EN},
  {GPMC_A3, MODE(2) | PULL_UP_EN},
  {GPMC_A4, MODE(2) | PULL_UP_EN},
  {GPMC_A5, MODE(5) | PULL_UP_EN},
  {GPMC_A6, MODE(5)},
  {GPMC_A7, MODE(5)},
  {GPMC_A8, MODE(5)},
  {GPMC_A9, MODE(5)},
  {GPMC_A10, MODE(5) | PULL_UP_EN},
  {GPMC_A11, MODE(5)},
  {GPMC_A12, MODE(5)},
  {GPMC_A13, MODE(2) | PULL_UP_EN},
  {GPMC_A14, MODE(2) | PULL_UP_EN},
  {GPMC_A15, MODE(2)},
  {GPMC_A16, MODE(1)},
  {GPMC_A17, MODE(1)},
  {GPMC_A18, MODE(1)},
  {GPMC_A19, MODE(1)},
  {GPMC_A20, MODE(1) | PULL_UP_EN},
  {GPMC_A21, MODE(1)},
  {GPMC_A22, MODE(1) | PULL_UP_EN},
  {GPMC_A23, MODE(1)},
  {GPMC_A24, MODE(2) | PULL_UP_EN},
  {GPMC_A25, MODE(2)},
  {GPMC_A27, MODE(8) | PULL_UP_EN},
...
}

changed to

static struct nor_pad_config nor_pad_cfg[] = {
...
  {GPMC_A1, MODE(5) | PULL_UP_EN},
  {GPMC_A2, MODE(5) | PULL_UP_EN},
  {GPMC_A3, MODE(5) | PULL_UP_EN},
  {GPMC_A4, MODE(5) | PULL_UP_EN},
  {GPMC_A5, MODE(5) | PULL_UP_EN},
  {GPMC_A6, MODE(5) | PULL_UP_EN},
  {GPMC_A7, MODE(5) | PULL_UP_EN},
  {GPMC_A8, MODE(5) | PULL_UP_EN},
  {GPMC_A9, MODE(5) | PULL_UP_EN},
  {GPMC_A10, MODE(5) | PULL_UP_EN},
  {GPMC_A11, MODE(5) | PULL_UP_EN},
  {GPMC_A12, MODE(5) | PULL_UP_EN},
  {GPMC_A13, MODE(5) | PULL_UP_EN},
  {GPMC_A14, MODE(5) | PULL_UP_EN},
  {GPMC_A15, MODE(5) | PULL_UP_EN},
  {GPMC_A16, MODE(1) | PULL_UP_EN},
  {GPMC_A17, MODE(1) | PULL_UP_EN},
  {GPMC_A18, MODE(1) | PULL_UP_EN},
  {GPMC_A19, MODE(1) | PULL_UP_EN},
  {GPMC_A20, MODE(1) | PULL_UP_EN},
  {GPMC_A21, MODE(1) | PULL_UP_EN},
  {GPMC_A22, MODE(1) | PULL_UP_EN},
  {GPMC_A23, MODE(1) | PULL_UP_EN},
  {GPMC_A24, MODE(2) | PULL_UP_EN},
  {GPMC_A25, MODE(2) | PULL_UP_EN},
  {GPMC_A26, MODE(2) | PULL_UP_EN},
  {GPMC_A27, MODE(8) | PULL_UP_EN},
...
}

Am I right. any other changes to be add in the u-boot source code?

Pavel Botev said:

Have you build the u-boot.bin with the ti8148_evm_config_nor config?

yes

Pavel Botev said:

Are you aligned with the below user guide?

http://processors.wiki.ti.com/index.php/TI81XX_PSP_NOR_Driver_Guide

yes.

Best Regards,

Pavel

0 Pavel Botev over 11 years ago in reply to qiuxicj MESSN

TI__Guru**** 170625 points

Qiuxicj,

Let me confirm your steps for building the u-boot.bin file, are they as below?

1. $ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm distclean

2. $ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm ti8148_evm_config_nor

3. Modify the u-boot source code

4. $ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm u-boot.ti

Regards,
Pavel

0 Pavel Botev over 11 years ago in reply to qiuxicj MESSN

TI__Guru**** 170625 points

qiuxicj MESSN said:
Am I right. any other changes to be add in the u-boot source code?

Also I do not see this step:

http://processors.wiki.ti.com/index.php/DM814x_AM387x_PSP_U-Boot#NOR_Support

In case of NOR boot and XIP, we cannot initialize GPMC while running from NOR, hence we have to relocate the tiny GPMC init code to SRAM and then transfer control to SRAM and then come back to NOR XIP.
Also, the relocatable GPMC init code should be placed in the first 4KBytes of the u-boot. This is achieved by adding lowlevel_init.o just below start.o in the u-boot linker script board/ti8148_evm/u-boot.lds as shown below.

SECTIONS
{
    . = 0x00000000;
    . = ALIGN(4);
    .text   :
    {
      arch/arm/cpu/arm_cortexa8/start.o  (.text)
      arch/arm/cpu/arm_cortexa8/ti81xx/lowlevel_init.o   (.text)
      *(.text)
    }
...
...
...

#define NOR_SECT_SIZE               (128 * 1024)

These macros assume spansion flash being used in the EVM. For any other flash part, the sector size macro 
(NOR_SECT_SIZE) has to be modified.

Regards,

Pavel

0 qiuxicj MESSN over 11 years ago in reply to Pavel Botev

Intellectual 760 points

Pavel Botev said:

Let me confirm your steps for building the u-boot.bin file, are they as below?

1. $ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm distclean

2. $ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm ti8148_evm_config_nor

3. Modify the u-boot source code

4. $ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm u-boot.ti

my step is

1. Modify the u-boot source code

2. $ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm distclean

3. $ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm ti8148_evm_config_nor

4. $ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm u-boot.ti

does it matter?

0 Pavel Botev over 11 years ago in reply to qiuxicj MESSN

TI__Guru**** 170625 points

qiuxicj MESSN said:

my step is

1. Modify the u-boot source code

2. $ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm distclean

3. $ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm ti8148_evm_config_nor

4. $ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm u-boot.ti

does it matter?

Should also work fine.

Best regards,
Pavel

0 qiuxicj MESSN over 11 years ago in reply to Pavel Botev

Intellectual 760 points

hello, Pavel

Pavel Botev said:
In case of NOR boot and XIP, we cannot initialize GPMC while running from NOR, hence we have to relocate the tiny GPMC init code to SRAM and then transfer control to SRAM and then come back to NOR XIP.

Also, the relocatable GPMC init code should be placed in the first 4KBytes of the u-boot. This is achieved by adding lowlevel_init.o just below start.o in the u-boot linker script board/ti8148_evm/u-boot.lds as shown below.
SECTIONS
{
    . = 0x00000000;
    . = ALIGN(4);
    .text   :
    {
      arch/arm/cpu/arm_cortexa8/start.o  (.text)
      arch/arm/cpu/arm_cortexa8/ti81xx/lowlevel_init.o   (.text)
      *(.text)
    }

I have check this file. It is right.

Pavel Botev said:
#define NOR_SECT_SIZE (128 * 1024)

These macros assume spansion flash being used in the EVM. For any other flash part, the sector size macro
(NOR_SECT_SIZE) has to be modified.

the NOR_SECT_SIZE of my NOR flash is the same as EVM.

difference is EVM flash :64MB cos flash :128MB

is there any other macros that needs to be modified?

Best Regards,

qiuxicj

0 qiuxicj MESSN over 11 years ago in reply to Pavel Botev

Intellectual 760 points

hello, Pavel

what is the effect by doing

Pavel Botev said:

3. $ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm ti8148_evm_config_nor

Do any configuration need to changed for XIP_MUX0?

Best Regards,

qiuxicj

0 Pavel Botev over 11 years ago in reply to qiuxicj MESSN

TI__Guru**** 170625 points

Qiuxicj,

qiuxicj MESSN said:

what is the effect by doing

3. $ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm ti8148_evm_config_nor

[/quote]

The ti8148_evm_config_nor enables the CONFIG_NOR and CONFIG_NOR_BOOT defines in the u-boot source code.

You already provide your BTMODE[4:0] 11010, but what is the value of BTMODE[10] pin, BTMODE[14:13] pin, BTMODE[15], BTMODE[12] pin?

Best regards,
Pavel

0 qiuxicj MESSN over 11 years ago in reply to Pavel Botev

Intellectual 760 points

hello, Pavel

the setting is : BTMODE[10] = 0; BTMODE[14:13] = 00 ; BTMODE[15] = 0; BTMODE[12] = 1;

Best Regards,

qiuxicj

0 Pavel Botev over 11 years ago in reply to qiuxicj MESSN

TI__Guru**** 170625 points

Try looking at the tracing vector that the ROM code provides. The TRM gives the address and the bit field definitions for the tracing vector.

Tracing vectors give you some indication what the ROM code executed in its attempt to boot. This can help you determine how far the ROM got before failing to boot, and can give you some idea as to why it failed.

Best regards,
Pavel

0 Pavel Botev over 11 years ago in reply to Pavel Botev

TI__Guru**** 170625 points

A feedback from the ROM Code team:

The most probable cause for this issue is that the pull ups n the board are not correct – while flashing the u-boot, the pin mux configuration is done by the flashwriter and that allows the NOR to be accessed properly. For eg, if A22 is left unconnected, then it could be floating, but then as the ROM does not configure all the address pins, when the ROM tries to read from 0x0 of NOR, the NOR might actually think some other address is being accessed and return the value from there.

The easy way to check is to fill the entire nor with 128 different values then the ROM will definitely find an image and boot from that. It will fail, but it will give an idea of what address the ROM is actually accessing when it is trying to read from the beginning of NOR flash.

0 qiuxicj MESSN over 11 years ago in reply to Pavel Botev

Intellectual 760 points

hello, Pavel

Pavel Botev said:
Try looking at the tracing vector that the ROM code provides. The TRM gives the address and the bit field definitions for the tracing vector

I am new in this field, How to read the tracing vector?

Best Regards,

qiuxicj

0 qiuxicj MESSN over 11 years ago in reply to Pavel Botev

Intellectual 760 points

hello, Pavel

qiuxicj said:

\ezsdk_5_05\board-support\u-boot-2010.06-psp04.04.00.01\board\ti\ti8148\Evm.c

static struct nor_pad_config nor_pad_cfg[] = {
...
  {GPMC_A1, MODE(2) | PULL_UP_EN},
  {GPMC_A2, MODE(2) | PULL_UP_EN},
  {GPMC_A3, MODE(2) | PULL_UP_EN},
  {GPMC_A4, MODE(2) | PULL_UP_EN},
  {GPMC_A5, MODE(5) | PULL_UP_EN},
  {GPMC_A6, MODE(5)},
  {GPMC_A7, MODE(5)},
  {GPMC_A8, MODE(5)},
  {GPMC_A9, MODE(5)},
  {GPMC_A10, MODE(5) | PULL_UP_EN},
  {GPMC_A11, MODE(5)},
  {GPMC_A12, MODE(5)},
  {GPMC_A13, MODE(2) | PULL_UP_EN},
  {GPMC_A14, MODE(2) | PULL_UP_EN},
  {GPMC_A15, MODE(2)},
  {GPMC_A16, MODE(1)},
  {GPMC_A17, MODE(1)},
  {GPMC_A18, MODE(1)},
  {GPMC_A19, MODE(1)},
  {GPMC_A20, MODE(1) | PULL_UP_EN},
  {GPMC_A21, MODE(1)},
  {GPMC_A22, MODE(1) | PULL_UP_EN},
  {GPMC_A23, MODE(1)},
  {GPMC_A24, MODE(2) | PULL_UP_EN},
  {GPMC_A25, MODE(2)},
  {GPMC_A27, MODE(8) | PULL_UP_EN},
...
}

What does "PULL_UP_EN" mean?

Best Regards,

qiuxicj

0 qiuxicj MESSN over 11 years ago in reply to Pavel Botev

Intellectual 760 points

hello, Pavel

By the way, What does printing "CCCCCC" mean?

Best Regards,

qiuxicj

0 Pavel Botev over 11 years ago in reply to qiuxicj MESSN

TI__Guru**** 170625 points

qiuxicj MESSN said:
I am new in this field, How to read the tracing vector?

You should use CCStudio and JTAG.

Best regards,
Pavel

0 Pavel Botev over 11 years ago in reply to qiuxicj MESSN

TI__Guru**** 170625 points

qiuxicj MESSN said:
What does "PULL_UP_EN" mean?

PULL_UP_EN means that you have selected internal pull up to the corresponding pin.

This is the code:

u-boot-2010.06-psp04.04.00.01/arch/arm/include/asm/arch-ti81xx/cpu.h:

#define PULL_UP_EN (0x1 << 17)

This value apply to bit PINCNTLx[17] PLLTYPSEL = 0x1 (pull up selected). See DM814x datasheet, Table 4-11. PINCNTL1 – PINCNTL270 (PINCNTLx) Registers Bit Descriptions.

Regards,
Pavel

0 Pavel Botev over 11 years ago in reply to qiuxicj MESSN

TI__Guru**** 170625 points

qiuxicj MESSN said:
What does printing "CCCCCC" mean?

The "11010" configuration order is:

1. XIP (MUX0) 2. UART 3. SPI 4. MMC

The "CCCCCC" output shows that the XIP (MUX0) is skipped (by some reason) and UART is selected! The board is trying to boot from UART.

Regards,
Pavel

Processors

Processors forum

XIP_MUX0 boot problem