Another DM365 booting from Micron NAND Flash question

Jon Nicoll

Hello there

I am trying to get a DM365-based board booting from NAND Flash, with a Micron NAND Flash part. We can successfully boot this board from SD card and from SPI memory, and have u-boot and a linux kernel etc. running out of NAND Flash. It is the booting from NAND that are having trouble with. I am aware that other people are also having Device ID compatability issues with this processor and so am giving as much information as I can.

Our NAND Flash part is Micron MT29F8G08DAA-WP. This has a Manufacturer's Id of 0x2C and a Chip Id of 0xD3. Our DM365 silicon is Rev 1.2. There does seem to be differing opinion and information about whether such a device is actually supported by the DM365 RBL. We have made some close investigation of the boot process and I have some information to pass on, and some questions.

This Micron part has a block size of 0x40000, each block comprising 64 pages of 4096 bytes. At Block 1, page 0, of our flash (ie. 0x00040000) we have a UBL describer:

0xa1aced00    # FIELD 0: UBL magic number - safe mode
0x00000100    # FIELD 1: absolute start address in IRAM
0x00000008    # FIELD 2: number of pages in UBL
0x00000001    # FIELD 3: starting block Number of UBL code
0x00000001    # FIELD 4: starting page number of UBL code
# remaining locations in Block 1, page 0 filled with 0xff

and at Block 1, page 1, (0x00041000) of our flash we have the beginning of our UBL code.

The description on the NAND boot in SPRUFG5A says that:

a) if a valid UBL magic number is found, the block number where it is found is copied to IRAM address 0x7ffc)
b) The UBL code corresponding to the fields in the UBL describe are copied to IRAM, and then the absolute start address (Field 1 of the UBL describer above) is jumped to. We have been trying to follow these actions by connecting to our board via CCS once the board has failed to boot, and observing the contents of the IRAM. I am aware that this is not optimal, but here is what we are seeing:

- we see 0x00000001 at location 0x7ffc of IRAM, ie. the RBL appears to be finding the UBL magic number at block #1 of the NAND Flash (correct)
- at address 0x0020--0x0033 in IRAM, we see the whole of the UBL describer above (starting with the magic number)
- we then then see in IRAM what appears to be the rest of Block 1, page 0 (ie the remaining blank locations in block 1 above), copied to IRAM. This appears to end at around IRAM location 0x1000
- the UBL code found in the next page of our Flash cannot be seen in IRAM.

Note that the UBL describer appears to be the first thing copied, to location 0x00000020. I note that the description of NAND Flash boot mode in SPRUFG5A(pp. 169) explicitly says that the RBL will "copy the UBL [ie. not the describer] into Internal RAM, starting at 0x0000:0020".

We have performed similar examination of the IRAM after (successfully) booting via SD card. In this case we see:
- we see 0x00000008 at location 0x7ffc of IRAM, ie. the RBL appears to be finding the UBL magic number at block #8 of the SD Card (correct)
- we see in IRAM from location 0x00000020 the actual contents of the UBL. This is as we would expect from the description of MMC/SD boot (SPRUFG5A pp. 169).

I am hoping that this gives some information about what the RBL thinks the page and block size of our NAND Flash is. Specifically:

1) why is the RBL seeming to copy the UBL Describer itself, followed by the rest of that page, into IRAM?
1a) I wonder if it is possible that this is part of the action of the RBL, which would normally then be followed by a copy of the actual UBL code over the top of this? if so, perhaps this gives a clue what is happening...
2) Does the fact that the RBL appears to copy only one page imply that it is ignoring the FIELD 2 of our UBL describer, which says that our UBL has 8 pages?

FWIW we have also experimented with having a UBL magic number of 0xa1aced00, to select Legacy mode. This has made little difference to our observations.

I know that there have been considerable discussions on this forum regarding which NAND flash devices are actually supported. This thread:

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/99/p/34519/120199.aspx#120199

refers to an entry in 'device_nand.c' which includes this line:

{ 0xD3,   4096,       64,             2048+64}, // 512 MB (4th ID byte will be checked)

I am guessing that device_nand.c is part of the RBL? if so this line seems to indicate that our device should work.

