I have a situation where we are having a lot of data corruption across all our boot partitions such that the AM3517 code does not load and/or boot to a point where we can interrogate the partitions to see how ECCs are distributed or what the data looks like. (to understand the character and possible pattern of the corruption which might lead me to speculate on what is causing it...so I can know where to even "start" to put a scope probe! :) )
Is there a tool / method that I can use to READ the data from the NAND flash (either partition by partition of even as a whole) and then save it to a file so that I might do this between a GOOD card and one of our BAD cards and then do some sort of simple octal dump | compare to see differences. I am thinking that our read only partitions like u-boot and our OS should not have suffered from any changes over time, so they should match completely. (and we know they don't because there are uncorrectable ECCs during boot)
The other debug approach I was considering is to create a boot image on an SDCARD and boot from there....then from there, try to mount and interrogate the various partitions in the NAND Flash. Does that sound like a reasonable approach, and what sort of issues to I have to consider. (someone told me I need to create the partitions on the SDCARD to the exact specifications as the NAND was created.....size, ECC, etc...)
I apologize, I am a newbie to the AM3517, and this entire embedded environment, so these might be dumb questions.....but I tried to GOOGLE all this and more, and have come up with more questions than answers,
Is there a NEWBIE document that describes building for the SDCARD vs the NAND.....can I just take the process / scripts used for the NAND and make some small environment changes, load and SDCARD in the SOM and expect the boot environment to "end up there" rather than the NAND. (It can't really be that easy....right?)
Any insights on any of the above are greatly appreciated.....
-Quentin
