All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew E. Mileski <andrewm@isoar.ca>
To: u-boot@lists.denx.de
Subject: [U-Boot] CONFIG_MTD_CONCAT issue
Date: Thu, 30 Apr 2015 22:18:11 -0400	[thread overview]
Message-ID: <5542E263.8060604@isoar.ca> (raw)

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

                 reply	other threads:[~2015-05-01  2:18 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5542E263.8060604@isoar.ca \
    --to=andrewm@isoar.ca \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.