Skip to content
Snippets Groups Projects
Select Git revision
  • master default protected
  • stable
  • extraversion
  • early-display
  • variant-emmc-nvme-boot
  • 2024-07-19
  • 2024-06-30
  • 2023-10-18
  • 2023-10-10
  • 2023-07-04
  • 2023-01-25
  • v3
  • variant-emmc-nvme-boot
  • 2020-06-01
14 results

cmd_nand.c

Blame
    • Scott Wood's avatar
      30486322
      nand erase: .spread, .part, .chip subcommands · 30486322
      Scott Wood authored
      A while back, in http://lists.denx.de/pipermail/u-boot/2009-June/054428.html,
      Michele De Candia posted a patch to not count bad blocks toward the
      requested size to be erased.  This is desireable when you're passing in
      something like $filesize, but not when you're trying to erase a partition.
      
      Thus, a .spread subcommand (named for consistency with
      http://lists.denx.de/pipermail/u-boot/2010-August/075163.html
      
      ) is introduced
      to make explicit the user's desire to erase for a given amount of data,
      rather than to erase a specific region of the chip.
      
      While passing $filesize to "nand erase" is useful, accidentally passing
      something like $fliesize currently produces quite unpleasant results, as the
      variable evaluates to nothing and U-Boot assumes that you want to erase
      the entire rest of the chip/partition.  To improve the safety of the
      erase command, require the user to make explicit their intentions by
      using a .part or .chip subcommand.  This is an incompatible user interface
      change, but keeping compatibility would eliminate the safety gain, and IMHO
      it's worth it.
      
      While touching nand_erase_opts(), make it accept 64-bit offsets and sizes,
      fix the percentage display when erase length is rounded up, eliminate
      an inconsistent warning about rounding up the erase length which only
      happened when the length was less than one block (rounding up for $filesize
      is normal operation), and add a diagnostic if there's an attempt to erase
      beginning at a non-block boundary.
      
      Signed-off-by: default avatarScott Wood <scottwood@freescale.com>
      Tested-by: default avatarBen Gardiner <bengardiner@nanometrics.ca>
      30486322
      History
      nand erase: .spread, .part, .chip subcommands
      Scott Wood authored
      A while back, in http://lists.denx.de/pipermail/u-boot/2009-June/054428.html,
      Michele De Candia posted a patch to not count bad blocks toward the
      requested size to be erased.  This is desireable when you're passing in
      something like $filesize, but not when you're trying to erase a partition.
      
      Thus, a .spread subcommand (named for consistency with
      http://lists.denx.de/pipermail/u-boot/2010-August/075163.html
      
      ) is introduced
      to make explicit the user's desire to erase for a given amount of data,
      rather than to erase a specific region of the chip.
      
      While passing $filesize to "nand erase" is useful, accidentally passing
      something like $fliesize currently produces quite unpleasant results, as the
      variable evaluates to nothing and U-Boot assumes that you want to erase
      the entire rest of the chip/partition.  To improve the safety of the
      erase command, require the user to make explicit their intentions by
      using a .part or .chip subcommand.  This is an incompatible user interface
      change, but keeping compatibility would eliminate the safety gain, and IMHO
      it's worth it.
      
      While touching nand_erase_opts(), make it accept 64-bit offsets and sizes,
      fix the percentage display when erase length is rounded up, eliminate
      an inconsistent warning about rounding up the erase length which only
      happened when the length was less than one block (rounding up for $filesize
      is normal operation), and add a diagnostic if there's an attempt to erase
      beginning at a non-block boundary.
      
      Signed-off-by: default avatarScott Wood <scottwood@freescale.com>
      Tested-by: default avatarBen Gardiner <bengardiner@nanometrics.ca>