LS1046A IFC Async NAND interface revisited

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

LS1046A IFC Async NAND interface revisited

938 Views
Daves_Garage
Contributor IV

Back to getting the NAND interface working correctly with u-boot, I'm experiencing the first chip select line CS0 working correctly, but the second chip select CS1 being held low all the time (this is within U-boot)...

For some parts, I'm able to access NAND (I'm assuming both the first and second banks are being written and read from at the same time), but for others, I am not.

Oddly enough, the ONFI parameter page is read correctly on the ones that work.  I've setup the mask register for 2GB boundary, as the part is a 4GB part, and I'm looking for advice on what to look for next.

Any help is appreciated.

0 Kudos
9 Replies

318 Views
simon_braun
Contributor I

This thread has aged a little but did you make any progress on this issue?
I'm facing pretty much the same problem of having a second NAND back to back without being seen in mtd as a second devices.
Haven't done any tests though... but will do in the next weeks.

0 Kudos

302 Views
Daves_Garage
Contributor IV

No, not really... I'm able to use 1/2 of the chip to hobble along with testing, which is where I store my OS images that get loaded into DDR4 memory.  Once the OS is loaded, I'm hoping to focus my effort on the driver there so it will access the whole thing, and I can use the second half as a novram ramdisk... I haven't gotten to it yet... Probably next month I'll get a chance...

Were you getting the same effect?  Did you find out anything useful?  It's kinda frustrating not having a FAE you can call upon for things like this... the back and forth over the forum is painfully slow...

-Dave

 

0 Kudos

888 Views
Daves_Garage
Contributor IV

Here are the results while using the u-boot commands:

NAND read: device 0 offset 0x7ff80000, size 0x80000
 524288 bytes read: OK
=>

image.png

=> nand read 0x80100000 0x80000000 0x80000

NAND read: device 0 offset 0x80000000, size 0x80000
 524288 bytes read: OK
=>

image.png

0 Kudos

889 Views
Daves_Garage
Contributor IV

Hi Yi Ping,

Section 5.2 of this appnote refers to hardware recommendations, and I followed these recommendations during board development.  I actually use 4.7k pullups on the CS lines.

I don't believe this is a hardware issue, but rather a software issue; specifically an issue within u-boot software and the IFC setup.

I based the setup off of the software provided by LSDK 21.08.

As a background on the board, the NAND flash is 4GB; 2GB per chip select.

I am able to control the CS lines independently when I use the following code

void TestNANDchipselect( void ) {
    struct mtd_info  *mtd  = get_nand_dev_by_index(0);
    struct nand_chip *nand = mtd_to_nand(mtd);
    uint8_t buffer[4096];

    while( 1 ) {
        nand_read_page_op(nand, 0x7FF80000>>12, 0, buffer, 1024);
        nand_read_page_op(nand, 0x7FF80000>>12, 0, buffer, 1024);
        nand_read_page_op(nand, 0x80000000>>12, 0, buffer, 1024);
    }
}

I get the following scope traces:

NAND CS1&2NAND CS1&2

The problem is from within u-boot.  When I execute `nand erase.chip`, the terminal output indicates it erases all addresses from 0x00000000-0xFFFFFFFF, but the scope indicates it never uses the CS1 line...  this is confusing.

Can you think of a reason why this might happen?

I can provide you with the constant definitions I use within my board header file if that would help.

-Dave

 

0 Kudos

861 Views
yipingwang
NXP TechSupport
NXP TechSupport

Please modify the following in include/configs/ls1046ardb.h in u-boot source file. Please modify CS0 to CS1

#define CONFIG_SYS_CSPR0_EXT CONFIG_SYS_NAND_CSPR_EXT
#define CONFIG_SYS_CSPR0 CONFIG_SYS_NAND_CSPR
#define CONFIG_SYS_AMASK0 CONFIG_SYS_NAND_AMASK
#define CONFIG_SYS_CSOR0 CONFIG_SYS_NAND_CSOR
#define CONFIG_SYS_CS0_FTIM0 CONFIG_SYS_NAND_FTIM0
#define CONFIG_SYS_CS0_FTIM1 CONFIG_SYS_NAND_FTIM1
#define CONFIG_SYS_CS0_FTIM2 CONFIG_SYS_NAND_FTIM2
#define CONFIG_SYS_CS0_FTIM3 CONFIG_SYS_NAND_FTIM3

Please refer to the following section.

