DM6467 NAND boot

libin said:

1. Can DM6467 revision 1.1 boot from NAND flash? Or it just can not boot from NAND02G-B2D?

2. How does RBL check the UBL signature? Will it load the UBL signature to 0x00000020 and check from there?

3. If Our design is workable, why RBL does not copy UBL to 0x00000020 and boot from there?

1. Yes silicon rev 1.1 will boot from NAND Flash; if your NAND device is listed in the table of supported Device IDs (see SPRAAS0C you referred to), then you should be ok

2. RBL checks UBL signature prior to loading to IRAM at address 0x00000020; the fact that you are seeing this only when UBL is in block 5 may be a sign that your NAND device has bad blocks in blocks 1-4, however, it is also a good sign that it recognizes your NAND device ID.

3.  If you are seeing your UBL signature at 0x00000020, it is probrably copying it there (at least partly).  It can have problems if 1) it finds errors in UBL or 2) UBL has not been modified to work with the new NAND device.

Thank you very much, Juan. This is very helpful.

I will check the NAND addressing. Block 0 to Block 4 ought to be fine since the nand programmer can write and read back.

So in IRAM, from 0x00000020, it should be the UBL signature. The UBL itself will be copied to somewhere else in IRAM. Is this correct? We have thought that after RBL checked the magic number, it will copy the UBL to 0x00000020 and execute from there.

UBL could be the problem. But I think it should be able to send out "Booting PSP Boot Loader" if it is fully loaded to IRAM.

If UBL is not fully coped to IRAM, what could be the reason? Will the serial port still send out BOOTME in this case?

Thanks,

Libin

I utilized the source code from DM355 nand flash programmer and tried again. The result is the same. But I feel that nand flash addressing is not the problem.

I can see that RBL will load the whole page to IRAM starting from 0x00000020, from nand flash block 5 page 0. This page contains the UBL signature.

Where will RBL load the UBL which is in nand flash starting from block 5 page 1?

libin,

Apologize for the delay, please note that UBL signature is part of UBL itself, hence we know that at least to copy process started and UBL was being transferred to IRAM; I am not sure what would cause it to stop of all a suden, but it RBL cannot successfully load UBL, it will fall back to UART boot mode you will see BOOTME messages. 

Have you tried this on our DM6467 EVM (as opposed to your own board)?  Just as a sanity check to make sure the steps you are following work in a known good platform.

I can see that UBL signature(page 0 of block 5) is loaded into IRAM starting from 0x00000020. But we do not know where will RBL put UBL. UBL on NAND flash starts from page 1 to page 7 of block 5.

If we know where RBL will load UBL, we can compare it and know better what is going on.

Unfortunately we do not have the EVM for DM6467. We only have the EVM for DM355 and DM6446.

In DM6467, UBL is normally placed in the range from 0x00000020 to 000074FF: see  http://focus.ti.com/lit/an/spraas0c/spraas0c.pdf for more details.

DM6446 NAND boot should be very similar to DM6467; I would try the steps in the DM6446 as a sanity check.

hi Juan, I just want you know that we have solved the problem. Now it can boot from nand flash. It is all about the RBL ECC of the nand flash.

Libin,

This is great news; thank you for posting solution back to the community.

hi,

I am facing similar issue of having the UBL executing from NAND.

could you let us know what is the work around.

regards,

Victor

In DM6467 nand programmer code, you have to enable the ECC when programming the flash. Basically it is to calculate the ECC and write it to flash. Different page size has to be treated differently. DM355 nand programmer is a good reference. The datasheet of DM6446 has the detail for nand controller and how to write ECC. What's happening is that RBL will check ECC when loading UBL from nand flash. It will abort if there is ECC error. This is why we always saw the 5th page is loaded into RAM if ECC is not enabled.

thanks for the reply.

I have eanbled the ECC at nand programmer code and still see the issue,

could you let us know on  the following.

1. different page size to be treated differently.  our understanding, this is wrt to the nand device and its  page info.(we are taking care)

2. we are exactly seeing the indication by you i.e "5th page is loaded into RAM".: in this case will it be possible, for us to know some more details on the nand programmer code used and the ECC specific changes that are needed to be taken care.

1. NANDFCR

2. Uint32 _NAND_write8( Uint32 tx, Uint32 use_ecc )

3.sprue14b.pdf p.132:

As stated previously, when the RBL reads NAND memory pages, it attempts to verify a correct read by checking the ECC values. For every 512 bytes read from the NAND, the EMIF interface generates an ECC value in the NANDFnECC register of the AEMIF peripheral. The RBL compares this value against the value stored in the spare bytes of the NAND page it is reading. These stored values should be placed in the spare bytes region when the page is written. Therefore, any program that writes a UBL header and UBL binary to the NAND flash must know where the RBL looks for the stored ECC values when it tries to load the UBL.

The exact location of where the RBL expects to find the stored ECC depends on the page size of the device. For 256-byte/page and 512-byte/page devices, the ECC value is stored in the first four bytes of the spare byte region (see Table 12-1 and Table 12-2). For 2048-byte/page devices, there are four ECC values (Table 12-3), one for each set of 512 bytes read, which should be stored at addresses 8h, 18h, 28h, and 38h of the spare bytes region. The 32-bit ECC values should be in big-endian order. The provided example UBL respects these ECC requirements, as can be seen by inspecting the source file, nand.c.

HI Libin and Juan,

I am also facing a similar issue.

Any help will be really appreciated.

I have posted the issue in detail at the below mentioned link.

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/99/t/233348.aspx

Regards

Ayusman