Hi Mike,
> (1) is '--noecc' critical? (Is it ecc memory?)
Yes, it is important to specify noecc (meaning no ecc info needed to be dumped).
> (2) should the '--omitoob' option be '--omitbad'
> or is it really referring to 'out of band' memory
> (oob)? And, again, is the lack of the option a
> showstopper?
Yes, obmitoob (out of band) option ignores oob, so the dump can be reused on any NS325 box.
If the nanddump version you run does not have those options, you should make sure to download the binaries tarball I uploaded in the u-boot release post
With that said, the mtd back up with nadndump is just a precaution. You can get stock NSA325 nanddump mtds from this forum should you ever need them. Those steps were illustration of how to hack these boxes safely, i.e. you have your own backup, you're are in control when and if you can restore them to stock.
> The next issue refers to bad blocks. I have two -
> at 0x0000048c0000 #582 and 0x0000050a0000 #645.
>
582 and 645 are far away from mtd0, i.e u-boot region, so it is safe to ignore these bad blocks.
> (3) how do I work out which block and which mtd
> number these are present in? Is there an easy
> formula?
NAND block is 128MB. So mtd0 is 8 blocks, 0-7. You can derive the other mtd block numbers by this formula.
So NSA325 mtdparts env defines these mtds:
mtd0 (u-boot) size is 0x100000 = 1MB, and its location is at 0x0. You can keep going to the next and so on.
> (1) is '--noecc' critical? (Is it ecc memory?)
Yes, it is important to specify noecc (meaning no ecc info needed to be dumped).
> (2) should the '--omitoob' option be '--omitbad'
> or is it really referring to 'out of band' memory
> (oob)? And, again, is the lack of the option a
> showstopper?
Yes, obmitoob (out of band) option ignores oob, so the dump can be reused on any NS325 box.
If the nanddump version you run does not have those options, you should make sure to download the binaries tarball I uploaded in the u-boot release post
Quote
A. Flashing Instruction:
Installation is the same for each u-Boot image, the instruction below is written to include all boxes. So choose the platform name that you are installing for, and copy/paste the appropriate commands.
If you are running kernel that do not provide mtd-utils and uboot-tools (fw_setenv, fw_printenv, flash_erase, nandwrite), you can download the NAND and U-Boot tools binaries here in this thread.
With that said, the mtd back up with nadndump is just a precaution. You can get stock NSA325 nanddump mtds from this forum should you ever need them. Those steps were illustration of how to hack these boxes safely, i.e. you have your own backup, you're are in control when and if you can restore them to stock.
> The next issue refers to bad blocks. I have two -
> at 0x0000048c0000 #582 and 0x0000050a0000 #645.
>
582 and 645 are far away from mtd0, i.e u-boot region, so it is safe to ignore these bad blocks.
> (3) how do I work out which block and which mtd
> number these are present in? Is there an easy
> formula?
NAND block is 128MB. So mtd0 is 8 blocks, 0-7. You can derive the other mtd block numbers by this formula.
So NSA325 mtdparts env defines these mtds:
mtdparts=mtdparts=orion_nand:0x100000(uboot),0x80000(uboot_env),0x80000(key_store),0x80000(info),0xA00000(etc),0xA00000(kernel_1),0x2FC0000(rootfs1),0xA00000(kernel_2),0x2FC0000(rootfs2)
mtd0 (u-boot) size is 0x100000 = 1MB, and its location is at 0x0. You can keep going to the next and so on.