12 Feb, 2016

2 commits


10 Feb, 2016

1 commit


08 Feb, 2016

9 commits


06 Feb, 2016

1 commit

  • Correct spelling of "U-Boot" shall be used in all written text
    (documentation, comments in source files etc.).

    Signed-off-by: Bin Meng
    Reviewed-by: Heiko Schocher
    Reviewed-by: Simon Glass
    Reviewed-by: Minkyu Kang

    Bin Meng
     

05 Feb, 2016

1 commit

  • The x86 build target "efi-x86" has no TEXT_BASE configured. And with the
    introduction of CONFIG_BOOTDELAY for x86, this function is now called
    for this board as well. Resulting in compile errors for this target.

    Without TEXT_BASE it makes no sense to fill these values. So lets only
    configure the env variable if TEXT_BASE is defined.

    Signed-off-by: Stefan Roese
    Cc: Simon Glass
    Cc: Bin Meng
    Cc: Tom Rini
    Reviewed-by: Simon Glass
    Reviewed-by: Bin Meng

    Stefan Roese
     

02 Feb, 2016

1 commit

  • Use of memalign can trigger fragmentation issues such as:

    // Internally, this needs to find a free block quite bit larger than s.
    // Once the free region is found, any unaligned "padding" immediately
    // before and after the block is marked free, so that the allocation
    // takes only s bytes (plus malloc header overhead).
    p = memalign(a, s);
    // If there's little fragmentation so far, this allocation is likely
    // located immediately after p.
    p2 = malloc(x);
    free(p);
    // In theory, this should return the same value for p. However, the hole
    // left by the free() call is only s in size (plus malloc header overhead)
    // whereas memalign searches for a larger block in order to guarantee it
    // can adjust the returned pointer to the alignment requirements. Hence,
    // the pointer returned, if any, won't be p. If there's little or no space
    // left after p2, this allocation will fail.
    p = memalign(a, s);

    In practice, this issue occurs when running the "dfu" command repeatedly
    on NVIDIA Tegra boards, since DFU allocates a large 32M data buffer, and
    then initializes the USB controller. If this is the first time USB has
    been used in the U-Boot session, this causes a probe of the USB driver,
    which causes various allocations, including a strdup() of a GPIO name
    when requesting the VBUS GPIO. When DFU is torn down, the USB driver
    is left probed, and hence its memory is left allocated. If "dfu" is
    executed again, allocation of the 32M data buffer fails as described
    above.

    In practice, there is a memory hole exactly large enough to hold the 32M
    data buffer than DFU needs. However, memalign() can't know that in a
    general way. Given that, it's particularly annoying that the allocation
    fails!

    The issue is that memalign() tries to allocate something larger to
    guarantee the ability to align the returned pointer. This patch modifies
    memalign() so that if the "general case" over-sized allocation fails,
    another allocation is attempted, of the exact size the user desired. If
    that allocation just happens to be aligned in the way the user wants,
    (and in the case described above, it will be, since the free memory
    region is located where a previous identical allocation was located),
    the pointer can be returned.

    This patch is somewhat related to 806bd245b1ab "dfu: don't keep
    freeing/reallocating". That patch worked around the issue by removing
    repeated free/memalign within a single execution of "dfu". However,
    the same technique can't be applied across multiple invocations, since
    there's no reason to keep the DFU buffer allocated while DFU isn't
    running. This patch addresses the root-cause a bit more directly.

    This problem highlights some of the disadvantages of dynamic allocation
    and deferred probing of devices.

    This patch isn't checkpatch-clean, since it conforms to the existing
    coding style in dlmalloc.c, which is different to the rest of U-Boot.

    Signed-off-by: Stephen Warren
    Reviewed-by: Tom Rini
    Acked-by: Lukasz Majewski

    Stephen Warren
     

28 Jan, 2016

2 commits


26 Jan, 2016

3 commits


25 Jan, 2016

4 commits

  • clang-3.8 reports that these functions are unused, remove them. As this
    is the last part of CONFIG_MODEM_SUPPORT_DEBUG, drop that from README.

    Reviewed-by: Bin Meng
    Signed-off-by: Tom Rini

    Tom Rini
     
  • This enables boards to choose where to/from the environment should be
    saved/loaded. They can then for example support using the same device
    (dynamically) from which the bootloader was launched to load and save
    env data and do not have to define CONFIG_SYS_MMC_ENV_DEV statically.

    In my use case, the environment needs to be on the same device I
    booted from. It can be the eMMC or an optional SD card.
    I therefore would override mmc_get_env_dev in the board code, read the
    CPU registers to determine where we booted from and return the
    corresponding device index.

    Cc: Tom Rini
    Cc: Stephen Warren
    Cc: Tim Harvey
    Cc: Simon Glass
    Cc: Hans de Goede

    Signed-off-by: Clemens Gruber
    Reviewed-by: Stephen Warren
    Reviewed-by: Tom Rini

    Clemens Gruber
     
  • Variable _load_end_ points to end address of uncompressed buffer
    (*not* uncomress_buffer_end / sizeof(ulong)), so multipling uncompressed
    size with sizeof(ulong) is grossly incorrect in flush_cache().
    It might lead to access of address beyond valid memory range and hang the CPU.

    Tested on MIPS architecture by using compressed(gzip, lzma)
    and uncompressed uImage.

    Signed-off-by: Purna Chandra Mandal
    Reviewed-by: Simon Glass
    Reviewed-by: Daniel Schwierzeck

    Purna Chandra Mandal
     
  • There are a lot of unrelated files in common, including all of the commands.
    Moving them into their own directory makes them easier to find and is more
    logical.

    Some commands include non-command code, such as cmd_scsi.c. This should be
    sorted out at some point so that the function can be enabled with or without
    the associated command.

    Unfortunately, with m68k I get this error:

    m68k: + M5329AFEE
    +arch/m68k/cpu/mcf532x/start.o: In function `_start':
    +arch/m68k/cpu/mcf532x/start.S:159:(.text+0x452): relocation truncated to fit: R_68K_PC16 against symbol `board_init_f' defined in .text.board_init_f section in common/built-in.o

    I hope someone can shed some light on what this means. I hope it isn't
    depending on the position of code in the image.

    Signed-off-by: Simon Glass
    Reviewed-by: Bin Meng
    Reviewed-by: Heiko Schocher
    Acked-by: Stefan Roese
    Acked-by: Przemyslaw Marczak

    Simon Glass
     

24 Jan, 2016

1 commit

  • The testpattern of the lcd was only working in 8bit mode(2x3 tiles in
    different colors). With this patch now 8bit and 16bit is supported.
    In 16bit mode there are 2x4 tiles in different colors.
    The number of LCD-colors is defined in the include/configs/.h

    Signed-off-by: Andreas Neubacher
    Signed-off-by: Anatolij Gustschin

    Andreas Neubacher
     

22 Jan, 2016

4 commits


21 Jan, 2016

10 commits


19 Jan, 2016

1 commit

  • In a number of places we had wordings of the GPL (or LGPL in a few
    cases) license text that were split in such a way that it wasn't caught
    previously. Convert all of these to the correct SPDX-License-Identifier
    tag.

    Signed-off-by: Tom Rini

    Tom Rini