Mity CPU Platforms » MitySOM-335x (ARM Cortex-A8 Based Products)

Could you please provide a reference to these TI wiki pages?

What git repo did you locate the referenced mityarm335x.h file?

Does this wiki page help? http://support.criticallink.com/redmine/projects/armc8-platforms/wiki/UBIFS_Nand_Boot#NAND-Partition-Table

The TI processor bootcode will check the first 4 blocks for a valid MLO and use the first one found. If a block goes bad and the MLO in that block no longer passes the checksum then the bootcode will skip it and check the next one.

-Jonathan

You can read up on the TI processor ROM boot process in section 26 of the AM335x Technical Reference Manual. http://www.ti.com/lsds/ti/arm/sitara_arm_cortex_a_processor/sitara_arm_cortex_a8/am335x_arm_cortex_a8/tech_docs.page?rootFamilyId=3000&familyId=2920&docCategoryId=6

Hi Jonathan,
Here is the wiki for the AM335x Uboot users guide:
http://processors.wiki.ti.com/index.php/AM335x_U-Boot_User%27s_Guide#SPI_2

The mityarm335x.h is from the latest git repo as described on your wiki:
http://support.criticallink.com/redmine/projects/armc8-platforms/wiki/Das_U-Boot_Port

The wiki link you gave does clarify that the processor does check the NAND block
for errors. But I do notice that there is only one uboot image put into NAND. This
suggests that MLO does not do the same type of check to verify that uboot is
good (uboot is built as an image.) So when I see the mityarm335x.h comments the
environment seems to be in the wrong location, but the there are/could be multiple
uboot images. It seems to make sense that if there backups of MLO, then there should
be at least one backup of uboot as they are both stored in NAND flash.

So is the .h file correct and MLO does check for more than one uboot or was it
referring to a different memory map?

Thanks,
John C.

John,

Thanks for the clarification, I was looking in the kernel repository not the U-boot one.

I am not too familiar with the u-boot mlo implementation. I'm not sure what it would take to have the MLO support two locations for the u-boot image.

My guess though is that its not as vital as both the MLO and U-boot image has the nand driver which can auto skip marked bad blocks when reading and writing. We use the "nand.i write" specifically to make sure we don't write data to any known bad blocks and since the u-boot partition is effectively read-only (only writes when programming partition) a block shouldn't go bad. The nand driver also uses BCH-8 error correction which should allow 8-bits of error correction per block.

Ok I see where you were referencing. http://support.criticallink.com/gitweb/?p=u-boot-mityarm-335x.git;a=blob;f=include/configs/mityarm335x.h;h=9f0fddb73dff9620959a3860acd62ad76b1c59b4;hb=HEAD#l196. The comment you mentioned appears to be out of date. Possibly copied from TIs u-boot support or our L138 module.

The MTDPARTS_DEFAULT value more accurately references the partition scheme we've been using.
http://support.criticallink.com/gitweb/?p=u-boot-mityarm-335x.git;a=blob;f=include/configs/mityarm335x.h;h=9f0fddb73dff9620959a3860acd62ad76b1c59b4;hb=HEAD#l367

So looking in the following file you can see that there is support in the MLO for having a redundant environment partition, although we don't use it. It would probably not be difficult for someone to also add a redundant u-boot partition in the same file.

arch/arm/cpu/armv7/omap-common/spl_nand.c
http://support.criticallink.com/gitweb/?p=u-boot-mityarm-335x.git;a=blob;f=arch/arm/cpu/armv7/omap-common/spl_nand.c;h=af02a595571c4eea509abefde84a6ab72bb06cc2;hb=HEAD

Note that you can look through the README in the repo to get information on various supported #defines.
http://support.criticallink.com/gitweb/?p=u-boot-mityarm-335x.git;a=blob;f=README;h=a43da97a4149db3bf9cea0a1b9e02ef69eee9802;hb=HEAD#l2780

Jonathan,
Thanks much as your last two posts help tremendously. Our biggest concern with using NAND for both the u-boot images
(and our own) was having a block go bad. We did not want our units to end up dying in the field because a block had gone bad
and wiped our image. I had looked at the s_init() code hoping to track how MLO got to the code to load u-boot, but did not
get far, so your link for spl_nand.c was nice. We have done slight modifications to u-boot to support out spi flash, so I
could look into what it would take to add a redundant u-boot.
Thanks again for all the help.
John C.

Thanks for the status update. Let us know how it turns out.

-Jonathan