topic Re: imx6ULL Custom Board booting from NAND flash in i.MX Processors

imx6ULL Custom Board booting from NAND flash

iancaddy — Sat, 05 Jan 2019 06:10:09 GMT

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)?

Re: imx6ULL Custom Board booting from NAND flash

Yuri — Wed, 16 Jan 2019 05:05:39 GMT

Hello,

Please look at my comments regarding the issue.

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.

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!

Re: imx6ULL Custom Board booting from NAND flash

iancaddy — Wed, 16 Jan 2019 08:56:09 GMT

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.

Re: imx6ULL Custom Board booting from NAND flash

Yuri — Thu, 17 Jan 2019 06:36:21 GMT

Hello,

the following Community discussion contains information how

to interpret the log. It may help.

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

Regards,

Yuri.

Re: imx6ULL Custom Board booting from NAND flash

iancaddy — Fri, 18 Jan 2019 07:38:40 GMT

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?

Re: imx6ULL Custom Board booting from NAND flash

arekkaras — Fri, 26 Apr 2019 12:56:12 GMT

Hi Ian,

did you solved your issue ?

Regards

Re: imx6ULL Custom Board booting from NAND flash

iancaddy — Sun, 28 Apr 2019 06:35:12 GMT

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

Re: imx6ULL Custom Board booting from NAND flash

arekkaras — Tue, 30 Apr 2019 05:35:06 GMT

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>

Re: imx6ULL Custom Board booting from NAND flash

arekkaras — Thu, 30 May 2019 18:31:13 GMT

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 · GitHub

Regards

Arek

Re: imx6ULL Custom Board booting from NAND flash

iancaddy — Fri, 31 May 2019 00:35:36 GMT

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.

Re: imx6ULL Custom Board booting from NAND flash

iancaddy — Wed, 12 Jun 2019 06:25:31 GMT

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.