imx6ul does not boot anymore with mask revision 2N52P

[db42]

Due to changes in the boot rom, the size of the image in the boot data structure seems not to be used.

Only 4kB is loaded from nand. Our bootloader code works on all imx6 variants, this is the first processor where is does not work.

Is this the "ROM modification change to help with overall device performance improvement" ? Faster booting by only loading 4kB?

[apines]

We have this issue as well and the behavior is as Daniel describes it -- regardless of the value of the length field the MCIMX6G2DVM05AB, mask 2N52P, date code 1734 loads the initial 4kB from the SD Card then doesn't seem to load anything further (it works fine on MCIMX6G2DVM05AA, mask 1N52P).  ERR011115 mentions a problem with the boot loader on this variant but not quite this problem.  Was this issue resolved at the same time as ERR011115 with MCIMX6G2DVM05AB, mask 2N52P, date codes 1740 and later?  Is there something different about the Image Vector Table and Boot Data structures from what's described in section 8.7 of the reference manual?  We haven't found any of post-1740 date coded parts yet so we haven't been able to test that.

[igorpadykov]

had problem processor passed ddr test and proper dcd header

was used with new ddr settings ?

[apines]

Hi, Igor, thanks for the reply.  It has no DCD header, nor should it need one.  See IMXULRM.pdf, Section 8.7.1.1, Table 8-26: "The DCD is optional so this field may be set to NULL if no DCD is required".  I'm loading the image directly into OCR, not into DDR.  ERR011115, noted above, mentions that "User should set the boot image start address greater or equal to 0x908000 (if the boot image running in OCRAM) to prevent the boot failure when using the SD/eMMC/SPINOR boot devices".  I have it set to 0x908000.  I dug a bit deeper and can verify using both an oscilloscope and JTAG that it's correctly loading the first eight sectors (4kB) from the card into OCR then it stops reading from the card.  I also verified that it does jump to the correct entry address because if I use JTAG to load the portions of the image that the bootloader is failing to load then reset the board it loads the first 4kB, jumps to my code, and my code starts running.  Any insights you can provide would be appreciated.

[db42]

You have to set the "start" value in the Boot Data Structure to 0x908000 or higher. This value is used to copy the code from NAND to IRAM. The "entry" value in the IVT has to be changed accordingly.

I have tested this on datecode 1715 and it worked.

[apines]

This took care of it.  The errata says the BSP is not affected but I had to change CONFIG_SPL_TEXT_BASE in imx6_spl.h from 0x00908000 to 0x00909000 to make it work.  Maybe there's a more recent BSP which deals with it correctly.  Thanks for the feedback; hopefully no one else will get jammed by this.

[ranjithhebbar]

Changed  CONFIG_SPL_TEXT_BASE in imx6_spl.h from 0x00908000 to 0x00909000 to boot SPL normal image. But trying to do the SPL signed image with HAB it is failing. Anyone have tried this in 2N52P.

[bernhardfink]

Just to complete this thread, here is the final outcome:

Here is a quick Summary for the 6UL boot issue. An errata has been created, the details of which are below. A ROM patch has been identified and validated, the start of this production is set for Sept 22 2017.

The date code will be the only way to differentiate the material, as no other part number or hardware register will be changed.

Errata: ERR11115 ROM: Failures when using a specific boot image start address for SD/eMMC/NAND/SPINOR boot 

SW Workaround: For SD/eMMC/NAND/SPINOR boot, set the boot image start address greater or equal to 0x908000. 

Fix: There is a ROM patch to fix the issue on i.MX 6UL Rev 1.2. With the patch, the entire OCRAM range can be used (again) starting at 0x907000.

Identification: Devices with the ROM patch will be identified with an effective date code, later than 9/22/2017

Other devices impacted:  please look into the errata documents of the respective devices
6SLL 
7D

[igorpadykov]

Hi Daniel

"ROM modification change" will not help with overall device performance improvement,

it just fixed  erratum ERR010690 SNVS LP (backup battery domain) reset bug during power up / power down.

http://www.nxp.com/docs/en/errata/IMX6ULCE.pdf 

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------