#define CONFIG_SYS_CSPR1_EXT CONFIG_SYS_NAND_CSPR_EXT
#define CONFIG_SYS_CSPR1 CONFIG_SYS_NAND_CSPR
#define CONFIG_SYS_AMASK1 CONFIG_SYS_NAND_AMASK
#define CONFIG_SYS_CSOR1 CONFIG_SYS_NAND_CSOR
#define CONFIG_SYS_CS1_FTIM0 CONFIG_SYS_NAND_FTIM0
#define CONFIG_SYS_CS1_FTIM1 CONFIG_SYS_NAND_FTIM1
#define CONFIG_SYS_CS1_FTIM2 CONFIG_SYS_NAND_FTIM2
#define CONFIG_SYS_CS1_FTIM3 CONFIG_SYS_NAND_FTIM3

0 Kudos

832 Views
Daves_Garage
Contributor IV

I'm having some confusion about mapping the address space for a single chip that uses 2 chip selects: CS0 for the first 2GiB, and CS1 for the second 2GiB.

How should the variables be setup to accomplish this?

 

0 Kudos

612 Views
Daves_Garage
Contributor IV

one month with radio silence on this thread...

Are there any employees of NXP familiar with the NAND flash software in U-boot specific to the LS1046A?

Even an employee familiar with just the LS1046A processor - even this might help...

0 Kudos

848 Views
Daves_Garage
Contributor IV

This produces the same effect, and is what I had already implemented...
Can you explain the significance of the base address, and how it maps to the IFC memory, and can you explain the AMASK value, and what value it should have to produce a new CS for the second NAND flash part?

Using these default values:

#define BPC_NAND_BUFFER_BASE0 0x60000000
#define BPC_NAND_AMASK0 0
#define BPC_NAND_CSPR0_EXT (0x0)
#define BPC_NAND_CSPR0 \
(CSPR_PHYS_ADDR(BPC_NAND_BUFFER_BASE0) | CSPR_PORT_SIZE_8 | \
CSPR_MSEL_NAND | CSPR_V) // programmed value
#define CONFIG_SYS_CSPR0 BPC_NAND_CSPR0
#define CONFIG_SYS_CSPR0_EXT BPC_NAND_CSPR0_EXT

#define CONFIG_SYS_CSOR0 BPC_NAND_CSOR

#define CONFIG_SYS_AMASK0 BPC_NAND_AMASK0
#define CONFIG_SYS_CS0_FTIM0 BPC_NAND_FTIM0
#define CONFIG_SYS_CS0_FTIM1 BPC_NAND_FTIM1
#define CONFIG_SYS_CS0_FTIM2 BPC_NAND_FTIM2
#define CONFIG_SYS_CS0_FTIM3 BPC_NAND_FTIM3
#define CONFIG_SYS_CSOR0_EXT BPC_CSOR_EXT
// CONFIG_SYS_CSPR0_FINAL??? is this necessary?
// CONFIG_SYS_AMASK0_FINAL??? is this necessary?

The CS line is active on CS0 (as expected)...

Using these values:

#define BPC_NAND_BUFFER_BASE1 0x60000000
#define BPC_NAND_AMASK1 0
#define BPC_NAND_CSPR1_EXT (0x0)
#define BPC_NAND_CSPR1 \
(CSPR_PHYS_ADDR(BPC_NAND_BUFFER_BASE1) | CSPR_PORT_SIZE_8 | \
CSPR_MSEL_NAND | CSPR_V) // programmed value
#define CONFIG_SYS_CSPR1 BPC_NAND_CSPR1
#define CONFIG_SYS_CSPR1_EXT BPC_NAND_CSPR1_EXT

#define CONFIG_SYS_CSOR1 BPC_NAND_CSOR

#define CONFIG_SYS_AMASK1 BPC_NAND_AMASK1
#define CONFIG_SYS_CS1_FTIM0 BPC_NAND_FTIM0
#define CONFIG_SYS_CS1_FTIM1 BPC_NAND_FTIM1
#define CONFIG_SYS_CS1_FTIM2 BPC_NAND_FTIM2
#define CONFIG_SYS_CS1_FTIM3 BPC_NAND_FTIM3
#define CONFIG_SYS_CSOR1_EXT BPC_CSOR_EXT
// CONFIG_SYS_CSPR0_FINAL??? is this necessary?
// CONFIG_SYS_AMASK0_FINAL??? is this necessary?

The CS line is active on CS1 (as expected)...

The problem is creating definitions that allow me to put the 2 parts end to end, so the first part uses an address range below 0x80000000 and the second part uses an address range from 0x80000000 and above.

When I try to assign a base address of 06_80000000 by setting the EXT register to 0x06, the system generates "Error" handler, esr `0xbf000000`

Also, if I give them the same base address, from within u-boot, I get:

Daves_Garage_0-1700089302240.png

This is fine, but again - they both use the same CS0 line...

Thank you for your time in advance.

0 Kudos

896 Views
yipingwang
NXP TechSupport
NXP TechSupport

Please refer to "5.2 IFC recommendations " in https://www.nxp.com.cn/docs/en/application-note/AN5252.pdf.

0 Kudos