Sad, I made it all the way to the end of the year without any response from NXP on this forum... That says something.
I got ahold of an FAE (Field Application Engineer) from NXP and discussed the issue with him a few months ago, and he said it wasn't possible - that says something too, lol.
Since I wasn't going to accept that answer, I spend a few days playing around with things, and finally got it to work - key note for anyone reading this: The reference manual is wrong. Don't believe the RCW settings table 3-9 for IFC signal configurations:
When IFC_GRP_E_EXT is set to 1, the RD_B[n]_B signal associated with IFC_CS_B[1] is ignored! This is the problem.
Set IFC_GRP_E_EXT to 0 and watch what happens!
I hope this helps somebody out there... no retreat, no surrender
-Dave
Sad, I made it all the way to the end of the year without any response from NXP on this forum... That says something.
I got ahold of an FAE (Field Application Engineer) from NXP and discussed the issue with him a few months ago, and he said it wasn't possible - that says something too, lol.
Since I wasn't going to accept that answer, I spend a few days playing around with things, and finally got it to work - key note for anyone reading this: The reference manual is wrong. Don't believe the RCW settings table 3-9 for IFC signal configurations:
When IFC_GRP_E_EXT is set to 1, the RD_B[n]_B signal associated with IFC_CS_B[1] is ignored! This is the problem.
Set IFC_GRP_E_EXT to 0 and watch what happens!
I hope this helps somebody out there... no retreat, no surrender
-Dave
Here are the results while using the u-boot commands:
NAND read: device 0 offset 0x7ff80000, size 0x80000
524288 bytes read: OK
=>
=> nand read 0x80100000 0x80000000 0x80000
NAND read: device 0 offset 0x80000000, size 0x80000
524288 bytes read: OK
=>
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:
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
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:
This is fine, but again - they both use the same CS0 line...
Thank you for your time in advance.
