How ROM increments device address in imx53?

[rahul44]

Hi NXP community,

I am using imx53 based processor and there is need to boot from serial I2C based EEPROM. In iMX53RM Rev. 2.1 document, page no: 514, it is mentioned that device address as 0x50. In our case EEPROM total memory is divided into 4 quadrant, each having incremental device address starting from 0x50. So how will ROM increment device address after writing into first quadrant? 

[orangeashu]

Hello Jimmy, 

Thanks for your A2A and point to point. 

3 further questions: 

1). Any EVK or develop board or any customer board (which is available to use), where EIM_D18 & EIM_D17 pins are out and can be checked with our customized + compressed uboot of size 63K (from your end or can be purchased or sampled to us) ?

2). When we put this into Serial I2C mode from fuse, which speed this I2C will work from BOOT ROM reading? Like 100 KHz or 400 KHz. Reference manual doesn't mention this point.

3). As we understood that, I2C is not verified by NXP teams, But is ECSPI1/ 2 verified?
if yes, please share some information like which port and how it had been verified.

As we understand that our current SOM doesn't have any pins coming out of I2C3 from EIM_D18 & D17. we are using I2C3 on GPIO1(5) & GPIO(6) IO MUX, we need to do a respin of HW, then we would like to take a decisive call for I2C Vs CSPI.

--
Thanks
Ashish Agarwal

[jimmychan]

1) As the i.MX53 is very old. Sorry, I cannot find any i.MX53 EVK is available for order.

2) I think it should be working at 400kHz.

3) ECSPI1 connect to a M25P32. Attached is the MX53 board schematic. In the BSP user's guide Table 3.5, there is switch setting for booting from SPI NOR.

[orangeashu]

Hello,

Thanks a lot Jimmy.

By having this reference. i think we can certainly confirm that CSPI1 would have been verified. 

though I2C IS NOT checked, but it can be verified over this tablet platform as it has wires coming out, which can be jumpered.

https://www.nxp.com/design/development-boards/i-mx-evaluation-and-development-boards/sabre-platform-....

But yes, it seems it may work as SPI is working.

I think this thread can be put on rest, till we check or do POC in a way or other or finds out some EVK custom first versions in our yard.

One again thanks a lot, appreciate your prompt response. Very much appreciated. You are true savior.

[orangeashu]

One more query to add: 

6. What is I2C clock frequency expected when power on after I2C fusing is done, like 100 MHZ or 400 MHz.

    We will capture the waveform and share with you tomorrow early morning IST time.

[orangeashu]

Hello Jimmychan

To give you a background here about the end use case and issue description: 

Our customer custom device based on i.Mx53 boot directly from an eMMC chip from Micron (N2M400FDB311A3C).  It is version 4.41.  The eMMC chip has gone end of life and newer versions while they should be backwards compatible do not work because of an issue with the i.MX53 boot ROM.  Here is the response our customer received from NXP

NXP Response - July 2017: This is a limitation for this old i.MX part. The i.MX53 supports eMMC 4.5 but not at the booting. Unfortunately, the ROM cannot be updated with a newer version and this reduces the option to boot from external memory. If customers use SPI for instance just for the booting, they can continue using eMMC after it boots.

Customer did some last buy, but they are running out of N2M400FDB311A3C, Hence requested for alternate solution.

Hence as a solution we had targeted to boot from I2C EEPROM (M24M02) first from BOOT ROM, and then switch to eMMC uboot again and then boot Linux from eMMC.

We have 2 issues if I set priority than:

1. https://community.nxp.com/t5/i-MX-Processors/Problem-reading-emmc-from-uboot-for-imx53/m-p/1240315#M...
   Here you consider for POC we are loading minimal uboot via Serial download mode from USB to RAM and boot it. Then internally from this uboot we would like to read another uboot from eMMC.

2. https://community.nxp.com/t5/i-MX-Processors/How-ROM-increments-device-address-in-imx53/m-p/1239651#...
Once above problem is solved and we are able to create uboot-1, which is able to read from eMMC.
Now when we flash into I2C EEPROM, if this size is more then 64KB then I2C EEPROM will have whole uboot in 2 quadrants of this memory (M24M02: has 4 quadrants of 64KB size with address as 0x50, 0x51, 0x52, 0x53). Hence in boot rom fusing, if we set address of starting quadrant 0x50, how I2C FW in boot rom will be able to increase the I2C address from 0x50 → 0x51 or not.
If not then we need to reduce uboot as minimum as possible for size < 64 KB

Thanks
Ashish Agarwal

[jimmychan]

Do you mean you cannot boot from EEPROM?

What is the address 0x50? I cannot find it in RM.

[rahul44]

It is mentioned on pg: 514 Table 7-23. EEPROM via I2C Device Select Code. By default it seems 0x50 as device address, how can we change or increment address?

[jimmychan]

Mostly, there is "Device Select Code" in the EEPROM setting. You can refer to the datasheet of EEPROM to match this setting.

[rahul44]

Yes, this matches my device address as 0x50. My EEPROM is M24M02, which has four quadrants and memory divided between them. So 1st quadrant has device address-0x50, second-0x51, third-0x52 and fourth-0x53. Each can store 64KB memory (Total 256 KB). There is a need to read more than 64KB memory so is it possible as ROM can identify only 1st quadrant i.e. 0x50 ?

[jimmychan · Accepted solution]

>> how I2C FW in boot rom will be able to increase the I2C address from 0x50 → 0x51 or not.

Sorry, the answer is no. The address cannot be increase.

How about to consider the boot from SPI-NOR?

[orangeashu]

Hello  jimmychan

Thanks for your proposal, however we don't have possibility of SPI bus coming out of our SOM module to carrier board. As it is very old and existing design. Hence Re-Spin of SOM design is not a primary option.

Hence we are limited and bounded to boot from I2C only.

however based on your reply and our latest status i have below queries: 

1. Did I2C boot tested by NXP on i.MX53 platform??
   Also can you please share the I2C based uboot source code, as it is quite challenging to make uboot of this minimal size for I2C based devices.

2. To Set fusing with I2C, we are writing below address: 

Addr	Value
0804	0x10
080C	0x30
0810	0x01
0814	0x20
180C	0x04

Does 0x818 Register also required to be set for proper I2C fusing?

3. We had prepared a uboot binary (minimal size) of size 63KB and writing in Big endian (4 Byte or int size) way into I2C externally. Can you please confirm how this binary data and at which address (i.e. Offset is required or not, if yes then what and how to calculate it) is need to be written?

As you confirmed that I2C addressing can't be increased in boot rom code, hence it means the MAX size of uboot possible to write over I2C is only 63K, 1024 offset might be required (as per RM).

Reference: "Table 7-26. Image Vector Table Offset and Initial Load Region Size" of "i.MX53 Multimedia Applications Processor Reference Manual, Rev. 2, 12/2012"

> Boot Device Type Image           Vector Table Offset             Initial Load Region Size
> I2C/HS-I2C/SPI EEPROM        1 Kbyte = 0x400 bytes        2 Kbyte

4. How to flash or write data over I2C via uuu script or any other script over USB / Serial download mode? Please share reference (if script is not present fully working also) as it may help us to lead some clue to move forward. 

5. Is there any sequence or I2C data scope traces are available in your side repo, which can help us to debug our side (I2C booting doesn't work) Problem?

Thanks

Ashish Agarwal

[jimmychan]

1) No, we don't test the boot from EEPROM (I2C). So we don't have the example code.

2) No

3)Yes, you are right. The offset is 0x400.

4,5) Sorry, we don't have it.