i.MX6 Internal Boot from SPI Stuck in ROM

cancel
Showing results for 
Search instead for 
Did you mean: 

i.MX6 Internal Boot from SPI Stuck in ROM

Jump to solution
1,558 Views
ronsandel
Contributor I

We have developed a custom board with an i.MX6D and I've been trying to get it to load from the SPI NOR and it seems to be stuck in the ROM.  It is supposed to be in Internal Boot mode and loading from CS0 on eCSPI5.  I'm able to attach JTAG while it is stuck in the ROM and I can verify the following:

  • SRC_SBMR2 @ 0x20D801C = 0x22000001, so BOOT_MODE[1:0] is set to internal boot and BT_FUSE_SEL isn't set.
  • SRC_SBMR1 @ 0x20D8004 = 0x0CC00030:
    • BOOT_CFG1 = 0x30 which the documentation says is for serial boot.
    • BOOT_CFG4 = 0x0C which should be chip select 0, 3 byte addressing, and eCSPI5.

The log buffer contains:

00902190: 02 00 01 00 f0 00 02 00 00 00 03 00 00 00 04 00  ................

009021A0: 00 00 05 00 04 00 06 00 00 00 08 00 00 00 00 00  ................

009021B0: f0 00 08 00 00 00 09 00 33 05 0a 00 ff 1f 06 00  ........3.......

009021C0: 00 00 0c 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

While in JTAG, I can place breakpoints for data access and I never see the eCSPI5 registers accessed.  I've gone through the documentation over and over and searched through this forum.  What does the log say is happening?

Thanks,

Labels (2)
0 Kudos
1 Solution
112 Views
qiang_li-mpu_se
NXP Employee
NXP Employee

I think the swap was caused by the ECSPI module, it can only work in big endian mode. In iMX6 boot ROM, it will also swap the bytes, so this is not the problem if you used Freescale software to burn the data into SPI nor.

But if you burn the SPI nor with other tools, such as ROM programmer, it will be issue if there is no swap.

View solution in original post

0 Kudos
7 Replies
112 Views
qiang_li-mpu_se
NXP Employee
NXP Employee

For ECSPI5 boot, it can only support the followed PIN MUX, how about the customer's PIN used for ECSPI5:

SD1_DAT1: for SS0

SD1_DAT0: for MISO

SD1_CMD: for MOSI

SD1_CLK: for SCLK

By the way, the customer should also make sure their chip is iMX6D not iMX6DL, only iMX6D and iMX6Q have the ECSPI5.

0 Kudos
112 Views
ronsandel
Contributor I

Yes, my eCSPI5 is hooked up on those pins and I am using the iMX6D.  If I load my program over JTAG, I am able to access the eCSPI5 peripheral properly.

0 Kudos
112 Views
MarekVasut
Senior Contributor I

Try connecting a logic analyzer to the SPI bus and see if the CPU actually loads the payload from the NOR at all.

Also, how do you produce and write the payload into the NOR?

112 Views
ronsandel
Contributor I

So I wound up hooking a scope with serial decode on to the SPI bus and I was able to verify that the peripheral was working.  I must have set up the breakpoint on the eCSPI5 registers incorrectly on Friday, because when I tried it again today it triggered.  From there, I was able to verify the data looked correct on the scope and then I was able to find where in memory the data was being stored and when I looked at it I noticed the bytes were swapped.  I am using VxWorks and in the original SPI driver I noticed it was swapping bytes on both read and write and thought that was odd so when I wrote my driver I didn't do that.  Turns out the ROM needs things to be swapped.  So after I put the swapping back in I was able to successfully load from the SPI NOR.

So my question now, is why is the ROM requiring it's data to be swapped?  I read the System Boot chapter in the Reference Manual and found nothing that would suggest that.

Thanks,

0 Kudos
112 Views
MarekVasut
Senior Contributor I

I never used vxworks, but what do you mean by swapping? You mean the buffer with the data that are being put on the line needs to be adjusted by the IMX/SPI driver before executing the actual transfer ?

This must be some vxworks specific behavior, since for example in Linux and U-Boot, you usually get only a simple buffer of bytes (unsigned char []) and put them on the line in the same order you got them.

0 Kudos
112 Views
ronsandel
Contributor I

I mean endian byte swapping.  It looks like u-boot is doing the same thing:

https://github.com/boundarydevices/u-boot-imx6/blob/production/drivers/spi/mxc_spi.c#L256

Each data word is being swapped to big endian.

0 Kudos
113 Views
qiang_li-mpu_se
NXP Employee
NXP Employee

I think the swap was caused by the ECSPI module, it can only work in big endian mode. In iMX6 boot ROM, it will also swap the bytes, so this is not the problem if you used Freescale software to burn the data into SPI nor.

But if you burn the SPI nor with other tools, such as ROM programmer, it will be issue if there is no swap.

View solution in original post

0 Kudos