DM365: More Details on RBL's usage of NAND Spare Bytes

RBL uses does not implement any bad block checking/managment; it simply relies on the HW ECCs; that said, in DM365, RBL uses 4-bit ECCs (as suggested by ARM UG, 1-bit ECCs are not supported by RBL); therefore, you must choose the appropriate NAND part if your want to boot from NAND such that RBL will work properly.

That said, at the higher software layers (UBL, U-boot, kernel) user has more freedom to decide if they want to implement software ECCs, rely on hardware ECCs and decide on the length of the ECCs they would like.  I do not recall what our DVSDK defaults are off the top of my head, but there is more flexibility at these upper software layers, though taking the defaults will likely save your lots of work.

With regards to how NAND manufacturers mark bad blocks, I would recommend getting this information from the manufacturers themselves.  As a rule of thumb, spare bytes on first and second pages (and if it is an ONFI device it will also check the spare bytes region of the last page of the block) are used.  If any byte of these spare bytes regions, that is not normally used for storing ECC data, is not 0xFF, then the block is considered bad.  Again though, I would double check this with the corresponding NAND manufacturers.

Thanks Juan,

you gave me some important information. RBL uses only the hardware 4-bit ECC, and checks not for bad blocks. Of course the magic number is used too.  About the manufactorers coding of bad blocks: I checked some, and typically only the first byte of the spare area is used (1st and second block, ONFI first and last).

But some details are not clear to me:

• Is it an atvantage to use the same ECC/bad block algo for every level (RBL, SD-Tool, UBL, U-Boot, Kernel, File-Sytem, etc)? Or can the Methods be used intermixed without danger (U-Boot must know every method used, because firmware updates can be don there)?
• What is the prefered Layout of a page? In literature I found 2 types: (a) 4x512 Data Bytes and then 4x16 Spare Bytes at the end, (b) 512 Data Bytes and 16 Spare Bytes, this 4 times. I guess it is (a), but this is not clear.
• How many bytes are used to calculate ECC, 512 data bytes only or 512 + 6 data + spare bytes? In case of 518 bytes, is it no problem to have the used bytes not in a continous array, like in layout (b)?

Thanks,
Andi

Andi,

Unfortunately, I do not know all the answers to your questions, but I will answer what I know...

With regards to the various software layers using same of different ECCs policies, normally when a particular layer completes its task, it no longer partakes in the system environment; therefore it is ok if they do not follow the same policies.  For isntance RBLs job is to find a valid secondary boot-loader (e.g UBL), once it finds it, places it in RAM and runs it, it is done.  UBL is small and does minimal hardware initialization primarily to put default NAND speed (slow) to a more suitable (faster) configuration to allow fast loading of U-boot, it then loads u-boot to RAM and it is done... simlarly, u-boot initializes a little more of the hardware (ethernet, uart, ...) to allow basic system configuration (via u-boot enviroment vars, tftp, nfs services...).  However, once the kernel loads, the kernel drivers can (and more often than not, do) overwrite u-boot hardware initialization and provide more robust ethernet driver, may choose to disble NAND in place of another memory device attached to shared EMIF port... and that is ok, because u-boot has served its purpose and no longer partakes on system environment until the next time you cycle power to the EVM.  It is pass-the-battan architecture (once you done your part, you are done) that allows different layers to use different ECCs policies if they wish.  BTW, in cases where both u-boot and kernel use NAND, NAND is partitioned by kernel driver and u-boot normally limits its access to the memory locations (one of the partitions) the system designer agreed to use for u-boot; and yes, although not necessary, it would be beneficial to have u-boot and kernel use same ECC policy.

I am afraid I do not know enough to address your last two bullets, but maybe someone else can jump in and offer their expertise.