XLDR programming algorithm referred to in XLDR source

The requirement is from ROM spec:

From 3530 TRM 1.4.7.2 Non-XIP Memory

“NAND and OneNAND devices use up to four copies of the image

in the first four physical blocks. Therefore, the ROM code searches for the image in the first four physical

blocks of these devices. Other devices use only one copy of the image and the block loop runs only once.”

Regarding programming tool, it is any tool that can accomplish this job. Specifically, in case of EVMFlash the .raw file contains 4 copies of xldr and 1 copy of eboot

Atul

Hi Atul,

Thanks for your reply.

The reason I'm asking is that the comment (and code) specifically do not follow the spec.

According to 25.4.7.2 in the TRM, only the first four physical blocks will be searched for bootloader code. Note that this is regardless of whether any bad blocks are found (I suppose that's the whole point of having four locations to search; if one turns out to be bad, no problem - just try the next one).

But the code in xldr that determines where xldr ends (and consequently where eboot begins) skips over bad blocks, which implies that the location of eboot would be shifted in case one or more of the first four blocks is marked as bad. The comment says the reason the code does this is because "the programming algorithm" behaves this way; it programs xldr into the first four good blocks, skipping any bad blocks. It even says that copies of xldr stored in the fifth block onwards will never be loaded, as the ROM code will never look there, and that the reason xldr behaves this way is it "simplifies the flash management algorithms".

Therefore my question: Which programming algorithm is the comment referring to?

Best regards,
Carsten

Just to clarify, it appears that the programming algorithm described in the XLDR comment does not follow the ROM spec.

The Boot ROM will look for code in the first four blocks only, regardless if they are marked as bad or not.

But the programming algorithm described will skip bad blocks, meaning that if, say, block 2 is bad, copies of XLDR will be stored in blocks 0, 1, 3 and 4.
And since the Boot ROM will never look beyond 3, this seems like
  - a waste of one flash block (and, in the extremely rare case that three out of the first four blocks are corrupt, up to three blocks)
  - locating Eboot becomes more complicated, as it will not be at a fixed offset

OK, so let me ask in another way.

Which software implements the described algorithm?
  - Is it the Flash Tool that runs on a PC?
  - Is there any embedded code somewhere that skips bad blocks when programming XLDR?

Best regards,
Carsten