On 12/02/2013 12:46 PM, Gupta, Pekon wrote: >>> So coming back to the specific problem here. >>> I think we need 'nandecc' back in u-boot till atleast all systems have >>> migrated to BCH16 or whatever highest ecc-scheme which can be >>> supported on OMAP devices. >>> > > Forgot to mention, one more way of updating boot-loaders with > different ecc-scheme via kernel. This can be helpful when: > - you want to remotely upgrade your u-boot, but your kernel is statically > build with different ecc-scheme. > - In production environment, where you boot multiple devices in parallel > (using say NFS boot), and then flash multiple devices without bothering > about ecc-schemes.. > > *Method* > (1) Flash the u-boot image on one *sample* device selecting appropriate > ecc-scheme which ROM code understands. > (2) Dump the complete image along with OOB appended (as a binary) > (3) Use this binary image (with OOB included) to flash other devices > from kernel as *raw* data (that means kernel will not append ECC while > writing data, it will blindly write the image as-it-is on the partition). > > This way the ECC with which u-boot image was built in (1) will get > programmed, irrespective of what kernel supports.. > - I have seen at-least one customer going into production this way. > - And I have been using this often too, though with older mtd-utils. There are many ways to in essentially work around this problem, given the ability to raw write (including OOB) from the kernel and from u-boot. This doesn't change the general problem of "we have cases where we need part of the NAND with one scheme, another part of it with a different one". -- Tom -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
