AM625: Question for Serial NAND boot flow

Tashiro-san, 

ROM expert is out this week.  My guess is that the BUSY bit is checked, The 13h command is followed by 3 address bytes.  Not sure what other info you are looking for. 

Please check the following for discussion on compatible devices:

 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1449924/am623-am62x-mpu-compatibility-support-with-qspi-nand-flash-parts/5679045?tisearch=e2e-sitesearch&keymatch=am62x%252520serial%252520nand#5679045

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1307344/faq-am625-am623-am62l-am62a-am62d-q1-am62p-design-recommendations-commonly-observed-errors-during-custom-board-hardware-design-ospi-qspi-memory-interface?tisearch=e2e-sitesearch&keymatch=ospi%2525252525252520faq#

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1181116/faq-ospi-faq-for-sitara-jacinto-devices?tisearch=e2e-sitesearch&keymatch=ospi%25252525252525252520faq#

REgards,

James

Hi James,

JJD said:

ROM expert is out this week.  My guess is that the BUSY bit is checked, The 13h command is followed by 3 address bytes. 

The customer can wait for the final answer until next week. So please double check it with the ROM expert.

Thanks and regards,
Koichiro Tashiro

Hi James,

Thanks for confirming.
Do you mean the ROM code polls BUSY bit in the Status Register and even if the bit is not cleared until calculated timeout, it goes to next step and boot-up properly?

According to below FAQ,  "Read Status Register" has below requirements.
"It is mandatory for a flash to support this command in 1S-1S-1S mode with the opcode 0x05, 0 address bytes, 0 dummy cycles." 
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/946418/faq-tda4vm-is-there-a-guide-to-choosing-the-right-ospi-flash-parts-that-are-supported-on-jacinto-7

The customer wants to know if the NAND device does not support above requirements, the device cannot be used as booting device.

Thanks and regards,
Koichiro Tashiro

Koichiro, yes it will move on to the next step after BUSY bit is cleared or the timeout is met.  

I don't know where that requirement comes from.   Let me see if i can find out. 

REgards,

James

Hi Lucas,

Thanks for your detailed answer!
The customer wants to confirm below point.

Koichiro Tashiro said:

The customer wants to know if the NAND device does not support above requirements, the device cannot be used as booting device.

According to your answer, it seems the NAND can be used as booting device even it does not support the "read status register" command with Opecode 0xF.
Correct?
Or the "read status register command" is used other place?

Thanks and regards,
Koichiro Tashiro

Hi Koichiro,

i'd be interested to know which device they are looking at which doesn't support the status register command with opcode 0xF?

We have tested with Winbond and Micron, and each has the same location for the busy bit.

If the device doesn't support status register command 0xF, the timeout of 2ms would take affect on each page read, but should still complete.  However, this may not be ideal for the customer, as it would result in much longer boot time.

Regards,

James

Hi James,

JJD said:

i'd be interested to know which device they are looking at which doesn't support the status register command with opcode 0xF?

I am asking the customer the device part#.

JJD said:

However, this may not be ideal for the customer, as it would result in much longer boot time.

Could you double check "read status register" is not used in other part in ROM code?

Thanks and regards,
Koichiro Tashiro

Hi Koichiro, the ROM will perform reads from the NAND in the same manner.  Not sure why you are asking if it is used in other parts of the ROM code.  I will be used whenever the ROM reads from the Serial NAND>

Regards,

James

Hi James,

I just sent you NAND part# and datasheets the customer is planning to use.

Thanks and regards,
Koichiro Tashiro

Koichiro, i received the datasheets, and it appears that both support command 0xF at address 0xC0, so they would support Read Status Register.

Ultimately, however, in order to determine if the device can boot, i would recommend that the customer replace the device on an EVM with the devices they are interested in, and attempt to boot from them. Because there is such a wide variety of devices that have different features and specs, it is difficult to definitively say a certain device will boot or not.

Regards,

James

Hi JJD,

JJD said:

it appears that both support command 0xF at address 0xC0, so they would support Read Status Register.

According to below FAQ, command needs to be 0x5 and address is 0x0. Is this typo?
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/946418/faq-tda4vm-is-there-a-guide-to-choosing-the-right-ospi-flash-parts-that-are-supported-on-jacinto-7

BTW, above FAQ is linked from below AM62 SDK document.
https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/11_00_09_04/exports/docs/linux/Foundational_Components/U-Boot/UG-QSPI.html#ospi-qspi-nor-nand


Thanks and regards,
Koichiro Tashiro

Greetings Koichiro,

Both of the links you have posted are for Linux/U-boot which is separate from the ROM. If you have questions about the software I would recommend a separate ticket specifically for those software details.

Sincerely,

Lucas

Hi Lucas,

I am a bit confused. Do you mean supported NAND device is different between ROM and Linux/U-boot?
- ROM supports 0xF as Read Status Register command.
- Linux/U-boot supports 0x5 as Read Status Register command.
It does not make sense to me.

Thanks and regards,
Koichiro Tashiro

Greetings Koichiro,

The ROM is non-volatile code on our device that cannot be changed and is used to load the boot images, this can be called the primary bootloader. Your original question references the TRM chapter about OSPI NAND boot, which is the primary bootloader that reads the image from serial NAND flash. These requirements to boot cannot be changed.

The primary bootloader loads an image into the SoC, after that it all depends on what the user has chosen to place into flash. It will usually be some form of a secondary bootloader, such as what's available in the MCU+SDK or even bare-metal code; it does not have to be U-boot. It is entirely up to the user what the secondary bootloader does or even needs, some customers boot from OSPI and then never have a need to touch it again for their use-case.

Secondary bootloaders are entirely user customizable. U-boot which is commonly used to boot Linux is open source and all the drivers/requirements depend on the code itself and how it is customized for the user. If you're asking about requirements for Linux/U-boot and the details around them, you will have better luck filing a targeted ticket of software questions so that what is required or not required by that software can be understood.

Sincerely,

Lucas

Hi Lucas,

Thanks for clarification. I understood differences between the primary bootloader and the the secondary bootloader.
What the customer is asking here is for the primary bootloader (ROM bootloader) which users cannot be changed.

Q1) I understood from previous discussion, the primary bootloader supports Opecode 0xF as Read Status Register. Correct?

Q2) On the other hand, Linux/U-boot supports Opecode 0x5 as Read Status Register, Correct?

Q3) If both answers to Q1/Q2 are "YES";
- Opecode 0xF is mandatory for serial NAND boot.
- Opecode 0x5 is an optional if serial NAND accesses are required in customers' usecases.
Correct?

Thanks and regards,
Koichiro Tashiro 

Koichiro,

1) yes

2) not sure what the MCU+SDK driver supports.  I will forward your question to get an answer.

3)  0xF is mandatory to be compatible to ROM.  I don't know what the default operation of the secondary bootloader is.  But if the device supports both opcodes, then it could work with either.

Regards,

James

Hi,

Allow me sometime to read through this thread and respond on the open questions.

Regards,

Vaibhav