Can't boot custom DM814x board from MT29F8G16 NAND

Hi Daniel,

For 16-bit NAND chip, can you try with the following switch (boot pins) configuration:

SW1[11:0] = 000010010010 - this corresponds to BTMODE[11:0]

SW2.NAND = 1

Can you also attach a log file with the console message output when you try to boot from NAND.

Regards,

Pavel

Pavel,

> SW1[11:0] = 000010010010 - this corresponds to BTMODE[11:0]

I already had this setting when CONTROL_STATUS = 0x00010312.  However, I did the same hardware mods to change my BTMODE pull-ups again on a second board, and got better results:

- Attempt to boot from NAND fails.  No need for log file, the only output is "CCCCCCCCCCCCCCC...".

- When this happens, I used TeraTerm's Xmoden send function to send "u-boot.min.nand".  The min program was then able to boot the 2nd-stage u-boot.bin with no issue.  (I.e., no "ECC: uncorrectable.")

So, I must have bad solder connection on my first board, fixed on my second board.  But the ROM code still cannot boot the 1st-stage min u-boot.

To get NAND access to work from u-boot, I had to change ECC layout (due to 4kB pagesize and larger OOB area usage).  What about the ROM code - is it prepared for such a setup?

Dan -

Hi Dan,

For 4096 bytes + 224 spare bytes NAND, we have info that it is supported, but the SW should be modified:

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/p/179173/654961.aspx

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/100/t/55641.aspx

You can also check the following wiki pages, which describes how the ROM code works with NAND:

http://processors.wiki.ti.com/index.php/Davinci/Sitara/Integra_Nand_Boot_FAQ

http://processors.wiki.ti.com/index.php/Determining_compatibility_between_ROM_Bootloader_%28RBL%29_and_Raw_NAND_devices

http://processors.wiki.ti.com/index.php/Raw_NAND_ECC

Also note that on the DM814x EVM, there is a dedicated switch for NAND enable/boot. This is SW2.1, which should be ON. The signal connected to this switch is NAND_BOOTn, which is related to the GPMC_nCS0 signal and finally enable the NAND Flash in CE pin.

We have some linux kernel patches created recently:

http://arago-project.org/git/projects/?p=linux-omap3.git;a=commit;h=243977171ae666f012cc38c76e28bc0fe3d532f5

http://arago-project.org/git/projects/?p=linux-omap3.git;a=commit;h=45fc6a799471a0b85b807b14b7f3bf0977dd2bc3

http://arago-project.org/git/projects/?p=linux-omap3.git;a=commit;h=976d48c63a2d1a22f26832883ebafbbfbe7f9b8d

I hope this will be in help.

Regards,

Pavel

Pavel,

The "RBL UBL and host program" wiki page says:

If the RBL can't get a successful read out of the first five blocks, the boot will fail and will default to attempting a UART boot. One recommendation would be to fill the first five blocks with the same header and UBL. Then if the first one ever goes bad, you'll already have four more copies ready to do the job. But if all five of those blocks go bad (which I think is VERY unlikely over the lifetime of the device) then the device won't boot.

Is it correct that, in this context, the five "blocks" means five 256kB blocks (since MT29F8G16 has 256kB erasesize)?

Still, I don't think this particular point will help, since uboot and linux both concur that page 0 (with min uboot loader) are okay.  (But it is good to know for actual manufacturing.)

I'll apply the kernel patches on Monday - but again, I doubt that they will help with getting RBL to work, since my problem is much earlier.

With regards to SW2, yes, I am aware of it on the EVM.  But I'm not using the EVM, I'm using a custom board.  My recollection is that SW2 is used for choosing if GPMC's CS0 goes to NAND or SPI FLASH.  Our CS0 goes to the NAND.  And it must be okay, since we can read from and write to NAND, yes?

