imx6ULL Custom Board booting from NAND flash

[iancaddy]

Hi All,

We hve a custom board based on the imx6ULL processor.  We are using u-boot and *not* a linux kernel, but an RTEMS kernel.  We have been using the JTAG interface to download and test the code.  Now we want to put u-boot into the NAND flash to boot.

I have tried various methods and in the end have settled for adding a imx-kobs command to u-boot to allows us to program the NAND flash directly from u-boot as we do not have a linux kernel setup for our custom board.

This was slightly complicated by the fact that the u-boot that I am using does not support writing to raw NAND, but only through the ECC, so I had to create a raw command to write the FCB page.  The other pages I have placed through the normal MTD interface.

This seems to work OK, but on reboot, nothing happens and u-boot does not start.  I have looked at a bunch of issues getting NAND flash to boot for custom boards here, sometimes even using the linux tool, but that is not an option for us.

Here is an output of the nand info command on the board:

nand info

Device 0: nand0, sector size 128 KiB
  Page size       2048 b
  OOB size          64 b
  Erase size    131072 b
  subpagesize     2048 b
  options     0x40004200
  bbt options 0x00068000

Here is the output from our kobs (equiv) command:

Saving the store u-boot image @ 0x82000000, size = 0x00088000 to NAND Flash

Updating Boot control blocks
Progammed FCB Header:
  u32Checksum = 0xfffffbf9
  u32FingerPrint = 0x20424346
  u32Version = 0x01000000
  NANDTiming.u8DataSetup = 80
  NANDTiming.u8DataHold = 60
  NANDTiming.u8AddressSetup = 25
  NANDTiming.u8DSAMPLE_TIME = 6
  NANDTiming.u8NandTimingState = 0
  NANDTiming.u8REA = 0
  NANDTiming.u8RLOH = 0
  NANDTiming.u8RHOH = 0
  u32DataPageSize = 2048
  u32TotalPageSize = 2112
  u32SectorsPerBlock = 64
  u32NumberOfNANDs = 0
  u32TotalInternalDie = 0
  u32CellType = 0
  u32EccBlockNEccType = 4
  u32EccBlock0Size = 512
  u32EccBlockNSize = 512
  u32EccBlock0EccType = 4
  u32MetadataBytes = 10
  u32NumEccBlocksPerPage = 3
  u32EccBlockNEccLevelSDK = 0
  u32EccBlock0SizeSDK = 0
  u32EccBlockNSizeSDK = 0
  u32EccBlock0EccLevelSDK = 0
  u32NumEccBlocksPerPageSDK = 0
  u32MetadataBytesSDK = 0
  u32EraseThreshold = 0
  u32BootPatch = 0
  u32PatchSectors = 0
  u32Firmware1_startingSector = 512
  u32Firmware2_startingSector = 960
  u32SectorsInFirmware1 = 272
  u32SectorsInFirmware2 = 272
  u32DBBTSearchAreaStartAddress = 256
  u32BadBlockMarkerByte = 1999
  u32BadBlockMarkerStartBit = 0
  u32BBMarkerPhysicalOffset = 2048
  u32BCHType = 0

Progammed DBBT Header:
  u32Checksum = 0x00000000
  u32FingerPrint = 0x54424244
  u32Version = 0x01000000
  u32Res = 0x00000000
  u32DBBTNumOfPages = 0x00000000
Writing u-boot image from block 8 to 14
Writing u-boot image from block 15 to 21

U-Boot write completed successfully.

I have checked all the pages and the correct data appears to be in place.  I have checked the FCB (page 0) and used the correct ECC version from the kobs command for the imx6ULL and it appears to get through the FCB portion as the NAND CE is different to when I have a blank flash (or an incorrectly formatted FCB page).

There does not appear to be any useful information on how to debug this other than I found these questions:

NAND BOOT fail on iMX6UL 

i.MX6Q NAND boot issues 

The second one was referenced from one I have misplaced for the moment.  So, I put the JTAG back on after a reset and on the imx6ULL the reference manual states the BOOT ROM Log Buffer Pointer is located  @ 0x01E0, so I got that location and printed out the 256 bytes that it points to, and here is the information, but I have no information on how to decode it.  Any suggestions?

(gdb) x /x 0x1e0
0x1e0:  0x00901d14
(gdb) x /64x 0x901d14
0x901d14:       0x000e0000      0x00010002      0x000200f0      0x00030000
0x901d24:       0x00040000      0x00050001      0x00060000      0x00070000
0x901d34:       0x000700f0      0x00080000      0x000003c0      0x000800f0
0x901d44:       0x00090000      0x000a2233      0x00061fff      0x00062001
0x901d54:       0x00070000      0x00070033      0x000c0000      0x00000000
0x901d64:       0x00000000      0x00000000      0x00000000      0x00000000
0x901d74:       0x00000000      0x00000000      0x00000000      0x00000000
0x901d84:       0x00000000      0x00000000      0x00000000      0x00000000
0x901d94:       0x00000000      0x00000000      0x00000000      0x00000000
0x901da4:       0x00000000      0x00000000      0x00000000      0x00000000
0x901db4:       0x00000000      0x00000000      0x00000000      0x00000000
0x901dc4:       0x00000000      0x00000000      0x00000000      0x00000000
0x901dd4:       0x00000000      0x00000000      0x00000000      0x00000000
0x901de4:       0x00000000      0x00000000      0x00000000      0x00000000
0x901df4:       0x00000000      0x00000000      0x00000000      0x00000000
0x901e04:       0x00000000      0x00000000      0x00000000      0x00000000

