Skip to content
Snippets Groups Projects
  1. Dec 13, 2023
  2. Dec 04, 2023
  3. Nov 29, 2023
  4. Nov 27, 2023
  5. Nov 22, 2023
  6. Nov 20, 2023
  7. Nov 18, 2023
  8. Nov 16, 2023
    • Dmitrii Merkurev's avatar
      cmd: bcb: support various block device interfaces for BCB command · a654369b
      Dmitrii Merkurev authored and Tom Rini's avatar Tom Rini committed
      
      Currently BCB command-line, C APIs and implementation only
      support MMC interface. Extend it to allow various block
      device interfaces.
      
      Signed-off-by: default avatarDmitrii Merkurev <dimorinny@google.com>
      Cc: Eugeniu Rosca <erosca@de.adit-jv.com>
      Cc: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
      Cc: Simon Glass <sjg@chromium.org>
      Cc: Mattijs Korpershoek <mkorpershoek@baylibre.com>
      Cc: Sean Anderson <sean.anderson@seco.com>
      Cc: Cody Schuffelen <schuffelen@google.com>
      Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> # on vim3
      Reviewed-by: default avatarMattijs Korpershoek <mkorpershoek@baylibre.com>
      a654369b
    • Sean Anderson's avatar
      nand: Add sandbox driver · bc8e8a4b
      Sean Anderson authored and Tom Rini's avatar Tom Rini committed
      
      Add a sandbox NAND flash driver to facilitate testing. This driver supports
      any number of devices, each using a single chip-select. The OOB data is
      stored in-band, with the separation enforced through the API.
      
      For now, create two devices to test with. The first is a very small device
      with basic ECC. The second is an 8G device (chosen to be larger than 32
      bits). It uses ONFI, with the values copied from the datasheet. It also
      doesn't need too strong ECC, which speeds things up.
      
      Although the nand subsystem determines the parameters of a chip based on
      the ID, the driver itself requires devicetree properties for each
      parameter. We do not derive parameters from the ID because parsing the ID
      is non-trivial. We do not just use the parameters that the nand subsystem
      has calculated since that is something we should be testing. An exception
      is made for the ECC layout, since that is difficult to encode in the device
      tree and is not a property of the device itself.
      
      Despite using file I/O to access the backing data, we do not support using
      external files. In my experience, these are unnecessary for testing since
      tests can generally be written to write their expected data beforehand.
      Additionally, we would need to store the "programmed" information somewhere
      (complicating the format and the programming process) or try to detect
      whether block are erased at runtime (degrading probe speeds).
      
      Information about whether each page has been programmed is stored in an
      in-memory buffer. To simplify the implementation, we only support a single
      program per erase. While this is accurate for many larger flashes, some
      smaller flashes (512 byte) support multiple programs and/or subpage
      programs. Support for this could be added later as I believe some
      filesystems expect this.
      
      To test ECC, we support error-injection. Surprisingly, only ECC bytes in
      the OOB area are protected, even though all bytes are equally susceptible
      to error. Because of this, we take care to only corrupt ECC bytes.
      Similarly, because ECC covers "steps" and not the whole page, we must take
      care to corrupt data in the same way.
      
      Signed-off-by: default avatarSean Anderson <seanga2@gmail.com>
      bc8e8a4b
  9. Nov 15, 2023
    • Simon Glass's avatar
      bootstd: Add a return code to bootflow menu · 3fa53b95
      Simon Glass authored
      
      Return an error when the user does not select an OS, so we know whether
      to boot or not.
      
      Move calling of bootflow_menu_run() into a separate function so we can
      call it from other places.
      
      Expand the test to cover these cases.
      
      Add some documentation also, while we are here.
      
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      3fa53b95
  10. Nov 11, 2023
  11. Nov 10, 2023
  12. Nov 09, 2023
  13. Nov 07, 2023
  14. Nov 06, 2023
  15. Nov 03, 2023
  16. Nov 02, 2023
  17. Nov 01, 2023
  18. Oct 31, 2023
  19. Oct 27, 2023
Loading