Looping the BeagleBoard list...
I was unfortunately answering from an email address not subscribed to the
list...
Søren
Hi Andy,
Sorry for not getting back to you prior to now - You emailed my old emails
address, which I'm not checking at a daily basis any longer. Likewise work
is currently too heavy for me following the BeagleBoard list on a daily
basis (unfortunately) - I will though (soon) be back at full power I hope
and promise...
I have gone through the different methods of flashing the x-loader, u-
boot, kernel image to NAND on the BB sucessfully: via serial
bootstrap; via u-boot through kermit and the SD card, via u-boot
running on an XDS560R emulator, etc.
Great
We are currently developing a custom OMAP3530 board and we want to
"mass" flash those boards (at least with the x-loader and u-boot
images) in production, the quickest way being via the method of a
Boundary Scan Tool.
Any reason not to use USB or UART peripheral booting? This is what most
major customers do in their manufacturing lines and I think it would be much
easier (and you as well won't require JTAG access :-))?
We are currently using the ASSET Boundary Scan
Tool and our hardware engineer seems to have flashed the x-loader
image correctly but the it doesn't seem to come up (no X-loader boot
message). I believe the issue has to do with ECC HW encoding, the
first 4 blocks of NAND are ECC HW, which the x-loader resides, We
found out that the ASSET tool doesn't do ECC when writing to flash
(the OMAP is bypassed and hence is not running, which I think means it
doesn't auto-generate the ECC code and write it to the corresponding
spare OOB area for the data page).
The OMAP won't write any ECC codes by itself - It only calculate the value.
Then it's up to you to (somehow) write it wherever in the OOB area you want
(by the ASSET script used for flashing I assume)...
We have talked to the ASSET tool
developer and they say they don't provide ECC support because it's
hardware dependent (processor, NAND device) and too specific for our
platform; I believe they will only do so if it can be applied it
genericly to more platforms so they can support more different
customers. Anyways, our hardware engineer said it seems like the
ASSET tool can write in data mode and in spare mode; data mode is
problem just writing to the page data area and spare mode may be the
"OOB" area. How do I go about generating an OOB image for a x-loader
image, if there is such a thing?
The easiest way would be to read it back from an already flashed board
(flashed using one of the other methods mentioned above) - Or use the
algorithm from the x-loader source to create a "full image" including OBB
yourself 
I know it involves hamming code
algorithm used by the hardware but I'm not sure where to look. Our
hardware engineer thinks maybe if he can program the x-loader image in
"data" mode and then the OOB image in "spare" mode, maybe it'll work?
Can I do a dump of the OOB bytes section for an equivalent x-loader
data section using u-boot?
Not sure, but you can definitely do it with a slightly modified u-boot
(or most likely with the ASSET tool as well?)
Is there a tool (emulator or boundary scan) that any of you know that
can do the ECC automatically when writing to the NAND?
Never heard of such a thing, since it's normally an algorithm which might
change from chip-vendor to chip-vendor, and which really isn't static in any
way :-). You should however easily be able to write a script in either CCS,
Lauterbach or ASSET being able to do the requested operation for you. But
again, I think I would recommend either USB or serial peripheral boot
instead
I don't know if this makes any sense but hopefully the experts in this
forum can give some advice and pointers (I CCed a few of you who
posted on the ECC topic, hopefully you don't mind).
No problem - You are welcome - In case you need any further help going
forward...
Please don't hesitate to contact me directly again and I will see what I can
do...
Best regards - Good luck
Søren