1. 15 Aug, 2016 1 commit
  2. 14 Jul, 2016 1 commit
  3. 11 Jul, 2016 1 commit
  4. 27 May, 2016 1 commit
  5. 16 Jan, 2016 1 commit
  6. 14 Dec, 2015 1 commit
  7. 03 Dec, 2015 1 commit
  8. 24 Oct, 2015 1 commit
  9. 22 Oct, 2015 2 commits
  10. 28 Aug, 2015 1 commit
  11. 27 Jul, 2015 1 commit
  12. 07 Jul, 2015 1 commit
  13. 15 Jun, 2015 1 commit
  14. 30 Apr, 2015 1 commit
  15. 18 Apr, 2015 1 commit
    • Masahiro Yamada's avatar
      dm: select CONFIG_DM* options · 58d423b8
      Masahiro Yamada authored
      As mentioned in the previous commit, adding default values in each
      Kconfig causes problems because it does not co-exist with the
      "depends on" syntax.  (Please note this is not a bug of Kconfig.)
      We should not do so unless we have a special reason.  Actually,
      for CONFIG_DM*, we have no good reason to do so.
      Generally, CONFIG_DM is not a user-configurable option.  Once we
      convert a driver into Driver Model, the board only works with Driver
      Model, i.e. CONFIG_DM must be always enabled for that board.
      So, using "select DM" is more suitable rather than allowing users to
      modify it.  Another good thing is, Kconfig warns unmet dependencies
      for "select" syntax, so we easily notice bugs.
      Actually, CONFIG_DM and other related options have been added
      without consistency: some into arch/*/Kconfig, some into
      board/*/Kconfig, and some into configs/*_defconfig.
      This commit prefers "select" and cleans up the following issues.
      [1] Never use "CONFIG_DM=n" in defconfig files
      It is really rare to add "CONFIG_FOO=n" to disable CONFIG options.
      It is more common to use "# CONFIG_FOO is not set".  But here, we
      do not even have to do it.
      Less than half of OMAP3 boards have been converted to Driver Model.
      Adding the default values to arch/arm/cpu/armv7/omap3/Kconfig is
      weird.  Instead, add "select DM" only to appropriate boards, which
      eventually eliminates "CONFIG_DM=n", etc.
      [2] Delete redundant CONFIGs
      Sandbox sets CONFIG_DM in arch/sandbox/Kconfig and defines it again
      in configs/sandbox_defconfig.
      Likewise, OMAP3 sets CONFIG_DM arch/arm/cpu/armv7/omap3/Kconfig and
      defines it also in omap3_beagle_defconfig and devkit8000_defconfig.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
  16. 03 Apr, 2015 1 commit
  17. 28 Mar, 2015 2 commits
  18. 12 Feb, 2015 1 commit
  19. 09 Feb, 2015 1 commit
    • Alexey Brodkin's avatar
      arc: build libgcc in U-Boot · a67ef280
      Alexey Brodkin authored
      This way we may have very limited set of functions implemented so we
      save some space.
      Also it allows us to build U-Boot for any ARC core with the same one
      toolchain because we don't rely on pre-built libgcc.
      For example:
       * we may use little-endian toolchain but build U-Boot for ether
       * we may use non-multilibbed uClibc toolchain but build U-Boot for
      whatever ARC CPU flavour that current GCC supports
      Private libgcc built from generic C implementation contributes only 144
      bytes to .text section so we don't see significant degradation of size:
      $ arc-linux-size u-boot.libgcc-prebuilt
         text	   data	    bss	    dec	    hex	filename
       222217	  24912	 214820	 461949	  70c7d	u-boot.libgcc-prebuilt
      $ arc-linux-size u-boot.libgcc-private
         text	   data	    bss	    dec	    hex	filename
       222361	  24912	 214820	 462093	  70d0d	u-boot.libgcc-private
      Also I don't notice visible performance degradation compared to
      pre-built libgcc (where at least "*div*" functions are had-written in
      assembly) on typical operations of downloading 10Mb uImage over TFTP and
      Signed-off-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
  20. 23 Oct, 2014 1 commit
  21. 25 Sep, 2014 1 commit
  22. 13 Sep, 2014 1 commit
  23. 30 Jul, 2014 1 commit