[U-Boot] CONFIG_MTD_CONCAT issue

[U-Boot] CONFIG_MTD_CONCAT issue

[Andrew E. Mileski]

I'm having an issue using CONFIG_MTD_CONCAT with a dual-die NOR flash 
part.  Assistance appreciated.

We're using the driver for greater compatibility between single and 
dual-die NOR flash parts.


=> mtdparts

device nor2 <of-flash.2>, # parts = 5
  #: name                size            offset          mask_flags
  0: os                  0x03f00000      0x00000000      0
  1: spare               0x00020000      0x03f00000      0
  2: redun               0x00020000      0x03f20000      0
  3: env                 0x00020000      0x03f40000      0
  4: u-boot              0x000a0000      0x03f60000      0

active partition: nor2,0 - (os) 0x03f00000 @ 0x00000000

defaults:
mtdids  : nor2=of-flash.2
mtdparts: 
mtdparts=of-flash.0:63m(os),128k(spare),128k(redun),128k(env),640k(u-boot)

=> erase nor2,0
Erase Flash Partition nor2,0, bank 2, 0x00000000 - 0x03efffff
Error: start and/or end address not on sector boundary


It seems as though CONFIG_MTD_CONCAT is incompatible with
   common/cmd_flash.c : flash_fill_sect_ranges()
called from
   common/cmd_flash.c : do_flerase()
because the MTD_CONCAT offsets passed to it don't match any sectors.

Example:  Two 32 MiB flash banks are located at offsets 0xe0000000 and 
0xe2000000, which are always greater than the MTD_CONCAT offsets, 
resulting in a failure to find matching sectors.

Adding a debug message to the conditional at line 230:
   if (addr_last < info->start[sect])
       continue;
resulted in:
   ##DEBUG## addr_last < info->start[sect] (0x03efffff < 0xe0000000)
which demonstrates the passed MTD_CONCAT offsets being compared to the 
actual bank offsets.

I'm also experiencing a secondary issue of a random hang upon erasing 
only the last sector.  The command completes successfully, but never 
returns to the command prompt.  I suspect it is a memory clobber, 
possibly related to the MTD_CONCAT offsets being used when they 
shouldn't.  Still trying to narrow this one down though.

~~
Andrew E. Mileski