Any clues about what these observations tells us, and where to go from here?

    Thanks and Regards
    Jon Nicoll

over 16 years ago

0 Gaurav Agarwal over 16 years ago

TI__Expert 3425 points

Jon,

Please note that the maximum size of UBL supported is 30 KB (As per section 11.2.1.1 of DM365 ARM Subsystem Guide, http://focus.ti.com/lit/ug/sprufg5a/sprufg5a.pdf). Looks like your UBL is ~32 KB (8 * 4K).

The entry in the ROM is similar to what you have suggested:
{(AD)D3, 64, 2048+64, 22, 5}
(Table 114, ARM SS Guide)

As per this entry, RBL interprets the page size of NAND as 2K (as compared to 4096, which is the actual page size of NAND).

Given that the flasher you are using is using the right parameters to flash the NAND, can you please try the following:
Flash the UBL from Block 1, page 1. However make FIELD 4 as 0x00000002.

As the page size interpretation is half, changing the starting page number to double might do the trick.

Please let us know how it goes.

Thanks,
Gaurav

0 Jon Nicoll over 16 years ago in reply to Gaurav Agarwal

Intellectual 320 points

Hi Gourav,

thanks for your reply. I'm away from the board at the moment (I'm in the UK); I'll try your suggestions first thing tomorrow.

Gaurav said:

