14 Sep, 2014

1 commit

  • Now the types of CONFIG_SYS_{ARCH, CPU, SOC, VENDOR, BOARD, CONFIG_NAME}
    are specified in arch/Kconfig.

    We can delete the ones in arch and board Kconfig files.

    This commit can be easily reproduced by the following command:

    find . -name Kconfig -a ! -path ./arch/Kconfig | xargs sed -i -e '
    /config[[:space:]]SYS_\(ARCH\|CPU\|SOC\|\VENDOR\|BOARD\|CONFIG_NAME\)/ {
    N
    s/\n[[:space:]]*string//
    }
    '

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     

30 Jul, 2014

2 commits

  • We have switched to Kconfig and the boards.cfg file is going to
    be removed. We have to retrieve the board status and maintainers
    information from it.

    The MAINTAINERS format as in Linux Kernel would be nice
    because we can crib the scripts/get_maintainer.pl script.

    After some discussion, we chose to put a MAINTAINERS file under each
    board directory, not the top-level one because we want to collect
    relevant information for a board into a single place.

    TODO:
    Modify get_maintainer.pl to scan multiple MAINTAINERS files.

    Signed-off-by: Masahiro Yamada
    Suggested-by: Tom Rini
    Acked-by: Simon Glass

    Masahiro Yamada
     
  • This commit adds:
    - arch/${ARCH}/Kconfig
    provide a menu to select target boards
    - board/${VENDOR}/${BOARD}/Kconfig or board/${BOARD}/Kconfig
    set CONFIG macros to the appropriate values for each board
    - configs/${TARGET_BOARD}_defconfig
    default setting of each board

    (This commit was automatically generated by a conversion script
    based on boards.cfg)

    In Linux Kernel, defconfig files are located under
    arch/${ARCH}/configs/ directory.
    It works in Linux Kernel since ARCH is always given from the
    command line for cross compile.

    But in U-Boot, ARCH is not given from the command line.
    Which means we cannot know ARCH until the board configuration is done.
    That is why all the "*_defconfig" files should be gathered into a
    single directory ./configs/.

    Signed-off-by: Masahiro Yamada
    Acked-by: Simon Glass

    Masahiro Yamada
     

09 May, 2014

1 commit


14 Mar, 2014

1 commit


05 Mar, 2014

4 commits


13 Jan, 2014

1 commit


13 Nov, 2013

3 commits


10 Nov, 2013

1 commit

  • Conflicts:
    arch/arm/cpu/arm926ejs/mxs/Makefile
    board/compulab/cm_t35/Makefile
    board/corscience/tricorder/Makefile
    board/ppcag/bg0900/Makefile
    drivers/bootcount/Makefile
    include/configs/omap4_common.h
    include/configs/pdnb3.h

    Makefile conflicts are due to additions/removals of
    object files on the ARM branch vs KBuild introduction
    on the main branch. Resolution consists in adjusting
    the list of object files in the main branch version.
    This also applies to two files which are not listed
    as conflicting but had to be modified:

    board/compulab/common/Makefile
    board/udoo/Makefile

    include/configs/omap4_common.h conflicts are due to
    the OMAP4 conversion to ti_armv7_common.h on the ARM
    side, and CONFIG_SYS_HZ removal on the main side.
    Resolution is to convert as this icludes removal of
    CONFIG_SYS_HZ.

    include/configs/pdnb3.h is due to a removal on ARM side.
    Trivial resolution is to remove the file.

    Note: 'git show' will also list two files just because
    they are new:

    include/configs/am335x_igep0033.h
    include/configs/omap3_igep00x0.h

    Albert ARIBAUD
     

04 Nov, 2013

1 commit


01 Nov, 2013

1 commit


31 Jul, 2013

1 commit


27 Jul, 2013

1 commit


24 Jul, 2013

1 commit


26 Jun, 2013

1 commit


03 Jun, 2013

1 commit


16 May, 2013

1 commit


28 Apr, 2013

1 commit

  • PUE requires PKE to mean something, as do pull values with PUE, so do not
    compell users to explicitly use PKE and PUE everywhere. This is also what is
    done on Linux and what has already been done for i.MX51.

    By the way, remove some unused pad control definitions.

    There is no change of behavior.

    Note that SPI_PAD_CTRL was defined by several boards with a pull value, but
    without PKE or PUE, which means that no pull was actually enabled in the pad.
    This might be a bug in those boards, but this patch does not change the
    behavior, so it just removes the meaningless pull value from those definitions.

    Signed-off-by: Benoît Thébaudeau

    Benoît Thébaudeau
     

26 Apr, 2013

3 commits


03 Apr, 2013

2 commits

  • When booting a Freescale kernel 3.0.35 on a Wandboard solo, the get_board_rev()
    returns 0x62xxx, which is not a value understood by the VPU
    (Video Processing Unit) library in the kernel and causes the video playback to
    fail.

    The expected values for get_board_rev are:
    0x63xxx: For mx6quad/dual
    0x61xxx: For mx6dual-lite/solo

    So adjust get_board_rev() accordingly and make it as weak function, so that we
    do not need to define it in every mx6 board file.

    Signed-off-by: Fabio Estevam
    Acked-by: Dirk Behme
    Acked-by: Eric Nelson

    Fabio Estevam
     
  • Maximum bus width supported by some i.MX6 boards is not 8bit like
    others. In case where both host controller and card support 8bit transfers,
    they agree to communicate on 8bit interface while some boards support only 4bit interface.
    Due to this reason the mmc 8bit default mode fails on these boards. To rectify this,
    define maximum bus width supported by these boards (4bit). If max_bus_width is not
    defined, it is 0 by default and 8bit width support will be enabled in host
    capabilities otherwise host capabilities are modified accordingly.

    It is tested with a MMCplus card.

    Signed-off-by: Abbas Raza
    cc: stefano Babic
    cc: Andy Fleming
    Acked-by: Dirk Behme
    Acked-by: Andrew Gabbasov

    Abbas Raza
     

20 Mar, 2013

1 commit