regards,

Ian Caddy

P.S Does anyone know why there is no Category for the imx6ULL (the closest I can find is the imx6UL)?

[iancaddy]

Hi,

No this has not been resolved yet.  For the interim, we had a footprint for a uSD card and we got it booting through that mechanism so we currently require a uSD card for boot, then everything else that we control is on the NAND flash .

It is on our list to get back to this issue as we would like to remove the uSD card for production units.

regards, Ian Caddy

[arekkaras]

Hi,

I am working now on similar topic - I need to program complete NAND

flash from u-boot.

Unfortunately, complete FCB structure is not well documented in iMX6ULL

reference manual.

I did some reverse engineering from imx-kobs source code and found

following:

BOOT ROM expects first NAND flash page with FCB in format:

metadata - 32 bytes

ECC block size - 128 bytes

ECC BCH - 40 bits

number of data blocks - 8

galois field: 13

In kobs they use software BCH library to calculate ECC, but I want to

use BCH hardware to do this.

Of course, parameters given above are needed for FCB block.

Other pages can have different ECC settings, and this must be

accordingly configured in FCM

Hope it helps,

Regards

Arek

W dniu 29.04.2019 o 03:42, iancaddy pisze:

>

NXP Community

<https://community.freescale.com/resources/statics/1000/35400-NXP-Community-Email-banner-600x75.jpg>

>

Re: imx6ULL Custom Board booting from NAND flash

reply from Ian Caddy

<https://community.nxp.com/people/iancaddy?et=watches.email.thread> in

/i.MX Processors/ - View the full discussion

<https://community.nxp.com/message/1144725?commentID=1144725&et=watches.email.thread#comment-1144725>

>

[arekkaras · Accepted solution]

Hi Ian,

if you are still looking for solution, here is my patch to u-boot with simplified version of kobs tool, just for imx6ul processors:

SOMLABS: Add minimal implementation of IMX kobs-ng tool. · SoMLabs/somlabs-uboot-imx@23f402f · GitHu... 

Regards

Arek

[iancaddy]

Hi Arek,

I finally got back to look at this today, dropped in your code, and changed the couple of config files and it compiled fine (once I removed my failed code).  Ran it and tried it and it worked perfectly. We now have u-boot booting from NAND instead of SD card which will make things much simpler.

Thanks so much for this.

Best Regards,

Ian C.

[iancaddy]

Hi Arek,

We have not got back to this, but will definitely look at your solution, thanks very much.  I will probably try to get back to this in the next couple of weeks.

Regards,

Ian C.

[Yuri]

Hello,

  Please look at my comments regarding the issue.

1.

  Try to analyze HAB boot log just after boot crash, without system reset.

Boot ROM/HAB allocates certain memory region in Internal RAM (OCRAM) for HAB logs. For i.MX6 the log is located starting from address 0x904000, length 0xB8.

2.

  Please refer to the following resources regarding i.MX6 NAND using:

How-To use NAND boot on i.MX6UL EVK board 

Booting from NAND flash on i.MX6-based platforms - DAVE Developer's Wiki 

  Also, customers can use section 3.4 (NAND GPMI Flash) of “i.MX_Reference_Manual.pdf”

in the recent NXP Linux BSP in order to use Linux sources as an example.

 https://www.nxp.com/webapp/Download?colCode=L4.14.78_1.0.0_LINUX_DOCS 

Have a great day,

Yuri

------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer

button. Thank you!

[iancaddy]

Hi Yuri,

Thanks for the response.  Referring to point 1:

1. The problem with the JTAG is that to get control we need to perform a reset, but with our hardware configuration, the ROM bootloader starts (as I can see the NAND flash chip accesses, 2 lots of 4 CEs) before the debugger gets control after a reset.  This looks identical on the scope if I have a debugger connected and perform a reset, or if I power on the board with no debugger in place, so I assume that this should be after the bootrom has tried to startup from the NAND.

Here is the 256 bytes from the memory location 0c904000 like you have asked:

