S34ML01G1 -> NAND device not detecting in uboot & kernel?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hi Guys,

   

We using S34ML01G100T1000 in our custom TI DM385 board. we using IPNC RDK3.8(kernel -> http://arago-project.org/git/projects/?p=linux-ipnc-rdk-dm81xx.git;a=summary) & (uboot -> http://arago-project.org/git/projects/?p=u-boot-ipnc-rdk-dm81xx.git;a=summary) with kernel 2.6.37, i have checked support of dev_id & maf_id in nand_id.c file which is their but still, when i try to print maf_id & dev_id i'm getting 0x17 & 0x17. and i'm getting No NAND device found in uboot as well as kernel. does anyone knows what is the issue.

   

 

   

thanks & regards,

   

Ganesh

0 Likes
20 Replies
BacemD_61
Employee
Employee
50 replies posted 50 sign-ins 25 replies posted

Hi Ganesh,

   

Sorry for our late response!

   

I think there must be something wrong with your board driver that configures the NAND controller and the NAND timings as well.

   

As you mentioned, the corresponding device ID is liste in "nand_ids.c". Please also make sure to enable the NAND drivers in both u-boot and Linux.

   

You could enable debugging in the NAND module "nand_base.c" by adding the following define:

   

#define debug printf

   

This will provide more details about the failure and we can then get a better understanding of what's going wrong.

   

Best regards,

   

Bacem Daassi

   

Cypress Applications Engineering

0 Likes
Anonymous
Not applicable

Hi Bacem Daassi,

   

i have already added in many printf for debugging purpose, even i have added the line as you ask for it. but in my nand_base.c file no where it is using debug for printing. Daassi, My priority right now is to detect nand in uboot.

   

In u-boot, BOOTMODE[0]-BOOTMODE[4] -> determines NAND/SD Boot.

   

0x17 means SD Boot, 0x13 means NAND Boot.

   

As NAND flash is interface using GPMC, initial GPMC I/O lines are muxed with BOOTMODE lines.

   

So, BOOTMODE[2] decide NAND/SD Boot. If BTMODE[2] is connected to high it SD boot and connected to GND means NAND boot.

   

when i remove BTMODE[2] jumper i'm reading 0x13 value.

   

So, In short I'm not reading GPMC Data lines rather i'm reading BTMODE pins value.

   

We have one more board with x16 bit NAND, it got detected with same uboot which we are using for board with spansion nand flash. we checked CS0 line which connected to GND.

   

So can you tell what could be the reason for reading BTMODE values instead of GPMC datalines.

   

 

   

regards,

   

Ganesh

0 Likes
BacemD_61
Employee
Employee
50 replies posted 50 sign-ins 25 replies posted

Hi Ganesh,

   

Would it possible for you to attach a logic analyzer to the flash signals to see whether the commands that are received by the NAND flash are correct or not? That way we can also check the used timings.

   

I read through the TI DM385 reference manual but couldn't find any hint about the error you were having.

   

Could you check the GPMC registers for correctness, e.g: GPMC_CONFIG1_i (DEVICETYPE, DEVICESIZE...)?

   

Please also double check the TI DM385 board driver in u-boot. There might something missing for treating x8 NAND flashes since you're saying that you have another 16-bit part that's working fine for you. The Cypress NAND flash you're using here is a x8 part.

   

Are you able to boot from both SD and NAND device? You might be running two different images in this case.

   

Best regards,

   

Bacem Daassi

   

Cypress Applications Engineering

0 Likes
Anonymous
Not applicable

Hi Daassi,

   

Actually we don't have logic analyzer,

   

from uboot shell, GPMC_CONFIG Device type & size is correct,

   

GPMC_CONFIG1 -> 0x00000800

   

CONTROL_STATUS -> 0x00000317.

   

TI DM385 uses generic nand driver, I'm booting from SD card.

   

 

   

regards,

   

Ganesh

0 Likes
BacemD_61
Employee
Employee
50 replies posted 50 sign-ins 25 replies posted

Hi Ganesh,

   

I was referring to the board driver and not to the NAND chip driver. The board driver is the one that sets up the timings and GPMC config.

   

Please double check all the GPMC registers as well.

   

Is the nand scan function in u-boot matching one of the device ID to the read device ID or is it exiting without finding any match?

   

We need more logs here to see what happens. A LA would have been the best option.

   

Best regards,

   

Bacem

0 Likes
Anonymous
Not applicable

Hi Daassi,

   

Even i have checked timing values in GPMC_CONFIG register, it looks fine

   

arch/arm/include/asm/arch-ti81xx/mem.h

   

#define M_NAND_GPMC_CONFIG1    0x00000800     
#define M_NAND_GPMC_CONFIG2     0x00060600     
#define M_NAND_GPMC_CONFIG3     0x00060F01     
#define M_NAND_GPMC_CONFIG4     0x04010401     

   

#define M_NAND_GPMC_CONFIG5     0x00040506    
#define M_NAND_GPMC_CONFIG6     0x04000580     
#define M_NAND_GPMC_CONFIG7     0x00000008

   

arch/arm/cpu/arm_cortexa8/ti81xx/mem.c

   

in above file, GPMC_CONFIG register are set with certain delay. you can check here

   

http://arago-project.org/git/projects/?p=u-boot-ipnc-rdk-dm81xx.git;a=blob;f=arch/arm/cpu/arm_cortex...

   
    

Is the nand scan function in u-boot matching one of the device ID to the read device ID or is it exiting without finding any match?

   
   

yes it is exiting because it is unable to match device id.

   

U-Boot 2010.06 (Nov 24 2016 - 09:38:50) DM385_CARDVR_3.50.00
DM385-GP rev 1.1
ARM clk: 720MHz
DDR clk: 533MHz
L3 clk: 200MHz
IVA clk: 290MHz
ISS clk: 400MHz
DSP Default OFF
DSS Default OFF
DRAM:  1 GiB
MMC:   : 0, ON-BOARD SDIO: 1
Using default environment

   

The 2nd stage U-Boot will now be auto-loaded
Please do not interrupt the countdown till DM385_IPNC prompt if 2nd stage is already flashed

   

reading u-boot.bin

   

206480 bytes read
## Starting application at 0x80800000 ...
U-Boot 2010.06 (Nov 24 2016 - 09:40:16) DM385_CARDVR_3.50.00
DM385-GP rev 1.1
ARM clk: 720MHz
DDR clk: 533MHz
L3 clk: 200MHz
IVA clk: 290MHz
ISS clk: 400MHz
DSP Default OFF
DSS Default OFF
I2C:   ready
DRAM:  1 GiB
NAND:  
nand_init_chip -> NAND base_addr-> 8000000
Searching for NAND device @ GPMC CS:0
HW ECC BCH8 Selected
DM385 -> ecc_size_config -> 81a000
DM385 -> ecc_config -> 11100
DM385 -> Busw: 0
DM385 -> nand_select_chip->0
DM385 : GPMC -> 810 CONTROL_STATUS -> 317
nand_get_flash_type: second ID read did not match 17,17 against 17,17
DM385 -> name NAND 16MiB 1,8V 8-bit id 33 against device_id 17 failed
DM385 -> name NAND 16MiB 3,3V 8-bit id 73 against device_id 17 failed
DM385 -> name NAND 16MiB 1,8V 16-bit id 43 against device_id 17 failed
DM385 -> name NAND 16MiB 3,3V 16-bit id 53 against device_id 17 failed
DM385 -> name NAND 32MiB 1,8V 8-bit id 35 against device_id 17 failed
DM385 -> name NAND 32MiB 3,3V 8-bit id 75 against device_id 17 failed
DM385 -> name NAND 32MiB 1,8V 16-bit id 45 against device_id 17 failed
DM385 -> name NAND 32MiB 3,3V 16-bit id 55 against device_id 17 failed
DM385 -> name NAND 64MiB 1,8V 8-bit id 36 against device_id 17 failed
DM385 -> name NAND 64MiB 3,3V 8-bit id 76 against device_id 17 failed
DM385 -> name NAND 64MiB 1,8V 16-bit id 46 against device_id 17 failed
DM385 -> name NAND 64MiB 3,3V 16-bit id 56 against device_id 17 failed
DM385 -> name NAND 128MiB 1,8V 8-bit id 78 against device_id 17 failed
DM385 -> name NAND 128MiB 1,8V 8-bit id 39 against device_id 17 failed
DM385 -> name NAND 128MiB 3,3V 8-bit id 79 against device_id 17 failed
DM385 -> name NAND 128MiB 1,8V 16-bit id 72 against device_id 17 failed
DM385 -> name NAND 128MiB 1,8V 16-bit id 49 against device_id 17 failed
DM385 -> name NAND 128MiB 3,3V 16-bit id 74 against device_id 17 failed
DM385 -> name NAND 128MiB 3,3V 16-bit id 59 against device_id 17 failed
DM385 -> name NAND 256MiB 3,3V 8-bit id 71 against device_id 17 failed
DM385 -> name NAND 64MiB 1,8V 8-bit id a2 against device_id 17 failed
DM385 -> name NAND 64MiB 3,3V 8-bit id f2 against device_id 17 failed
DM385 -> name NAND 64MiB 1,8V 16-bit id b2 against device_id 17 failed
DM385 -> name NAND 64MiB 3,3V 16-bit id c2 against device_id 17 failed
DM385 -> name NAND 128MiB 1,8V 8-bit id a1 against device_id 17 failed
DM385 -> name NAND 128MiB 3,3V 8-bit id f1 against device_id 17 failed
DM385 -> name NAND 128MiB 1,8V 16-bit id b1 against device_id 17 failed
DM385 -> name NAND 128MiB 3,3V 16-bit id c1 against device_id 17 failed
DM385 -> name NAND 256MiB 1,8V 8-bit id aa against device_id 17 failed
DM385 -> name NAND 256MiB 3,3V 8-bit id da against device_id 17 failed
DM385 -> name NAND 256MiB 1,8V 16-bit id ba against device_id 17 failed
DM385 -> name NAND 256MiB 3,3V 16-bit id ca against device_id 17 failed
DM385 -> name NAND 512MiB 1,8V 8-bit id ac against device_id 17 failed
DM385 -> name NAND 512MiB 3,3V 8-bit id dc against device_id 17 failed
DM385 -> name NAND 512MiB 1,8V 16-bit id bc against device_id 17 failed
DM385 -> name NAND 512MiB 3,3V 16-bit id cc against device_id 17 failed
DM385 -> name NAND 1GiB 1,8V 8-bit id a3 against device_id 17 failed
DM385 -> name NAND 1GiB 3,3V 8-bit id d3 against device_id 17 failed
DM385 -> name NAND 1GiB 1,8V 16-bit id b3 against device_id 17 failed
DM385 -> name NAND 1GiB 3,3V 16-bit id c3 against device_id 17 failed
DM385 -> name NAND 2GiB 1,8V 8-bit id a5 against device_id 17 failed
DM385 -> name NAND 2GiB 3,3V 8-bit id d5 against device_id 17 failed
DM385 -> name NAND 2GiB 1,8V 16-bit id b5 against device_id 17 failed
DM385 -> name NAND 2GiB 3,3V 16-bit id c5 against device_id 17 failed
DM385 -> name AND 128MiB 3,3V 8-bit id 01 against device_id 17 failed
No NAND device found!!!
DM385 -> nand_select_chip->-1
0 MiB
MMC:   : 0, ON-BOARD SDIO: 1

   

 

   

GPMC Register value from uboot command prompt:

   

GPMC_CONFIG -> 50000050: 00000012
GPMC_STATUS -> 50000054: 00000301

   

GPMC_CONFIG1_0 -> 50000060: 00000800 - NAND Flash, device size is 8 bit
GPMC_CONFIG2_0 -> 50000064: 00060600
GPMC_CONFIG3_0 -> 50000068: 00060601
GPMC_CONFIG4_0 -> 5000006c: 04010401
GPMC_CONFIG5_0 -> 50000070: 00040506
GPMC_CONFIG6_0 -> 50000074: 04000580
GPMC_CONFIG7_0 -> 50000078: 00000048 - Chip select size is 128MB, A27, CS enabled
GPMC_CONFIG7_1 -> 500000a8: 00000f00 - Chip select size is 16MB, CS Disabled
GPMC_CONFIG7_2 -> 500000d8: 00000f00 - Chip select size is 16MB, CS Disabled
GPMC_CONFIG7_3 -> 50000108: 00000f00 - Chip select size is 16MB, CS Disabled
GPMC_CONFIG7_4 -> 50000138: 00000f00 - Chip select size is 16MB, CS Disabled
GPMC_CONFIG7_5 -> 50000168: 00000f00 - Chip select size is 16MB, CS Disabled

   

 

   

regards,

   

Ganesh

0 Likes
BacemD_61
Employee
Employee
50 replies posted 50 sign-ins 25 replies posted

Hi Ganesh,

   

I spent some time to review the registers value you're using.

   

Please try to relax the timings by increasing the values of OEOFFTIME, WEONTIME. For instance, in your GPMC_CONFIG4_0, I saw that OEONTIME is set to 1 GPMC_FCLK cycle  and OEODDTIME is set to 4 GPMC_FCLK cycle which leaves only 3 clock cycles for the read cycle, which is too low. Same thing for the write cycle, i.e: WEONTIME and WEOFFTIME.

   

Same thing in register GPMC_CONFIG5_0 where you could increase the values RDCYCLETIME, WRCYCLETIME...

   

It's to me clear that there is something wrong with the controller settings to operate our flash.

   

Please continue to play around with the settings by relaxing the timings as much as possible and give it a try.

   

Could you try reading the ONFI signature and ONFI table?

   

Is this the unique board you have at hand which you can test with? Can you replace the unit and try with another one?

   

You might also contact TI as well for their support on this problem, since they have the expertise of the controller.

   

Best regards,

   

Bacem

0 Likes
Anonymous
Not applicable

Hi Daassi,

   

We have multiple boards, we have tested on all of them we are facing the same issue.

   

As per your suggestion we relaxed maximum time we can do it in GPMC_CONFIG register. but nothing major happen.

   

50000060: 00000800  
50000064: 00060600  
50000068: 00060f01   
5000006c: 0c071807   
50000070: 00151e1e   
50000074: 04000580   
50000078: 00000048   

   

regards,

   

Ganesh

0 Likes
BacemD_61
Employee
Employee
50 replies posted 50 sign-ins 25 replies posted

Hi Ganesh,

   

Thanks for your effort!

   

I think at this stage, it's clear enough that there is something wrong with the controller settings to operate our flash.

   

What's the name of the TI board driver you're using? I'd like to take a look at this driver as well.

   

You mentioned you had another working part. From which manufacturer is it and what's its OPN?

   

Could you try reading the ONFI signature and ONFI table?

   

You might also contact TI as well for their support on this problem, since they have the expertise of the controller.

   

Best regards,

   

Bacem

0 Likes
Anonymous
Not applicable

Hi Daassi,

   

I'm using TI DM385 IPNC board,

   

board/ti/dm385_ipnc/evm.c -> board file

   

arch/arm/cpu/arm_cortexa8/ti81xx/mem.c

   

arch/arm/cpu/arm_cortexa8/ti81xx/sys_info.c

   

drivers/mtd/nand/ti81xx_nand.c -> nand driver

   

drivers/mtd/nand/nand.c

   

drivers/mtd/nand/nand_base.c

   

arch/arm/include/asm/arch-ti81xx/mem.h / nand.h -> sets config values

   

We are using micron x16 bit ONFI 1.0. it is not having any issue. From TI side their is no much support. As uboot and kernel is old they are not providing much support.

   

 

   

regards,

   

Ganesh

0 Likes
BacemD_61
Employee
Employee
50 replies posted 50 sign-ins 25 replies posted

Hi Ganesh,

   

Thanks for the additional details!

   

I had a look at the source files and I have to say that it's really hard for me to find something without having access to a complete test system.

   

Please try to visualize some of the important signals on an oscilloscope just to see if any bus traffic is reaching the NAND flash or not. You could check CE#, WE#, OE#, ALE. CLE and some of the IOs.

   

Please also check the power on timing. The first access to the flash should take place at least 5ms after Vcc ramp up.The R/B pin will show when the device is ready.

   

As mentioned, it would have been much easier to debug using a LA.

   

Best regards,

   

Bacem

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Hi Daassi,

   

We also checked I/O Lines, in nand_base.c file, where it is trying to pass command RESET & READ_ID, we have kept while 0ne loop so we can probe all data lines and ALE,CLE,WE,RE can probed.

   

Please find attached waveform file. Daassi, GPMC_CONFIG has been configured for more time.

   

order of waveform is from

   

CLE[Top most - CH2] followed by CE[CH3],WE[CH4] and ALE[Bottom most - CH1].

   

We probed I/O lines, as RESET Value is 0xFF - all I/O lines will be high & then READ_ID value is 0x90[D7 & D4] are high and remaining lines are low.

   

From NAND flash side, when we chip_byte(mtd) -> we should get maf_id & device_id these where it is reading SYSBOOT Values.

   

I will check 5ms and Vcc ramp up.

   

R/B is pulled externally high to 3.3v.

   

regards,

   

Ganesh

0 Likes
BacemD_61
Employee
Employee
50 replies posted 50 sign-ins 25 replies posted

Hi Ganesh,

   

The fact that reading NAND Flash device ID is showing SYSBOOT value does not mean that there is an issue with the flash. The flash doesn't know anything about the SYSBOOT values.

   

I think it's clear here that there's an issue with the controller configuration that's probably not ideal, and that's what I'm doing my best here to help you identifying.

   

I saw on the waveforms you sent that there is some big over- and undershots. here is what the datasheet says about this: "Maximum Voltage may overshoot to VCC+2.0V during transition and for less than 20 ns during transitions.". In these overshots, some are definitely taking longer than 20ns.

   

Best regards,

   

Bacem

0 Likes
Anonymous
Not applicable

Hi Daassi,

   

As i mentioned in my post that i have used maximum time at the same time in GPMC_CONFIG1 register i have set time paragranuality i.e x2 latency time. so the waveform coulb be because of that reason. I will check with new config values. if you find any solution please do share i'm at critical stage of my project[Only booting from NAND left].

   

 

   

regards,

   

Ganesh

0 Likes
BacemD_61
Employee
Employee
50 replies posted 50 sign-ins 25 replies posted

Hi Ganesh,

   

I think it would be of a great help if you can manage to get some additional LA traces.

   

The other point regarding the over- and undershots is also very critical.

   

Meanwhile, I will check internally if any of my colleagues has seen the same issue before.

   

Best regards,

   

Bacem

0 Likes
BacemD_61
Employee
Employee
50 replies posted 50 sign-ins 25 replies posted

Hi Ganesh,

   

I discussed this topic with our team members and we have the following ideas/suggestions:

   

1. It has been seen on similar cases that had glitches on the signals that the NAND flash was not responding properly to the read ID command and any other command.

   

2. We would like to make sure that the flash is being properly connected to the chipset. Could you please send me the schematics that show this connection for review?

   

Best regards,

   

Bacem

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Hi Daassi,

   

please find attachment of schematic.

   

 

   

regards,

   

Ganesh

0 Likes
BacemD_61
Employee
Employee
50 replies posted 50 sign-ins 25 replies posted

Hi Ganesh,

   

I reviewed your schematics and they looked fine to me.

   

It looks like the NAND flash is not responding at all and is not driving the bus that's why you're constantly reading the SYSBOOT (0x17) value.

   

Is the GPMC using the GPMC_WAIT0 signal to wait until the flash is no longer busy?

   

I guess there is something wrong with the power up sequence. Please double check the remaining open points we discussed.

   

Best regards,

   

Bacem

0 Likes
Anonymous
Not applicable

Hi Bacem Daassi,

   

I want to thanks for your support we have solved the issue. If you can look into schematic their is one resistor called R47[BT_MODE2] which decides NAND/SD boot. as we were connecting jumper it was creating problem. Now we have mounted 1kOhm Resistor. it started detecting NAND. and we were able to make read and write on nand.

   

thanks & regards,

   

Ganesh 

0 Likes
BacemD_61
Employee
Employee
50 replies posted 50 sign-ins 25 replies posted

Hi Ganesh,

   

Glad to hear that you were successful in fixing the issue. That's a great new!

   

Let us know if there is anything else we can do to help!

   

Best regards,

   

Bacem

0 Likes