Eric Lee / smarc-uboot

02 Oct, 2016

1 commit

16 Aug, 2016

1 commit

  • c978b5241   xtensa: add support for the xtensa processor architecture [2/2] ... Browse Code »

    The Xtensa processor architecture is a configurable, extensible,
    and synthesizable 32-bit RISC processor core provided by Tensilica, inc.

    This is the second part of the basic architecture port, adding the
    'arch/xtensa' directory and a readme file.

    Signed-off-by: Chris Zankel
    Signed-off-by: Max Filippov
    Reviewed-by: Simon Glass
    Reviewed-by: Tom Rini

    Chris Zankel
     

15 Jul, 2016

1 commit

  • 9a387128e   linux/io.h: add generic ioremap()/iounmap() defines ... Browse Code »

    For most of architectures in U-Boot, virtual address is straight
    mapped to physical address. So, it makes sense to have generic
    defines of ioremap and friends in .

    All of them are just empty and will disappear at compile time, but
    they will be helpful to implement drivers which are counterparts of
    Linux ones.

    I notice MIPS already has its own implementation, so I added a
    Kconfig symbol CONFIG_HAVE_ARCH_IOREMAP which MIPS (and maybe
    Sandbox as well) can select.

    Signed-off-by: Masahiro Yamada
    Reviewed-by: Daniel Schwierzeck

    Masahiro Yamada
     

12 Jul, 2016

1 commit

28 May, 2016

1 commit

17 Jan, 2016

1 commit

14 Dec, 2015

1 commit

03 Dec, 2015

1 commit

25 Oct, 2015

1 commit

  • 09f3ca3dd   arm, powerpc: select SYS_GENERIC_BOARD ... Browse Code »

    We have finished Generic Board conversion for ARM and PowerPC, i.e.
    all the boards have been converted except OpenRISC, SuperH, SPARC,
    which have not supported Generic Board framework yet.

    Select SYS_GENERIC_BOARD in arch/Kconfig and delete all the macro
    defines in include/configs/*.h.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     

23 Oct, 2015

2 commits

28 Aug, 2015

1 commit

28 Jul, 2015

1 commit

07 Jul, 2015

1 commit

15 Jun, 2015

1 commit

30 Apr, 2015

1 commit

19 Apr, 2015

1 commit

  • 58d423b88   dm: select CONFIG_DM* options ... Browse Code »

    As mentioned in the previous commit, adding default values in each
    Kconfig causes problems because it does not co-exist with the
    "depends on" syntax. (Please note this is not a bug of Kconfig.)
    We should not do so unless we have a special reason. Actually,
    for CONFIG_DM*, we have no good reason to do so.

    Generally, CONFIG_DM is not a user-configurable option. Once we
    convert a driver into Driver Model, the board only works with Driver
    Model, i.e. CONFIG_DM must be always enabled for that board.
    So, using "select DM" is more suitable rather than allowing users to
    modify it. Another good thing is, Kconfig warns unmet dependencies
    for "select" syntax, so we easily notice bugs.

    Actually, CONFIG_DM and other related options have been added
    without consistency: some into arch/*/Kconfig, some into
    board/*/Kconfig, and some into configs/*_defconfig.

    This commit prefers "select" and cleans up the following issues.

    [1] Never use "CONFIG_DM=n" in defconfig files

    It is really rare to add "CONFIG_FOO=n" to disable CONFIG options.
    It is more common to use "# CONFIG_FOO is not set". But here, we
    do not even have to do it.
    Less than half of OMAP3 boards have been converted to Driver Model.
    Adding the default values to arch/arm/cpu/armv7/omap3/Kconfig is
    weird. Instead, add "select DM" only to appropriate boards, which
    eventually eliminates "CONFIG_DM=n", etc.

    [2] Delete redundant CONFIGs

    Sandbox sets CONFIG_DM in arch/sandbox/Kconfig and defines it again
    in configs/sandbox_defconfig.
    Likewise, OMAP3 sets CONFIG_DM arch/arm/cpu/armv7/omap3/Kconfig and
    defines it also in omap3_beagle_defconfig and devkit8000_defconfig.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     

03 Apr, 2015

1 commit

28 Mar, 2015

2 commits

13 Feb, 2015

1 commit

09 Feb, 2015

1 commit

  • a67ef280f   arc: build libgcc in U-Boot ... Browse Code »

    This way we may have very limited set of functions implemented so we
    save some space.

    Also it allows us to build U-Boot for any ARC core with the same one
    toolchain because we don't rely on pre-built libgcc.

    For example:
    * we may use little-endian toolchain but build U-Boot for ether
    endianess
    * we may use non-multilibbed uClibc toolchain but build U-Boot for
    whatever ARC CPU flavour that current GCC supports

    Private libgcc built from generic C implementation contributes only 144
    bytes to .text section so we don't see significant degradation of size:
    --->8---
    $ arc-linux-size u-boot.libgcc-prebuilt
    text data bss dec hex filename
    222217 24912 214820 461949 70c7d u-boot.libgcc-prebuilt

    $ arc-linux-size u-boot.libgcc-private
    text data bss dec hex filename
    222361 24912 214820 462093 70d0d u-boot.libgcc-private
    --->8---

    Also I don't notice visible performance degradation compared to
    pre-built libgcc (where at least "*div*" functions are had-written in
    assembly) on typical operations of downloading 10Mb uImage over TFTP and
    bootm.

    Signed-off-by: Alexey Brodkin

    Alexey Brodkin
     

24 Oct, 2014

1 commit

  • 45ccec8f2   kconfig: move CONFIG_USE_PRIVATE_LIBGCC to Kconfig ... Browse Code »

    The private libgcc is supported only on ARM, MIPS, PowerPC, SH, x86.
    Those architectures should "select" HAVE_PRIVATE_LIBGCC and
    CONFIG_USE_PRIVATE_LIBGCC should depend on it.

    Currently, this option is enabled on Tegra boards and x86 architecture.
    Move the definition from header files to Kconfig.

    Signed-off-by: Masahiro Yamada
    Tested-by: Simon Glass
    Acked-by: Simon Glass
    Cc: Stephen Warren
    Cc: Tom Warren

    Masahiro Yamada
     

25 Sep, 2014

1 commit

  • 783e6a72b   kconfig: move CONFIG_OF_* to Kconfig ... Browse Code »
    43

    This commit moves:
    CONFIG_OF_CONTROL
    CONFIG_OF_SEPARATE
    CONFIG_OF_EMBED
    CONFIG_OF_HOSTFILE

    Because these options are currently not supported for SPL,
    the "Device Tree Control" menu does not appear in the SPL
    configuration.

    Note:
    zynq-common.h should be adjusted so as not to change the
    default value of CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME.

    Signed-off-by: Masahiro Yamada
    Acked-by: Simon Glass
    Cc: Stephen Warren
    Cc: Minkyu Kang
    Acked-by: Michal Simek

    Masahiro Yamada
     

14 Sep, 2014

1 commit

30 Jul, 2014

1 commit