1. 15 3月, 2016 9 次提交
  2. 14 3月, 2016 1 次提交
  3. 13 3月, 2016 1 次提交
  4. 12 3月, 2016 2 次提交
    • M
      sf: Correct data types in stm_is_locked_sr() · ea9619ae
      Marek Vasut 提交于
      The stm_is_locked_sr() function is picked from Linux kernel. For reason
      unknown, the 64bit data types used by the function and present in Linux
      were replaced with 32bit unsigned ones, which causes trouble.
      
      The testcase performed was done using ST M25P80 chip.
      The command used was:
       => sf protect unlock 0 0x10000
      
      The call chain starts in stm_unlock(), which calls stm_is_locked_sr()
      with negative ofs argument. This works fine in Linux, where the "ofs"
      is loff_t, which is signed long long, while this fails in U-Boot, where
      "ofs" is u32 (unsigned int). Because of this signedness problem, the
      expression past the return statement to be incorrectly evaluated to 1,
      which in turn propagates back to stm_unlock() and results in -EINVAL.
      
      The correction is very simple, just use the correctly sized data types
      with correct signedness in the function to make it work as intended.
      Signed-off-by: NMarek Vasut <marex@denx.de>
      Cc: Simon Glass <sjg@chromium.org>
      Reviewed-by: NJagan Teki <jteki@openedev.com>
      ea9619ae
    • L
      dm: ti_qspi: Fix conversion of address to a pointer · e6601df8
      Lokesh Vutla 提交于
      TI QSPI driver directly typecasts fdt_addr_t to a pointer. This is
      not strictly correct, as it gives a build warning when fdt_addr_t is u64.
      So, use map_physmem for a proper typecasts.
      
      This is inspired by commit 167efe01 ("dm: ns16550: Use an address
      instead of a pointer for the uart base")
      Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
      Reviewed-by: NJagan Teki <jteki@openedev.com>
      Reviewed-by: NTom Rini <trini@konsulko.com>
      Reviewed-by: NMugunthan V N <mugunthanvnm@ti.com>
      e6601df8
  5. 11 3月, 2016 1 次提交
  6. 10 3月, 2016 4 次提交
  7. 09 3月, 2016 14 次提交
    • D
      MIPS: pic32mzdask: use CONFIG_USE_PRIVATE_LIBGCC=y · 40a09be2
      Daniel Schwierzeck 提交于
      MIPS EL boards should define CONFIG_USE_PRIVATE_LIBGCC=y to work
      with EB-only toolchains like the one from kernel.org. If one do
      not globally set CONFIG_USE_PRIVATE_LIBGCC=y, the build fails with:
      
      /opt/gcc-4.9.0-nolibc/mips-linux/bin/mips-linux-ld.bfd: /opt/gcc-4.9.0-nolibc/mips-linux/bin/../lib/gcc/mips-linux/4.9.0/libgcc.a(_lshrdi3.o): compiled for a big endian system and target is little endian
      /opt/gcc-4.9.0-nolibc/mips-linux/bin/mips-linux-ld.bfd: /opt/gcc-4.9.0-nolibc/mips-linux/bin/../lib/gcc/mips-linux/4.9.0/libgcc.a(_lshrdi3.o): endianness incompatible with that of the selected emulation
      /opt/gcc-4.9.0-nolibc/mips-linux/bin/mips-linux-ld.bfd: failed to merge target specific data of file /opt/gcc-4.9.0-nolibc/mips-linux/bin/../lib/gcc/mips-linux/4.9.0/libgcc.a(_lshrdi3.o)
      /opt/gcc-4.9.0-nolibc/mips-linux/bin/mips-linux-ld.bfd: /opt/gcc-4.9.0-nolibc/mips-linux/bin/../lib/gcc/mips-linux/4.9.0/libgcc.a(_ashldi3.o): compiled for a big endian system and target is little endian
      /opt/gcc-4.9.0-nolibc/mips-linux/bin/mips-linux-ld.bfd: /opt/gcc-4.9.0-nolibc/mips-linux/bin/../lib/gcc/mips-linux/4.9.0/libgcc.a(_ashldi3.o): endianness incompatible with that of the selected emulation
      /opt/gcc-4.9.0-nolibc/mips-linux/bin/mips-linux-ld.bfd: failed to merge target specific data of file /opt/gcc-4.9.0-nolibc/mips-linux/bin/../lib/gcc/mips-linux/4.9.0/libgcc.a(_ashldi3.o)
      /work/git-trees/u-boot-mips/Makefile:1171: recipe for target 'u-boot' failed
      
      One example for a failing build is Travis CI.
      Signed-off-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com>
      Reviewed-by: NPurna Chandra Mandal <purna.mandal@microchip.com>
      40a09be2
    • M
      MIPS: fix mips_cache fallback without __builtin_mips_cache · 499b8475
      Matthias Schiffer 提交于
      The "R" constraint supplies the address of an variable in a register. Use
      "r" instead and adjust asm to supply the content of addr in a register
      instead.
      
      Fixes: 2b8bcc5a ("MIPS: avoid .set ISA for cache operations")
      Signed-off-by: NMatthias Schiffer <mschiffer@universe-factory.net>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
      499b8475
    • S
      malloc: remove !gd handling · deff6fb3
      Stephen Warren 提交于
      Following the previous patch, malloc() is never called before gd is set,
      so we can remove the special-case check for this condition.
      
      This reverts commit 854d2b97 "dlmalloc: ensure gd is set for early
      alloc".
      
      Cc: Rabin Vincent <rabin@rab.in>
      Signed-off-by: NStephen Warren <swarren@wwwdotorg.org>
      Reviewed-by: NTom Rini <trini@konsulko.com>
      Reviewed-by: NSimon Glass <sjg@chromium.org>
      deff6fb3
    • S
      malloc: use hidden visibility · 2f0bcd4d
      Stephen Warren 提交于
      When running sandbox, the following phases occur, each with different
      malloc implementations or behaviors:
      
      1) Dynamic linker execution, using the dynamic linker's own malloc()
      implementation. This is fully functional.
      
      2) After U-Boot's malloc symbol has been hooked into the GOT, but before
      any U-Boot code has run. This phase is entirely non-functional, since
      U-Boot's gd symbol is NULL and U-Boot's initf_malloc() and
      mem_malloc_init() have not been called.
      
      At least on Ubuntu Xenial, the dynamic linker does make both malloc() and
      free() calls during this phase. Currently these free() calls crash since
      they dereference gd, which is NULL.
      
      U-Boot itself makes no use of malloc() during this phase.
      
      3) U-Boot execution after gd is set and initf_malloc() has been called.
      This is fully functional, albeit via a very simple malloc()
      implementation.
      
      4) U-Boot execution after mem_malloc_init() has been called. This is fully
      functional with a complete malloc() implementation.
      
      Furthermore, if code that called malloc() during phase 1 calls free() in
      phase 3 or later, it is likely that heap corruption will occur, since
      U-Boot's malloc implementation will assume the pointer is part of its own
      heap, although it isn't. I have not actively observed this happening.
      
      To prevent phase 2 from happening, this patch makes all of U-Boot's malloc
      library public symbols have hidden visibility. This prevents them from
      being hooked into the GOT, so only code in the U-Boot binary itself
      actually calls them; any other code will call into the standard C library
      malloc(). This also avoids the "furthermore" issue mentioned above.
      
      I have seen references to this GCC pragma in blog posts from 2008, and
      RHEL5's ancient gcc appears to accept it fine, so I believe it's quite
      safe to use it without checking gcc version.
      
      Cc: Rabin Vincent <rabin@rab.in>
      Signed-off-by: NStephen Warren <swarren@wwwdotorg.org>
      Reviewed-by: NTom Rini <trini@konsulko.com>
      Reviewed-by: NSimon Glass <sjg@chromium.org>
      2f0bcd4d
    • T
      sandbox: Fix building with LLVM · 699946ae
      Tom Rini 提交于
      - The macro __BIGGEST_ALIGNMENT__ is gcc-specific.  If it is not defined
        we'll just assume 16.  This is correct for at least the common cases
        and LLVM does not provide an equivalent macro.
      - When linking U-Boot we're passing -T to the linker, and while gcc will
        just pass this along with LLVM we need to be specific.
      
      Cc: Simon Glass <sjg@chromium.org>
      Signed-off-by: NTom Rini <trini@konsulko.com>
      Reviewed-by: NSimon Glass <sjg@chromium.org>
      699946ae
    • A
      omap3: Use raw SPL by default for mmc1 · 22d90d56
      Alexander Graf 提交于
      Now that we fall back to the FS code path when we don't find u-boot
      at the raw sector offset, there is no good reason to not default to
      raw boot.
      
      With this patch, I can successfully boot u-boot from a raw sector
      offset on beagle-xm.
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      22d90d56
    • S
      api: Export API structure address as an environment variable · 22aa61f7
      Stanislav Galabov 提交于
      This patch makes the U-Boot api export its structure address as an environment
      variable, so it can be used to directly hint FreeBSD's loader of api's location.
      
      The relevant FreeBSD loader change is currently under review at:
      https://reviews.freebsd.org/D5492Signed-off-by: NStanislav Galabov <sgalabov@gmail.com>
      22aa61f7
    • D
      OMAP3: am3517_evm: Add NAND MTD partitions with UBI/UBIFS support · 3f53e619
      Derald D. Woods 提交于
      - Add required UBI/UBIFS config definitions
      - Add reasonable MTD partition layout
      - Remove JFFS2 config definitions
      - Drop some CFI verbage and definitions
      - Make comment 'one-liners' truly one line
      - Improve readability and content arrangement
      Signed-off-by: NDerald D. Woods <woods.technical@gmail.com>
      Reviewed-by: NTom Rini <trini@konsulko.com>
      3f53e619
    • D
      OMAP3: am3517_evm: Use BCH8 ECC for NAND · 138daa7b
      Derald D. Woods 提交于
      Select 8-bit BCH ecc-scheme with s/w based error correction
      - OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
      Signed-off-by: NDerald D. Woods <woods.technical@gmail.com>
      Reviewed-by: NTom Rini <trini@konsulko.com>
      138daa7b
    • M
      ARM: uniphier: allow debug_ll_init() to do nothing for unknown SoCs · 5d076486
      Masahiro Yamada 提交于
      This function should just return for unknown SoCs rather than writing
      unexpected values to registers.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      5d076486
    • M
      pinctrl: uniphier: guard uniphier directory with CONFIG_PINCTRL_UNIPHIER · 1d22c4b1
      Masahiro Yamada 提交于
      CONFIG_PINCTRL_UNIPHIER is more suitable than CONFIG_ARCH_UNIPHIER
      to guard the drivers/pinctrl/uniphier directory.
      
      The current CONFIG_PINCTRL_UNIPHIER_CORE is a bit long, so rename it
      into CONFIG_PINCTRL_UNIPHIER.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      1d22c4b1
    • M
      pinctrl: uniphier: set input-enable before pin-muxing · fdd15b6a
      Masahiro Yamada 提交于
      While IECTRL is disabled, input signals are pulled-down internally.
      If pin-muxing is set up first, glitch signals (Low to High transition)
      might be input to hardware blocks.
      
      Bad case scenario:
      [1] The hardware block is already running before pinctrl is handled.
         (the reset is de-asserted by default or by a firmware, for example)
      [2] The pin-muxing is set up.  The input signals to hardware block
         are pulled-down by the chip-internal biasing.
      [3] The pins are input-enabled.  The signals from the board reach the
          hardware block.
      
      Actually, one invalid character is input to the UART blocks for such
      SoCs as PH1-LD4, PH1-sLD8, where UART devices start to run at the
      power on reset.
      
      To avoid such problems, pins should be input-enabled before muxing.
      
      [ ported from Linux commit bac7f4c1bf5e7c6ccd5bb71edc015b26c77f7460 ]
      
      Fixes: 5dc626f8 ("pinctrl: uniphier: add UniPhier pinctrl core support")
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      fdd15b6a
    • M
      ARM: uniphier: fix build error when CONFIG_CMD_DDRMPHY_DUMP=y · 51244a60
      Masahiro Yamada 提交于
      The build fails if compiled with CONFIG_CMD_DDRMPHY_DUMP=y since commit
      46abfcc9 ("ARM: uniphier: rework struct uniphier_board_data").
      
      Fixes: 46abfcc9 ("ARM: uniphier: rework struct uniphier_board_data")
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      51244a60
    • M
  8. 05 3月, 2016 2 次提交
  9. 02 3月, 2016 5 次提交
  10. 01 3月, 2016 1 次提交
    • S
      usb: gadget: composite: Correct recovery path for register · 8038f6d2
      Sam Protsenko 提交于
      In case when usb_composite_register() failed once (for whatever reason),
      it will fail further even if all conditions are correct. Example:
      
          => fastboot 2
          Invalid Controller Index
          couldn't find an available UDC
          g_dnl_register: failed!, error: -19
          exit not allowed from main input shell.
      
          => fastboot 0
          g_dnl_register: failed!, error: -22
          exit not allowed from main input shell.
      
      Despite that 0 is correct index for USB controller, "fastboot 0" command
      will fail, because "composite" structure wasn't cleared properly on
      previous fail (on "fastboot 2" command).
      
      This patch fixes that erroneous behavior, allowing us to use composite
      even after previous failure.
      Signed-off-by: NSam Protsenko <semen.protsenko@linaro.org>
      8038f6d2