Skip to content
Snippets Groups Projects
Select Git revision
0 results
Search by author
  • Any Author
0 authors
  1. Mar 14, 2016
  3. Mar 13, 2016
  5. Mar 12, 2016
    • Marek Vasut's avatar
      sf: Correct data types in stm_is_locked_sr() · ea9619ae
      Marek Vasut authored 
      
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: default avatarMarek Vasut <marex@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: default avatarJagan Teki <jteki@openedev.com>
      ea9619ae
    • Lokesh Vutla's avatar
      dm: ti_qspi: Fix conversion of address to a pointer · e6601df8
      Lokesh Vutla authored 
      
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: default avatarLokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: default avatarJagan Teki <jteki@openedev.com>
Reviewed-by: default avatarTom Rini <trini@konsulko.com>
Reviewed-by: default avatarMugunthan V N <mugunthanvnm@ti.com>
      e6601df8
  7. Mar 11, 2016
  9. Mar 10, 2016
  11. Mar 09, 2016
    • Daniel Schwierzeck's avatar
      MIPS: pic32mzdask: use CONFIG_USE_PRIVATE_LIBGCC=y · 40a09be2
      Daniel Schwierzeck authored 
      
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: default avatarDaniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: default avatarPurna Chandra Mandal <purna.mandal@microchip.com>
      40a09be2
    • Matthias Schiffer's avatar
      MIPS: fix mips_cache fallback without __builtin_mips_cache · 499b8475
      Matthias Schiffer authored 
      
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: default avatarMatthias Schiffer <mschiffer@universe-factory.net>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
      499b8475
  13. Mar 08, 2016
    • Stephen Warren's avatar
      malloc: remove !gd handling · deff6fb3
      Stephen Warren authored 
      
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: default avatarStephen Warren <swarren@wwwdotorg.org>
Reviewed-by: default avatarTom Rini <trini@konsulko.com>
Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
      deff6fb3
    • Stephen Warren's avatar
      malloc: use hidden visibility · 2f0bcd4d
      Stephen Warren authored 
      
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: default avatarStephen Warren <swarren@wwwdotorg.org>
Reviewed-by: default avatarTom Rini <trini@konsulko.com>
Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
      2f0bcd4d
    • Tom Rini's avatar
      sandbox: Fix building with LLVM · 699946ae
      Tom Rini authored 
      
- 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: default avatarTom Rini <trini@konsulko.com>
Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
      699946ae
    • Alexander Graf's avatar
      omap3: Use raw SPL by default for mmc1 · 22d90d56
      Alexander Graf authored 
      
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: default avatarAlexander Graf <agraf@suse.de>
      22d90d56