10 Apr, 2015

19 commits


09 Apr, 2015

2 commits

  • Email address is not longer valid that's why remove it.

    Signed-off-by: Michal Simek

    Michal Simek
     
  • Since commit 326a682358c1 (malloc_f: enable SYS_MALLOC_F by default
    if DM is on), Zynq MMC boot hangs up after printing the following:

    U-Boot SPL 2015.04-rc5-00053-gadcc570 (Apr 08 2015 - 12:59:11)
    mmc boot
    reading system.dtb

    Prior to commit 326a682358c1, Zynq boards enabled CONFIG_DM, but
    not CONFIG_SYS_MALLOC_F. That commit forcibly turned on
    CONFIG_SYS_MALLOC_F. I have not figured out the root cause, but
    anyway it looks like CONFIG_SYS_MALLOC_F gave a bad impact on the
    Zynq MMC boot.

    We are planning to have the v2015.04 release in a few days.
    I know this is a defensive fixup, but what I can do now is to add
    # CONFIG_SYS_MALLOC_F is not set
    to every Zynq defconfig file to get back the original behavior.

    Tested on:
    - Zedboard
    - ZC706 board

    Signed-off-by: Masahiro Yamada
    Tested-by: Michal Simek
    Cc: Simon Glass

    Masahiro Yamada
     

07 Apr, 2015

8 commits

  • With e37f1eb we now use strict_strtoul() in do_mem_mtest() and this
    gives us a warning:
    ../include/vsprintf.h:38:5: note: expected 'long unsigned int *' but
    argument is of type 'int *'

    Signed-off-by: Tom Rini

    Tom Rini
     
  • Top-level Makefile has option to select dtc binary, but it is ignored
    due to bug in Makefile.lib. Fix it.

    Signed-off-by: Pavel Machek

    Pavel Machek
     
  • Since the Kconfig conversion, boards.cfg scanned by MAKEALL is
    generated by tools/genboardscfg.py. Every board is supposed to have
    its own MAINTAINERS that contains maintainer and status information,
    but, in fact, MAINTAINERS is missing from some boards.

    For such boards, the first field, Status, is filled with '-'.
    It causes a problem for "set" command, which ignores '-' in its
    arguments. Consequently, get_target_arch() returns a wrong field
    and MAKEALL fails to get a correct toolchain.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • Since the Kconfig conversion, config.mk has been included only when
    include/config/auto.conf is newer than the .config file.

    It causes build error if both files have the same time-stamps.
    It is actually possible because EXT* file systems have a 1s time-stamp
    resolution.

    The config.mk should be included when include/config/auto.conf is
    *not older* than the .config file.

    Signed-off-by: Masahiro Yamada
    Reported-by: Tom Rini
    Reported-by: York Sun
    Reported-by: Stephen Warren
    Reported-by: Matthew Gerlach
    Tested-by: Stephen Warren

    Masahiro Yamada
     
  • Back in fc46bae a "clean up" was introduced that intended to reconcile
    some of the AM335x codepaths based on how AM43xx operates.
    Unfortunately this introduced a regression on the DDR2 platforms. This
    was un-noticed on DDR3 (everything except for Beaglebone White) as we
    had already populated sdram_config correctly in sequence. This change
    brings us back to the older behavior and is fine on all platforms.

    Tested on Beaglebone White, Beaglebone Black and AM335x GP EVM

    Reported-by: Matt Ranostay
    Signed-off-by: Tom Rini

    Tom Rini
     
  • Currently, memtest will silently accept bad data. Perform error
    checking on user intput.

    Signed-off-by: Pavel Machek

    Pavel Machek
     
  • In stead of user_buffer_size, transfer_size should be used to pass to
    ahci_device_data_io(). transfer_size is the length that we want the
    low level function to transfer each time.
    If we use user_buffer_size which is the totally data length as parameter,
    low level function will actually create many SGs to transfer as many data
    as possible each time. That will produce many redundant data transfer.

    Signed-off-by: Tang Yuantian
    Reviewed-by: Simon Glass

    Tang Yuantian
     
  • The u-boot environment is redundantly stored in a NOR flash on our boards.
    Redundant means that there are two places to store the environment. But only
    one of the two is active. I discovered that on one board the u-boot (env_sf)
    uses the environment from the second place and the Kernel (fw_printenv) uses
    the environment from the first place.
    To decide which is the active environment there is a byte inside the
    environment. 1 means active and 0 means obsolete. But on that board both
    environments had have a 1. This can happen if a power loss or reset occurs
    during writing the environment. In this situation the u-boot (env_sf)
    implementation uses the second environment as default. But the Kernel
    (fw_printenv) implementation uses the first environment as default.

    This commit corrects the default in the u-boot env_sf implementation when a
    problem was detected. Now the recovery default is the same like in all other
    environment implementations. E.g. fw_printenv and env_flash. This ensures that
    u-boot and Kernel use the same environment.

    Signed-off-by: Mario Schuknecht

    Mario Schuknecht
     

06 Apr, 2015

11 commits