i.MX6ULL QSPI controller corrupted by Boot-ROM

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

i.MX6ULL QSPI controller corrupted by Boot-ROM

Jump to solution
1,993 Views
friederschrempf
Contributor IV

I want to share some strange behaviour, that we discovered on i.MX6ULL in case anyone else faces this issue and in hope that someone can explain what is actually going on.

We used to use i.MX6UL in QSPI boot mode to get the bootloader from a QSPI-NOR flash chip. This worked fine until we replaced the i.MX6UL by an i.MX6ULL. After booting from QSPI-NOR (which works fine), the Linux Kernel (4.14+backports) wasn't able to detect and access the QSPI-NOR flash any more. Booting the same bootloader binary from a different device like SD card, the QSPI-NOR worked just fine in Linux.

We found out, that in case of QSPI Boot and only on i.MX6ULL, one bit in the QSPI registers differs from non-QSPI boots, or i.MX6UL. When the issue occurs, bit 16 in QuadSPI_FLSHCR register is set, in other cases it is not set.

=> md.l 0x021e000c 1
021e000c: 00010303
=> md.l 0x021e000c 1
021e000c: 00000303

According to the reference manual of UL and ULL, the bit is marked as "Reserved", so it is completely unknown, what it actually means. As a workaround we can manually reset the bit in the bootloader code and this will cause the Linux QSPI driver to work properly and being able to access the NOR flash in Linux.

Labels (2)
0 Kudos
1 Solution
1,661 Views
friederschrempf
Contributor IV

bernhardfink‌ has pointed me to the reference manual of the i.MX7, which explains the meaning of bit 16 and 17 in the QuadSPI_FLSHCR register.

pastedImage_1.png

I guess the i.MX6UL contains an older version of the QSPI IP, that doesn't have the TDH feature and the documentation for the i.MX6ULL seems to miss the information about the differences in the QSPI hardware.

Our QSPI parameter file enables the DDR mode for the BootROM and our U-Boot implementation too uses DDR mode for read access via the AHB bus, which is the reason why the access via U-Boot works fine.

The Linux driver instead uses SDR mode and therefore resets the DDR_EN bit in the QuadSPI_MCR register, but leaves the TDH bits untouched, which leads to failures accessing the flash.

View solution in original post

7 Replies
1,662 Views
friederschrempf
Contributor IV

bernhardfink‌ has pointed me to the reference manual of the i.MX7, which explains the meaning of bit 16 and 17 in the QuadSPI_FLSHCR register.

pastedImage_1.png

I guess the i.MX6UL contains an older version of the QSPI IP, that doesn't have the TDH feature and the documentation for the i.MX6ULL seems to miss the information about the differences in the QSPI hardware.

Our QSPI parameter file enables the DDR mode for the BootROM and our U-Boot implementation too uses DDR mode for read access via the AHB bus, which is the reason why the access via U-Boot works fine.

The Linux driver instead uses SDR mode and therefore resets the DDR_EN bit in the QuadSPI_MCR register, but leaves the TDH bits untouched, which leads to failures accessing the flash.

1,661 Views
art
NXP Employee
NXP Employee

shivanipatel‌ ,

The SCH-28616 schematic refers to the EVK Base board that is common for the i.MX6UL and i.MX6ULL EVK boards. The schematic of the i.MX6UL CPU board is SPF-28617, for the i.MX6ULL CPU board - SPF-29364. So, which one exactly did you actually use? Please check&specify.

friederschrempf‌ ,

The issue you're reporting is not the known one. This might be possible specific (or even bug) of the i.MX6ULL Boot ROM code. Please give me some time to check it on my i.MX6ULL EVK board.

Best Regards,
Artur

0 Kudos
1,661 Views
shivanipatel
Senior Contributor II

The i.MX6UL EVK CPU Board is of SCH-28617 REV C1 and i.MX6ULL EVK CPU Board is of SCH-29364 REV A.

Regards,

Shivani

0 Kudos
1,661 Views
friederschrempf
Contributor IV

Thanks for investigating. I also suspect a bug/feature in the BootROM code of i.MX6ULL, as the very same software runs fine on i.MX6UL.

0 Kudos
1,661 Views
shivanipatel
Senior Contributor II

Hi, Frieder Schrempf 

I have tried to boot from QSPI on i.MX6UL-EVK & i.MX6ULL-EVK which has hardware revisions of SCH-28616 REV C1 & SCH-28616 REV C2 respectively.

I have used MFGTool of version L4.9.88, taken from this link to flash the image on QSPI.

I have followed the below mentioned steps to boot the boards (both  i.MX6UL-EVK & i.MX6ULL-EVK) from QSPI.

  • Flash the image on QSPI by running mfgtool2-yocto-mx-evk-qspi-nor-n25q256a.vbs script.
  • Load zImage, DTB file and rootfs using TFTP. (refered this link)
  • Boot the boards from QSPI. Boot Switch Configurations are SW602 - ON OFF and SW601 - OFF OFF OFF OFF

I am able to boot from QSPI on both i.MX6UL & i.MX6ULL EVKs and being able to detect the QSPI in Linux see the below sceenshot.

qspi.png

I also checked the QuadSPI_FLSHCR register value. It is same for both boards.

=> md.l 0x021e000c 1
021e000c: 00010303

Are you facing the issue on i.MX6UL & i.MX6ULL EVK boards?

If not then can you please check it first on EVKs?

Let us know your observations. It would be helpful if you provide the steps to boot the board from QSPI.

Regards,

Shivani

0 Kudos
1,661 Views
friederschrempf
Contributor IV

Thanks for looking at this issue. I see this issue on custom boards with i.MX6ULL. I don't have EVK boards to reproduce.

Steps:

  • Generate U-Boot image and prepend with QSPI header
  • Using Linux to copy image to NOR flash
  • Set OTP fuses to QSPI-Boot
  • Boot from QSPI
0 Kudos
1,661 Views
shivanipatel
Senior Contributor II

Okay. As per my investigation, this behaviour has not been seen on EVK boards.

So as Artur Petukhov said, it might be possible specific (or even bug) of the i.MX6ULL Boot ROM code.

Regards,

Shivani

0 Kudos