Can you tell me if the RBL should be expecting 128 byte oob size (as calculated by TI's uboot), or the real 224 byte total spare area?  I was thinking that it should not matter, since actual count of bytes used by ECC is less than 128.  However, I guess that we can still force the ECC layout in uboot to set up a larger oobfree block to know about the whole 224 byte area.  But it's just more unused bytes left at FF, right?

Dan -

Pavel,

I tried writing the u-boot.min.nand to five locations with the following lines:

mw.b 0x81000000 0xFF 0x200000
tftpboot 0x81000000 u-boot.min.nand
tftpboot 0x81040000 u-boot.min.nand
tftpboot 0x81080000 u-boot.min.nand
tftpboot 0x810c0000 u-boot.min.nand
tftpboot 0x81100000 u-boot.min.nand
nand erase 0x0 0x200000
nand write.i 0x81000000 0x0 0x200000

However, I still just got the uart CCCCCCCCC on the boot line ...

I also tried writing the image from linux using the three patches that you mentioned above, using flash_erase and nandwrite, but I got the same bad result.

Can you give me any other ideas?

Dan -

Hi Dan,

I requested help from our ROM Code and NAND driver experts. I will come back to you when I have something. Sorry for the delay.

BR,

Pavel

Meanwhile, I found that thread:

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/137886/518553.aspx

Do you have other board connected that may cause that issue?

Can you try with BTMODE[4:0] = 10100, thus we will remove the UART from the list.

Regards,

Pavel

Also, these are the official steps (and order) to burn the u-boot.min.nand to NAND flash:

TI8148_EVM# nand erase 0x0 0x20000 <=== Erasing the whole partition before flashing the image
TI8148_EVM# tftp 0x81000000 u-boot.min.nand
TI8148_EVM# nand write.i 0x81000000 0x0 0x20000

Can you try with these.

BR,

Pavel

Pavel,

> Do you have other board connected that may cause that issue?

No, there is no other board.  Plus, the thread that you found guesses that the problem was, "I guess connecting Expansion board disables nand flash."  But I can read and write to the FLASH.  So I think that is not the issue.  I think that RBL is either not finding UBL header in NAND, or it is doing ECC calculation differently than u-boot and kernel.

> Can you try with BTMODE[4:0] = 10100, thus we will remove the UART from the list.

With these settings, I get nothing on the serial port output, and the board does not appear to boot.

Dan -

Pavel,

I have 256 kB erasesize, so I have to use 0x40000, not 0x20000.

Otherwise, these are the same steps as I have already been using, except you are erasing NAND before TFTP'ing to DRAM.  I tried anyway - erasing the NAND before doing TFTP did not work.  I tried with my original boot setting and with BTMODE[4:0] = 10100.

Dan -

And what is the size of your u-boot.min.nand image?

The ROM code loads the u-boot-min image from NAND flash to OCMC RAM. OCMC RAM is 128KB, out of which 18KB at the end is used by the ROM Code. U-Boot also requires some space for the stack, heap and global data during executing and this region currently needs to be setup. So the size of the u-boot.min.nand should be less than 110KB.

BR,

Pavel

Pavel,

My u-boot.min.nand is 93 kB (94548 bytes).  Further, I can write my custom board's u-boot.min.nand into the DM814x-EVM's NAND, and then the EVM will boot okay.  (I guess that, min-wise, they are about the same?)  So, yes, it is less than 110 kB.

Dan - 

In the below link, we have a flow to get the NAND correctly initialized and detected:

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/224695/791185.aspx#791185

Could you please check it.

Best Regards,

Pavel

Yes, I've gone through that.  At all that is working.  Both uboot and linux recognize the NAND FLASH, and let me read from and write to it.

The only thing that give me pause is point 1, about the timing.  But then, my problem is not in the kernel, it is initial boot-up.

Hi Dan,

This is the feedback from our ROM Code expert:

Question: Could you please advice if the DM814x ROM Code supports this type of Micron NAND flash?

Answer: Yes, it does, but for some NAND Micron flashes the ONFI parameter page is corrupted which leads to some issues. Makig it unbootable. Please use u-boot to check if the ONFI parameter page is ok.

Regards,

Pavel

Pavel,

This is a little difficult to communicate, but here goes:

- READ ID

As I said in my initial post, I tried to do READ ID with address 0x20 in both u-boot and kernel.  It is supped to be 'O' 'N' 'F' 'I' (= 0x4f 0x4e 0x46 0x49), but instead I get 0x2C 0xC3 0x90 0xE6.  The DM814x TRM (sec. 4.7.3.2) says:

• Device detection and parameters. .... The ONFI Read ID (command 90h / address 20h) is sent to the NAND device. If it replies with the ONFI signature (4 bytes) then a Read parameters page (command ECh) is sent.

• If the parameters page does not have the ONFI signature, then the ONFI identification fails and the device falls back to using the look up table.  ....

So I guessed that the DM814x ROM code gets the same failure, and checks the look-up table. Device ID 0xC3 is in the Supported NAND Devices table in the DM814x TRM (table 4-14). And, there is an 0xC3 entry in the table in u-boot, named "NAND 1GiB 3,3V 16-bit".

- READ PARAMETER PAGE

In kernel, I bypassed the READ ID / 0x20 check described above, to get kernel to read the ONFI parameter page anyway. ONFI parameter page should also start with 'O' 'N' 'F' 'I' (= 0x4f 0x4e 0x46 0x49).  At first, this failed, because kernel was reading with 16-bit access.  So I got  0x4f 0x00 0x4e 0x00 0x46 0x00 0x49 0x00 ..., and CRC16 check failed.  So I changed kernel's drivers/mtd/nand/nand_base.c's nand_flash_detect_onfi() to always use the 8-bit read function nand_read_buf() instead of registered chip->read_buf() function (which is set to nand_read_buf16() due to 16-bit bus width).  Then I got valid parameter page data - and kernel's CRC16 check also passed:

0x4f 0x4e 0x46 0x49 0x02 0x00 0x19 0x00
0x3f 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x4d 0x49 0x43 0x52 0x4f 0x4e 0x20 0x20
0x20 0x20 0x20 0x20 0x4d 0x54 0x32 0x39
0x46 0x38 0x47 0x31 0x36 0x41 0x42 0x41
0x43 0x41 0x48 0x34 0x20 0x20 0x20 0x20

What does this mean for the ROM code?

Dan -

Pavel,

I have a clarification: the specific part that we are using is: MT29F8G16ABACAH4:C

Also, I am still wondering if the ECC calculation being done by the RBL matches how u-boot and linux are doing it, after my modification. Can you please ask the ROM Code expert to review the following two postings to see if they match the ROM code's operation?

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/p/231420/815041.aspx#815041  (refers to Julien's GPMC_NAND_HW_BCH8_ECC_LAYOUT a couple posts higher)

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/p/231420/815175.aspx#815175 (how I change linux to make same ECC layout)

Thanks,

Dan -

Pavel,

Another aspect to the 4kB ECC layout.  In the TRM, there is Figure 4-15 "ECC Data Mapping for 2KB Page and 8b BCH Encoding" and Figure 4-16 "ECC Data Mapping for 4KB Page and 16b BCH Encoding".  However, there is no figure for 4kB page and BCH8.  So now I am afraid that ROM code will only use BCH16 for a device with 4kB page, and u-boot and linux will support only BCH8 ...

Dan -

Hi Dan,

This is the feedback from out ROM code expert:

It means that the NAND is on ONFI NAND – and the standard configuration used by the u-boot is incorrect, therefore the image it is writing is in a wrong format for the ROM to read. To correct this you will have to modify both u-boot and the kernel to tell them that they are interfaced with an 8  bit NAND.

This is the feedback from our NAND driver experts:

In TI81xx EVM there was a switch which would tell the kernel driver and u-boot about the bus-width of NAND part connected on it. But on custom boards such switch may not be available, So following patches may help you which will AUTODETECT_BUSWIDTH of NAND: http://e2e.ti.com/cfs-file.ashx/__key/communityserver-discussions-components-files/716/4682.0004_2D00_ti81xx_2D00_nand_2D00_fixed_2D00_detection_2D00_of_2D00_bus_2D00_width_2D00_and_2D00_version.patch

http://e2e.ti.com/cfs-file.ashx/__key/communityserver-discussions-components-files/716/5672.0005_2D00_mtd_2D00_nand_2D00_add_2D00_NAND_5F00_BUSWIDTH_5F00_AUTO_2D00_to_2D00_autodetect_2D00_bus_2D00_wi.patch

http://e2e.ti.com/cfs-file.ashx/__key/communityserver-discussions-components-files/716/5287.0006_2D00_omap3_2D00_nand_2D00_use_2D00_NAND_5F00_BUSWIDTH_5F00_AUTO.patch

http://e2e.ti.com/cfs-file.ashx/__key/communityserver-discussions-components-files/716/7610.0013_2D00_ti81xx_2D00_nand_2D00_BUSWIDTH_2D00_AUTO_2D00_DETECTION_2D00_fixed_2D00_for_2D00_all_2D00_tr.patch

Pavel,

I've tried the patches. The Micron NAND is now identified correctly as ONFI:

omap2-nand driver initializing
ONFI param page 0 valid
ONFI flash detected
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xc3 (Micron NAND 1GiB 3,3V 16-bit)
omap2-nand: detected x16 NAND flash

This information seems correct. Also, I compared the output of "mtdinfo -a" with yesterday (with my ECC layout fixes, as per previous e2e posts). The only difference is that now oobsize is reported as 224, instead of 128.

This is good news, but this did not actually result in a bootable system. I wrote u-boot.min.nand into the first sector, but found that the block got marked as bad when I wrote to NAND from linux using "nandwrite". Dumping the data, I see that the OOB block has only 14 non-FF bytes after the bad-block marker. As I said in a previous post (referenced yesterday), I think that the basic problem is that omap2.c will set non-64 page size omap_oobinfo.eccbytes to "14", but it needs the real calculation, like:

omap_oobinfo.eccbytes = info->nand.ecc.bytes * info->mtd.writesize/info->nand.ecc.size;
omap_oobinfo.eccbytes = 14 * 4096/512 = 112

And just after that, I think that the omap_oobinfo.oobfree->offset is again miscalculated, and needs a real calculation, like:

omap_oobinfo.oobfree->offset = omap_oobinfo.eccbytes + offset
omap_oobinfo.oobfree->offset = 112 + 2 = 114

When I make these changes, the NAND can then be written without marking the block as bad. However, it still will not boot.

So, I'm back to where I was yesterday, and yesterday's last two posts.
- Does the ROM code match the above changes?
- Does the ROM code use BCH8 on device with 4kB pagesize, or is it using BCH16?

BTW:

In TI81xx EVM there was a switch which would tell the kernel driver and u-boot about the bus-width of NAND part connected on it. But on custom boards such switch may not be available

Our custom board has a pull-up to emulate the EVM switch setting, and it is set for 16 bits.  I.e. BTMODE[12] = 1.

Dan -

Hi Dan,

ROM will use the maximum BCH that it can fit into the spare area.

Regards,

Pavel

Pavel,

There are 224 bytes of spare space in this part.  The TI81XX_PSP_U-Boot.pdf says that for BCH16, the number of bytes needed is:

N = B * <Number of 512-byte sectors in a page> = 26 * 4096 / 512 = 208

Are you saying that the ROM will use BCH16?

My understanding is that the EZSDK is not prepared to support BCH16:

linux:

• arch/arm/plat-omap/include/plat/gpmc.h does not define a BCH16 value for "omap_ecc".
• drivers/mtd/nand/omap2.c does not have any obvious preparation for BCH16

uboot:

• include/linux/mtd/mtd-abi.h: the "eccpos" member of "struct nand_ecclayout" is not even large enough to hold 208 bytes - it is only 128 bytes large.
• drivers/mtd/nand/ti91xx_nand.c: if you try to change to BCH16 at uboot prompt with "nandecc hw 3", then __ti81xx_nand_switch_ecc() will print "HW ECC BCH16 not supported".

If ROM must use BCH16, but EZSDK cannot use BCH16, then what is TI's solution for this case?

Dan -

Hi Dan,

This is the feedback:

Pavel,

First, thank you for confirming the ROM operation as BCH16, and that the EZSDK is unprepared for it.

I noticed that the "nandwrite" program has a "--oob" option that is described as "Image contains oob data".  Maybe we can make a first-stage image on the build machine that includes the BCH16 bytes.  Can you point me to a software ECC implementation that matches TI's BCH16 calculation?  

Dan -

Hi Dan,

I am facing the same problem as to not able to boot up from nand on my AM3874 custom board.

Have you attempt to write the MLO to the nand flash with bch16 and able to boot up successfully? Care to share?

Thanks and regards,

poh boon

Eventually, our product switched to a smaller NAND part that falls into the BCH8 category.  However, I can tell you the following:

• While developing, we used SPI flash for a while, where the boot loader was in SPI, and everything else in FLASH; then the RBL's BCH decision is not in the picture at all.  That worked, but requires an extra part, so we didn't stick with it.
• While developing, we used the NANDI2C method for a while, where 5 bytes are staged in an EEPROM that can instruct RBL to use BCH8 (which is supported by uboot and kernel).  That was okay since we have an EEPROM at that address anyway, but we didn't need to stick with it since we changed to the smaller NAND part.
• To get things to work properly, we had to heavily patch the lernel drivers/mtd drivers and arch/arm, to match the upstream Arago.  We went as high as http://arago-project.org/git/projects/?p=linux-omap3.git;a=commit;h=ab3a473b1d5f450655fd0e5bf91daa0ccb161a2f .
• Since we did that, TI has added BCH16 support to the upstream Arago.  I have not attempted to update to these.  It may work, but you would either have to add your own mods to uboot (assuming that your uboot is loading the kernel from NAND), or else do something like write the bootloader using BCH16, and write everything else with BCH8.

Good luck,

Dan -

Thanks Dan, for sharing your experience with me.

Is it alright if you can tell me the part number of the nand flash which you have scaled down?

Thanks and regards,

poh boon

I think that might be frowned on.  Just start with your part, and then look for when with 128KiB sectors ...