(gdb) x /64x 0x904000
0x904000:    0x4214000c    0x00000033    0x0000000a    0x00000000
0x904010:    0x00000000    0x42080009    0x00006d87    0xe1200003
0x904020:    0x000000ff    0x00000005    0x00000000    0x00000000
0x904030:    0x00000000    0x00000000    0x00000000    0xed140003
0x904040:    0x0000001e    0x00000001    0x00904050    0x00000000
0x904050:    0x711400ed    0x806ffbb6    0x00000000    0x00000020
0x904060:    0x5a1e3e00    0x420c0005    0x00000001    0x00000000
0x904070:    0x420800db    0x000a2233    0x42080b00    0x23488984
0x904080:    0x28650f22    0xe7aa5dee    0x128c220d    0xfd7459ef
0x904090:    0x4b501413    0x95e06f5b    0xae802000    0xb5cdfff3
0x9040a0:    0xb28deffd    0x29465000    0xdfbede6d    0x030ac885
0x9040b0:    0xd9337fab    0x4548c218    0xc4d3674b    0xb22a0800
0x9040c0:    0x0109b0c2    0xcefbfefd    0x6d8123f1    0xfef5ec75
0x9040d0:    0x90206602    0xe701ceea    0x6c580413    0xee1fcde2
0x9040e0:    0xc42f77ff    0x5e120188    0xbdb79973    0x81804f50
0x9040f0:    0xfb1ffefe    0x0234002b    0xf8c2fb7e    0x19c10906

Here is the information from address 0x80 which is supposed to be the ROm Version and Copyright information:

(gdb) x /32x 0x80
0x80:    0x00000011    0x79706f43    0x68676972    0x43282074
0x90:    0x30322029    0x322d3631    0x2c373130    0x50584e20
0xa0:    0x6d655320    0x6e6f6369    0x74637564    0x202e726f
0xb0:    0x206c6c41    0x68676972    0x72207374    0x72657365
0xc0:    0x2e646576    0x20202020    0x00002020    0x00000000
0xd0:    0x00000000    0x00000000    0x00000000    0x00000000
0xe0:    0x00000000    0x00000000    0x00000000    0x00000000
0xf0:    0x00000000    0x00000000    0x00000000    0x00000000

Does the abovelog  look better for you? 

I thought I needed to provide the log from the log buffer pointer, which for the imx6ULL that we are using (according to the reference manual) contains the log buffer pointer at 0x1E0, which points to the memory I showed in my initial report.

Can you provide any information on how we are supposed to interpret this HAB boot log?

2. We have been through the above information and many more, but since the NAND boot sequence has a number of steps we are trying to hone in on which step is failing.

We have verified that we can download our u-boot.imx image using the imx_usb tool, so we have confirmed that our DCD seems to be correct, so we guess that it is failing somehow on the FCB or the Bad Block Table (which is empty), but a hint of hint of what the BootROM thinks is invalid would be a great help.

regards,

Ian C.

[Yuri]

Hello,

  the following Community discussion contains information how 

to interpret the log. It may help.

https://community.nxp.com/message/992026 

Regards,

Yuri.

[iancaddy]

Hi Yuri,

Thanks for the information, I overlooked that PDF document about the enums before, so this gives us a starting place.  Here is my decoding of the original request:

0x901d14:
0x000e0000  - I am not sure what the first parameter is
0x00010002 - ROM_LOG_BOOTMODE_INTERNAL
0x000200f0  - ROM_LOG_SEC_CONFIG_OPEN
0x00030000 - ROM_LOG_DIR_BT_DIS_VALUE0
0x00040000  - ROM_LOG_BT_FUSE_SEL_VALUE0
0x00050001 -  ROM_LOG_SEC_IMAGE_SELECT
0x00060000  -  ROM_LOG_PRIM_BOOTDEVICE_NAND
0x00070000 - ROM_LOG_DEVICE_INIT_CALL
0x000700f0  - ROM_LOG_DEVICE_INIT_PASS = 0x000700F0
0x00080000  - ROM_LOG_DEVICE_READ_DATA_CALL = 0x00080000
0x000003c0 - Not sure what the 0x3c0 parameter standard for but it is 960 which could be the read length for the FCB?
0x000800f0 - ROM_LOG_DEVICE_READ_DATA_PASS
0x00090000  - ROM_LOG_AUTHENTICATION_STATUS = 0x00090000
0x000a2233  - Not sure what the next 3 parameters are
0x00061fff -  ROM_LOG_REC_BOOTDEVICE_NONE
0x00062001 -  ????
0x00070000 - ROM_LOG_DEVICE_INIT_CALL
0x00070033 - ROM_LOG_DEVICE_INIT_FAIL
0x000c0000 - ROM_LOG_SDP_ENTRY

And this is where the log stopped.

So, it looks like the first read was a success, but the second read failed, maybe.  There is not enough information here to be able to work out what went wrong without more information.

We tried messing up the fingerprint on the FCB and this changed to the first read failing, rather than the second read.

We have also tried changing the m_u32DBBTSearchAreaStartAddress = 0 which according to the documentation should assume there are no bad blocks in the boot area, and the output did not change from above.

I carefully read through the other problem report you referenced, and I am not sure what lives at 0x907400 and you asked me to print out 0x904000, can you provide more information on what these memory locations provide?

Are there any more clues for us?

[arekkaras]

Hi Ian,

did you solved your issue ?

Regards