Skip to content
Snippets Groups Projects
  1. Dec 05, 2013
    • Kuo-Jung Su's avatar
      cmd_eeprom: bug fix for i2c read/write · 6ca6d080
      Kuo-Jung Su authored
      
      The local pointer of address (i.e., addr) only gets
      referenced under SPI mode, and it won't be appropriate
      to pass only 1-byte addr[1] to i2c_read/i2c_write while
      CONFIG_SYS_I2C_EEPROM_ADDR_LEN > 1.
      
      1. In U-boot's I2C model, the address would be re-assembled
         to a byte string in MSB order inside I2C controller drivers.
      
      2. The 'CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW' option which could
         be found at soft_i2c.c is always turned on in cmd_eeprom.c,
         the addr[0] always contains the device address with overflowed
         MSB address bits.
      
      Signed-off-by: default avatarKuo-Jung Su <dantesu@faraday-tech.com>
      Cc: Alexey Brodkin <abrodkin@synopsys.com>
      Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
      cc: Peter Tyser <ptyser@xes-inc.com>
      Cc: Heiko Schocher <hs@denx.de>
      Cc: Wolfgang Denk <wd@denx.de>
      Cc: Stefan Roese <sr@denx.de>
      Cc: Mischa Jonker <mjonker@synopsys.com>
      6ca6d080
  2. Nov 25, 2013
    • Masahiro Yamada's avatar
      common: Delete unnecessary rules. · 017ce20f
      Masahiro Yamada authored
      
      The directory tools/ is always built before common/.
      So when envcrc tool is necessary in common/Makefile,
      it already exists.
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.m@jp.panasonic.com>
      017ce20f
    • Tom Rini's avatar
      hash.c: Correct non-hash subcommand crc32 addr-save support · 4b756b01
      Tom Rini authored
      
      In the case of not having CONFIG_CMD_HASH but having CONFIG_CMD_CRC32
      enabled (and not CONFIG_CRC32_VERIFY), we end up in this part of the
      code path on hash_command().  However, we will only have exactly 3 args
      here, and 3 > 3 is false, and we will not try and store the hash at the
      address given as arg #3.  The next problem however is that we've been
      moving argv around so the third value is now in argv[0] not argv[3].
      
      Confirmed on AM335x Beaglebone White.
      
      Signed-off-by: default avatarTom Rini <trini@ti.com>
      4b756b01
  3. Nov 22, 2013
  4. Nov 13, 2013
    • Alexey Brodkin's avatar
      cmd_eeprom: fix i2c_{read|write} usage if env is in I2C EEPROM · a2e0a45d
      Alexey Brodkin authored
      
      Data "offset" is not used directly in case of I2C EEPROM. Istead it is
      split into "block number" and "offset within mentioned block". Which are
      "addr[0]" and "addr[1]" respectively.
      
      Signed-off-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
      
      Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
      cc: Peter Tyser <ptyser@xes-inc.com>
      Cc: Heiko Schocher <hs@denx.de>
      Cc: Wolfgang Denk <wd@denx.de>
      Cc: Stefan Roese <sr@denx.de>
      Cc: Mischa Jonker <mjonker@synopsys.com>
      a2e0a45d
  5. Nov 12, 2013
    • Anatolij Gustschin's avatar
      lcd: allow overriding lcd_get_size() · cefa4717
      Anatolij Gustschin authored
      
      Remove the redundant lcd_line_length initialisation which
      sneaked in when an earlier version of the patch of commit
      6d330719 has been rebased.
      
      Some lcd drivers need to setup lcd_line_length not from the
      panel_info parameters but by different means. Make the
      lcd_get_size() weak to allow setting lcd_line_length in
      a driver specific way.
      
      Signed-off-by: default avatarAnatolij Gustschin <agust@denx.de>
      Cc: Stephen Warren <swarren@wwwdotorg.org>
      cefa4717
  6. Nov 08, 2013
  7. Nov 06, 2013
  8. Nov 04, 2013
  9. Oct 31, 2013
  10. Oct 20, 2013
  11. Oct 17, 2013
    • trem's avatar
      i2c: fix init on generic board · 815a76f2
      trem authored
      
      On generic board, the i2c init initialize only
      one bus. But the new i2c subsystem allow to
      manage severals i2c bus. So in the case, instead
      of initializing a bus, we just set the current
      i2c bus. The initialization will be done in
      the i2c command.
      
      Signed-off-by: default avatarPhilippe Reynes <tremyfr@yahoo.fr>
      815a76f2
  12. Oct 16, 2013
  13. Oct 15, 2013
  14. Oct 14, 2013
  15. Oct 09, 2013
  16. Oct 07, 2013
    • Wolfgang Denk's avatar
      Fix number base handling of "load" command · b770e88a
      Wolfgang Denk authored
      As documented, almost all U-Boot commands expect numbers to be entered
      in hexadecimal input format. (Exception: for historical reasons, the
      "sleep" command takes its argument in decimal input format.)
      
      This rule was broken for the "load" command; for details please see
      especially commits 045fa1e1 "fs: add filesystem switch libary,
      implement ls and fsload commands" and 3f83c87e "fs: fix number base
      behaviour change in fatload/ext*load".  In the result, the load
      command would always require an explicit "0x" prefix for regular
      (i. e. base 16 formatted) input.
      
      Change this to use the standard notation of base 16 input format.
      While strictly speaking this is a change of the user interface, we
      hope that it will not cause trouble.  Stephen Warren comments (see
      [1]):
      
              I suppose you can change the behaviour if you want; anyone
              writing "0x..." for their values presumably won't be
              affected, and if people really do assume all values in U-Boot
              are in hex, presumably nobody currently relies upon using
              non-prefixed values with the generic load command, since it
              doesn't work like that right now.
      
      [1] http://article.gmane.org/gmane.comp.boot-loaders.u-boot/171172
      
      
      
      Acked-by: default avatarTom Rini <trini@ti.com>
      Acked-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarWolfgang Denk <wd@denx.de>
      b770e88a
Loading