TMS320DM8168: NAND Boot Failure when GPMC bus is shared with FPGA

Hi Khader,

Please compare the below settings between working case (standalone mode) and non-working case (FPGA mode):

- sysboot pins settings
- GPMC pins settings
- GPMC registers settings

Check if there is any difference between two cases and if there is difference please post it here for analysis.

Regards,
Pavel

Hi Pavel,

Thanks for replying. Here are the observations:

1. SYSBOOT PIN Settings are same.
2. GPMC PIN Settings are same. (Hardware wise since all the signals are tri-stated in FPGA)
3. The CONTROL_STATUS & BOOTSTAT register values are same. Whereas there are following differences in the GPMC register settings.

Reg address Reg Name working case (standalone mode) non-working case (with FPGA board)
0x50000060 CONFIG1 0x1810 0x401810
0x50000078 CONFIG7 0x48 0x00000F48
0x50000010 GPMC_SYSCONFIG 0x8 0x0
0x50000050 GPMC_CONFIG 0x12 0xA00

---Differences in RBL Tracing vector registers
0x4031D040 Current tracing vector, word 1 0x9E 0x907F
0x4031D044 Current tracing vector, word 2 0x18000 0xF000
0x4031D048 Current tracing vector, word 3 0x20 0x10420

Let me know your suggestions in resolving this.

Regards,
Shareef

Khader Shareef said:

---Differences in RBL Tracing vector registers
0x4031D040 Current tracing vector, word 1 0x9E 0x907F

This shows that image header is not found (bit 7 is 0 in non-working case). NAND Memory Booting: Image must begin with a header that contains information on image size and destination address. When the booting memory device is NAND, the image must contain a small header with the size of the software to load and the destination address where to store it.

Khader Shareef said:

0x50000010 GPMC_SYSCONFIG 0x8 0x0

In non-working case GPMC is set in force idle mode, thus GPMC might be in idle mode thus not able to operate. Can you check why GPMC_SYSCONFIG[4:3] SIDLEMODE is 0 ? Try with SIDLEMODE set to 1

Khader Shareef said:

0x50000060 CONFIG1 0x1810 0x401810

In non-working mode, [22] WAITREADMONITORING is 0x1. Do you have any difference in the wait pin configuration? Note that NAND ROM Code needs Wait pin signal WAITPIN0 connected to NAND BUSY output.

NAND ROM Code need also:

- 55 MHz GPMC clock
- Device connected to CS0
- GPMC timings adjusted for NAND access, for details see TRM section Figure 25-11. GPMC NAND Timings and Table 25-10. NAND Timings Parameters

The GPMC address bus is released since a NAND device does not use it. The ROM Code first performs an initial wait for device auto initialization (with 250 ms timeout) with polling of the ready information. Then, it needs to identify the NAND type connected to the GPMC interface.


General recommendation is to try with the GPMC registers settings from the working case.

You can also test if FPGA somehow damage the image written in NAND. Try first to boot in standalone, then FPGA mode (here boot fails), then again in standalone (without writing new image in NAND).

Regards,
Pavel

Hi Pavel,

Please see my reply below for above questions in the same order.

1. The NAND Image is the same and it is not being changed when the board is tested standalone and with FPGA board.

2. I tried to set this GPMC_SYSCONFIG register from CCS, SIDLEMODE set to 0x8 and then execute RBL by setting PC to 0x20000. But still there is no luck.

3. WAIT pin is connected only between the NAND and DM816x processor as we have also tried removing the buffer between FPGA's busy output which was being AND-ed with the NAND's busy output.

4. For the last point, we have tried to remove the DM816x board after testing with FPGA board and it boots fine, this implies that the NAND image is perfect even after connecting and removing from the FPGA board.

We have added logic analyzer IP in FPGA and see that NAND read is beginning and passing till the "Extract NAND Parameters From Device Parameters Page" in Figure Figure 25-12 of the sprugx8c TRM document. 

We cannot change the GPMC config registers since RBL configures them and then accordingly boots from NAND.

Does RBL have dependecy on any of the signals apart from the SYSBOOT pins ?

Can you please tell us as to what can cause the GPMC to go to idle state and NAND boot to fail in this case?

Regards,

Shareef

Shareef,

Khader Shareef said:

1. The NAND Image is the same and it is not being changed when the board is tested standalone and with FPGA board.

Khader Shareef said:

We cannot change the GPMC config registers since RBL configures them and then accordingly boots from NAND.

So you are using the same software (u-boot.noxip.bin) for both cases (standalone and FPGA), correct? If yes, then this should be hardware issue.

Khader Shareef said:

Does RBL have dependecy on any of the signals apart from the SYSBOOT pins ?

Yes, see TRM section 25.7.3.2 Pins Used. Besides sysboot pins BTMODE[4:0], you might also compare the rest of the boot pins: CS0BW, CS0MUX[0], CS0MUX[1] and CS0WAIT, see datasheet 4.2.1 Boot Configuration

Khader Shareef said:

Can you please tell us as to what can cause the GPMC to go to idle state and NAND boot to fail in this case?

We are not sure if GPMC module enter idle state. Can you check register CM_ALWON_GPMC_CLKCTRL in both cases. What value you have there?

See also the below wiki:

Regards,
Pavel

Hi Pavel,

1. Yes, we feel this to be HW related issue since the software does not change on the NAND.

2. We have checked and all the pins have their default values unchanged GPMC_Address [16:1] are 0x912.

3. The value of the control register CM_ALWON_GPMC_CLKCTRL is 0x2 in both working and non-working cases.

Also some more observations are that RBL is performing the following actions successfully:

1. Reading Device ONFI signature.

2. Reading 101 bytes of NAND parameter page.

3. Giving an address of 00, 04, 00, 00, 00, 00 (C1, C2, R1, R2, R3) followed by read page command 30h. After this, we don't see any data transfers happening. We are not sure about the reason for the same? Do you have any thoughts?

Regards,

Khader