Please note that the maximum size of UBL supported is 30 KB (As per section 11.2.1.1 of DM365 ARM Subsystem Guide, http://focus.ti.com/lit/ug/sprufg5a/sprufg5a.pdf). Looks like your UBL is ~32 KB (8 * 4K).

I think our UBL is less than 30k - but you have to round up to the next page, surely?

Gaurav said:

Given that the flasher you are using is using the right parameters to flash the NAND, can you please try the following:
Flash the UBL from Block 1, page 1. However make FIELD 4 as 0x00000002.

As the page size interpretation is half, changing the starting page number to double might do the trick.

OK - but won't I also have to increase the number of pages copied, if that is being interpreted as 2K rather than 4K?

Thanks

Jon

0 John Anderson over 16 years ago

Genius 5240 points

We are using the MT29F4G08AAC and it will boot. Had problems with other types refusing to boot. Would like to have a bigger NAND but finding a bigger one that works and not obsolete was a problem.

John A

0 Gaurav Agarwal over 16 years ago in reply to Jon Nicoll

TI__Expert 3425 points

Jon,

You are right. You will have to increase the number of pages accordingly.

However given that you are using CCS, you will know if your code is getting copied.

Let us know how it goes.

Regards,
Gaurav

PS: Please mark this post as answered via the Verify Answer button below if you think it answers your question. Thanks!

0 Jon Nicoll over 16 years ago in reply to Jon Nicoll

Intellectual 320 points

Hi Gourav

We've tried your suggestion without success, but I have more details below. We changed the UBL describer to the following:

0xa1aced00    # FIELD 0: UBL magic number - safe mode
0x00000100    # FIELD 1: absolute start address in IRAM
0x0000000F    # FIELD 2: number of pages in UBL
0x00000001    # FIELD 3: starting block Number of UBL code
0x00000002    # FIELD 4: starting page number of UBL code

That is, we changed the starting page number of the UBL code (FIELD 4), as you suggested, and we also changed the number of pages in the UBL to copy (FIELD 2), from 0x08 to 0x0F, as I suggested. I was able to check that our UBL fits within 0x7800 (30K), and so a page copy count of 15 (0x0f) should be sufficient.

With these changes, when we try (and fail) to perform a boot to NAND Flash, we again used Code Composer Studio to connect to the DM365 and examine the locations in IRAM where we understand the UBL code should be copied. We again see the 'block # found' value at 0x7ffc to be 0x00000001, as expected. Here's a dump of the code at 0x0000.0000:

0x00000000:    0xEA001FFE    0x759114D7    0x07DB2174    0x475685F8
0x00000010:    0xF7BA5656    0xC3579FC5    0x7B6A7843    0x2F170F52
0x00000020:    0xA1ACED00    0x00000100    0x0000000F    0x00000001 # UBL Describer?!
0x00000030:    0x00000002    0x00000000    0xFFFFFFFF    0xFFFFFFFF
0x00000040:    0xFFFFFFFF    0xFFFFFFFF    0xFFFFFFFF    0xFFFFFFFF
0x00000050:    0xFFFFFFFF    0xFFFFFFFF    0xFFFFFFFF    0xFFFFFFFF

That is, it looks like the UBL describer is being copied to IRAM at 0x00000020 onwards, and then the rest of Block 1, Page 0, of the NAND Flash is also being copied. This copying appears to end around address 0x00001000.

This is not what I'd expect the

By way of contrast, this is what we see when we successfully boot via SD Card:

0x00000000:    0xEA001FFE    0x719914D7    0x679B2174    0x47D687F8
0x00000010:    0xF7BAF676    0xC3759FC5    0x7B6A68C3    0x2E170F52
0x00000020:    0xEE190F31    0xE3A00001    0xEE090F31    0xEE190F11
0x00000030:    0xE59F0038    0xE380001D    0xEE090F11    0xE59F0034
0x00000040:    0xE59F1034    0xE59F2034    0xE1520000    0x9A000005
0x00000050:    0xE0422000    0xE1A02142    0xE490C004    0xE2522001
0x00000060:    0xE481C004    0x1AFFFFFB    0xE59F0004    0xE1A0F000
0x00000070:    0x00010000    0x00000100    0x02000000    0x00010020
0x00000080:    0x02006524    0x00000000    0x00000000    0x00000000
0x00000090:    0x00000000    0x00000000    0x00000000    0x00000000
0x000000A0:    0x00000000    0x00000000    0x00000000    0x00000000
0x000000B0:    0x00000000    0x00000000    0x00000000    0x00000000
0x000000C0:    0x00000000    0x00000000    0x00000000    0x00000000
0x000000D0:    0x00000000    0x00000000    0x00000000    0x00000000
0x000000E0:    0x00000000    0x00000000    0x00000000    0x00000000
0x000000F0:    0x00000000    0x00000000    0x00000000    0x00000000
0x00000100:    0xE1A00000    0xE10F0000    0xE3C0001F    0xE3800013
0x00000110:    0xE38000C0    0xE129F000    0xE1A00000    0xEE110F10
0x00000120:    0xE3C00C23    0xE3C00087    0xE3800002    0xE3800A01

This shows in part the start of the UBL at location 0x100, which is similar to what I'd expect to see if the NAND Flash copy worked OK (Of course I appreciate that these observations are not entirely reliable because the SD card boot at least may be using areas in IRAM for other purposes once booted).

We tried this experiment with values of both UBL_MAGIC_SAFE (0xA1ACED00) and UBL_MAGIC_SAFE_LEGACY (0xA1ACEDCC) for the Magic number. No difference was seen in the results.

Here is a bit more information about our actual NAND Flash. It has a first DeviceID value of 0xD3, but I appreciate that this seems to be an ambiguous value, and that the RBL may also require other ID codes from the memory:

Device: Micron MT29F16G08DAA, 16Gb x 8

Manufacturer's ID: 0x2c

Device ID 1: 0xD3 # note: other Devices exist with Id

Device ID 2: 0x90 # 2 dies per CE

Device ID 3: 0x2h (Page Size 4kb/0x1000, Block size 256kb/0x40000)

Device ID 4: 0x64

Thanks for your further help with this.

Best Regards

Jon Nicoll

0 Gaurav Agarwal over 16 years ago in reply to Jon Nicoll

TI__Expert 3425 points

Jon,

RBL copies the whole page, so your observation is correct. However it is not copying the UBL. The memory region starting 0x20 should look like the one in MMC/SD boot.

For SAFE mode, RBL follows the following steps:
1. Copy the UBL descriptor/describer. This step is successful in your case
2. Read the UBL desciptor, does some checks (like page size etc). If the size checks fail. RBL will abort NAND boot.
3. Start copying the UBL from the block and page size

The possible reasons could be:
1. The size of the UBL. For testing try making the no of pages as 1
2. Start page of UBL. Can you try starting the UBL in block 2, page 0.
3. ECC errors. If there are more ECC errors than the device supports or the spare bytes for ECC are not written properly, the page read will be aborted. Please cross-check the flash writer and try another NAND device.

If these suggestions do not work, can you please send the memory values (32 bit) at the following location:
0x0000bff8
0x00017db4
0x00017dbc - 0x00017ddc
0x0000bf6c - 0x0000bf8c

Thanks,
Gaurav

PS: Please mark this post as answered via the Verify Answer button below if you think it answers your question. Thanks!

0 Gaurav Agarwal over 16 years ago in reply to Gaurav Agarwal

TI__Expert 3425 points

Jon,

Are you able to have the NAND working?

Thanks,
Gaurav

0 Jon Nicoll over 16 years ago in reply to Gaurav Agarwal

Intellectual 320 points

Hello Gourav

Thaks for your very helpful posting. We have made good progress and it's looking like the NAND Flash is working! ;-). Here is some more information:

We tried using your suggestion of a '# of pages field' value of 1, with an otherwise-empty NAND Flash. With this we were able to see (via CCS) that the RBL was correctly copying 1 page (4096) bytes of (0xff) memory from Block 1, page 1 to 0x20 onwards. Thus the RBL was correctly determining the Block and page size of the NAND Flash
We then increased the value in the '# of pages field' to 2, 3, ... and so on. We ended up seeing that all values up to 7 worked, but that 8 does not. So from your earlier comments about the 30k UBL limit, I guess that this must apply to the calculated 'copy block size', ie. (determined NAND Flash page size) * (value of '# of pages in UBL' field) must be < 30k, not just that the UBL code must be < 30k. So in our case, with a NAND Flash page size of 4096 bytes, the maximum UBL we can have is 7*4096 = 28K. the RBL must fail either if the calculated size is > 30k, or if it's initial attempt to copy the UBL (into the TCM data area? goes over some limit.
Luckily, it looks like the value of 8 for the '# of pages' field was set higher than need be in our case. We are still checking this out, but it looks like our UBL is substantially smaller than this. We set the '# of pages' field to 7 and successfully got a UBL prompt!

So it looks like the Micron MT29F8G08DAA-WP is supported with DM365 Rev. 1.2 silicon. BTW, we are using a value of UBL_MAGIC_SAFE (0xA1ACED00) for the UBL describer.

You also asked about the contents of some memory locations. For reference, here they are:

0x0000bff8: 0x20050100
0x00017db4: 0x00000100

0x00017DBC:    0x010540D3    0x10161080
0x00017DC4:    0xB32C0000    0xE13BFDB4
0x00017DCC:    0x886B4144    0x7B22DBA7
0x00017DD4: 0x1CD00A80    0x0DD0C776
0x00017DDC:    0xA3D50EF4    0xCE44636E

0x0000BF6C    0x00440043    0x00440045
0x0000BF74    0x00440053    0x00440055
0x0000BF7C    0x00440073    0x00440033
0x0000BF84    0x00440075    0x00440035
0x0000BF8C    0x00450076    0x00450036

for the benefit of others who might be reading this thread, we have been using Constantine Shulyupin's SD card boot and flashing tool (Ver. Sept 22 2009) for copying the UBL onto NAND Flash. It looks like although this correctly determines the characteristics of our NAND Flash, it does a couple of things slighty wrong (no slur intended - I will pass our observations on to Constantine). (i) it writes a larger-than necessary value for the '#of pages' field in this case; (ii) it seems to put the U-boot at the wrong place for this device. We are investigating these further; I appreciate that this is not a Ti supported tool

So I think we have a working UBL - we have been able to get round both cases (i) and (ii) above and have booted up to U-boot via NAND Flash, and then a Linux kernel via NFS. Next step is to check getting the Linux kernel and filesystem onto the NAND Flash.

Thanks very much for your assistance with this.

Best Regards

Jon N

0 Gaurav Agarwal over 16 years ago in reply to Jon Nicoll

TI__Expert 3425 points

Jon,

Glad to know that the NAND is working for you.

From the logs, I can see that the RBL determines the NAND page size as 4K. That explains why the number of pages for UBL size should be limited to 7.

Best Regards,
Gaurav

PS: Please mark this post as answered via the Verify Answer button below if you think it answers your question. Thanks!

Processors

Processors forum

Another DM365 booting from Micron NAND Flash question