OMAP3503 - ROM-Code Boot Information

Hi Arun,

Since nobody from TI have answered, I though I would kick in. I don't know for 100% sure, but I have never seen it either (and I believe I know the OMAP ROM-code in kind of great detail [:)]), so I would tend to think that you can't get the info from the ROM-code.

Being curious: For which kind of purpose would you need the information? What are you trying to do?

Best regards
  Søren

Hai,

Thanks for your response.

We are trying to count the errors that occured while reading the NAND flash while booting. For that, in case if first block (of XLDR) is bad, the ROM-Code starts reading the XLDR from second block, so now one error counter needs to be incremented. So, we require the information from ROM-Code, through which block of XLDR the ROM-Code starts reading from the Flash.

Note: XLDR refers to X-Loader (Primary boot loader) running in the SRAM of OMAP3503 processor.

With Regards,

Arun.

Here are two possible ways/thinking to resolve your issue:

1) A bad block in NAND forms only when the block is erased/written to - reads will not result in the creation of any new bad blocks (so when you do your flashing, if you found that block 0 is bad, but block 1 is not, the ROM code during read will DEFINITELY boot from block 1 with absolute deterministic behaviour each and every boot, i.e it will never make block 1 bad)

2) If you really want to test assumption #1, instead of trying to get information directly from the ROM code about which block it read out from, have each of your X-Loader images have a varying block specific constant in them that you can print out during boot. This is a software solution/workaround to your problem.

Hope it helps,

Jerry

Although you are technically correct, reading a block will never result in it becoming "bad" you are missing a large problem when using NAND for code storage.

Google for read-disturb, Micron have also done several good presentations (The Inconvenient Truth of NAND Flash Memory) on the often overlooked problems of using NAND (such as read-disturb, data retention, endurance etc..).

Multiple copies of the initial bootloader are required not because a block becomes "bad" by being read, but that a block will start to forget the data it stores the more it is read. This can be fixed by re-writing (erasing and programming) the block, and the read-disturb mechanism is basically reset.

Hence, it is *very* useful to have an indication of which copy of the initial bootloader was used to boot, as this information should be used to aid a re-programming stratergy for the stored code (if the second copy was used, and the first used to be good the first should be erased and re-programmed and so on).

So multiple copies of the initial bootloader should be stored in the first few blocks not only because some may fail when being programmed, but because some *will* fail during the product's lifetime due to being read.

Though i'm not sure TI thought of read-disturb when implementing multiple copies of the initial bootloader...

Ahh, thank you for the illuminating information - i guess the only real solution here is to then produce differing xloader images of each of the 4 blocks; this can be done by modifying the linker script to place a new section for a data segment that is after the .bss section (bottom of your binary). This way, you can then pre-allocate some space there (perhaps 4-8 bytes) where you can add this custom ID information which is readable through code. When you do your flashing of the images, just modify that section for each block before writing it to NAND.

Jerry

Joseph Woodward said:

So multiple copies of the initial bootloader should be stored in the first few blocks not only because some may fail when being programmed, but because some *will* fail during the product's lifetime due to being read.

Though i'm not sure TI thought of read-disturb when implementing multiple copies of the initial bootloader...

I discussed this with both the TI ROM code team and several of the biggest NAND suppliers a couple of years ago...

And while I totally agree in you points (That NAND is "special and volatile" and you should take special care) I at the same time want to say that it isn't as bad as one might think while getting into the NAND world for the very first time. At least not as long as we speak SLC NAND. Speaking MLC NAND things gets worse - I totally agree.

With respect to the Read-disturb problem this typically occur for 1M+ reads fro SLC. For MLC the number goes down to around 100.000 times. Assuming 1 boot a day and a safety margin at a factor of 10 will will for MLC give a device life time of 100.000 / (365 days/year*10) = ~27years, which should be enough for most consumer electronic equipment (it's at least larger than the promised OMAP life time :-). For SLC NAND we are at 270 years :-) 

The biggest problem with NAND is while using them for reading/writing/erasing data "all the time", where the effects of wear-leveling and read-disturb really gets into play. Using them for reading at low rates (like once a day) won't normally show any significant problems. Other than the need for taking care about not using bad blocks.

Best regards
  Søren

You are correct, for SLC devices read disturb can effectively be disturbed...but these devices are getting rare!

As as you say, things are much worse for MLC (especially moving forwards to 4-bit/cell and 8-bit/cell devices).

One point I would query with you is whether the quoted read endurance is per-page or per-block (and this is one point where the information is lacking, and I've never been able to get a clear answer).

Imagine a 64-page-per-block device with 100K read lifetime before a failure due to read disturb. Lets say that we need all 64 pages in a block to boot (given a 2K page size this gives an application size of 128K, not unreasonable). Now, lets re-do your calculation assuming a read disturb is per-block:

100K / (365 days/year * 10 * 64PagesReadFromTheBlockToBoot) = less than half a year (a bit more of a problem!).

As I say, this depends on whether the read disturb is quoted against the page or the block, and I've found little conclussive information here. So if you know more please do enlighten me!

For reference from Micron's information on read distrub:

"Stressed cells are:
•Always in the block being read
•Always on pages not being read"

And from STMicro (quote found on the web, I believe "sector" means block):

"after 100,000 or so reads of a sector, the stored data is actually very likely to experience corruption"

Personally I think it takes a brave engineer to not build plenty of redundancy in to a product in which NAND flash is used the primary boot media and is used to store code. I admit the more modern devices seems to be heading this way, but the vast majority still seem to use NOR as the primary boot media.

Cheers :)

Joe

Hi Joe,

I agree that you have a very important point in this and that it's difficult to figure out what exactly the figure of 1M/100K reads means. I'll try to put the question to some of my "NAND-contacts" and let you know in case I get any better clarification from any of them. But straight out of the box I think you are right that it's individually page reads, although I'm not 100% sure - I missed that in my previous calculations - Sorry.

Secondly: I as well agree that using NAND technology in a proper way takes a lot of engineering/software/algorithm-skills - Especially for MLC - It's not as easy as the good old NOR, which AFAIK indeed is one of the main reasons for introducing eMMC - trying to hide away all of this nasty stuff :-)

Best regards and Thanks for a great discussion
  Søren