Skip to content

U
U-Boot.Mirror

OS / U-Boot.Mirror

通知 1
Star 0
Fork 0
U
U-Boot.Mirror

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 19 4月, 2015 4 次提交
    • M
      ARM: mx6: use "select" instead of default value in defconfig · b507c5e6
      由 Masahiro Yamada 提交于 
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: NSimon Glass <sjg@chromium.org>
      b507c5e6
    • M
      ARM: zynq: use "select" instead of default value in defconfig · 8981f05c
      由 Masahiro Yamada 提交于 
      All the Zynq boards have switch to Driver Model.
"select DM" is better than default value in each defconfig.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: NSimon Glass <sjg@chromium.org>
      8981f05c
    • M
      ARM: UniPhier: use "select" instead of default value in defconfig · 4e819950
      由 Masahiro Yamada 提交于 
      All the UniPhier boards have switch to Driver Model.
"select DM" is better than default value in each defconfig.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: NSimon Glass <sjg@chromium.org>
      4e819950
    • M
      dm: select CONFIG_DM* options · 58d423b8
      由 Masahiro Yamada 提交于 
      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: NMasahiro Yamada <yamada.masahiro@socionext.com>
      58d423b8
  3. 10 4月, 2015 1 次提交
    • A
      lpc32xx: add support for board work_92105 · 412ae53a
      由 Albert ARIBAUD \(3ADEV\) 提交于 
      Work_92105 from Work Microwave is an LPC3250-
based board with the following features:
- 64MB or 128MB SDR DRAM
- 1 GB SLC NAND, managed through MLC controller.
- Ethernet
- Ethernet + PHY SMSC8710
- I2C:
  - EEPROM (24M01-compatible)
  - RTC (DS1374-compatible)
  - Temperature sensor (DS620)
  - DACs (2 x MAX518)
- SPI (through SSP interface)
  - Port expander MAX6957
- LCD display (HD44780-compatible), controlled
  through the port expander and DACs

This board has SPL support, and uses the LPC32XX boot
image format.
Signed-off-by: NAlbert ARIBAUD (3ADEV) <albert.aribaud@3adev.fr>
      412ae53a
  5. 09 4月, 2015 1 次提交
  7. 28 3月, 2015 1 次提交
  9. 23 3月, 2015 2 次提交
    • B
      ARM: iMX: define an IMX_CONFIG Kconfig option · a05a6045
      由 Boris BREZILLON 提交于 
      IMX_CONFIG is currently passed via the SYS_EXTRA_OPTIONS which is marked
as deprecated.

Add a new Kconfig file under arch/arm/imx-common and define the
IMX_CONFIG Kconfig in there.

Each board is supposed to provide a default value pointing to the
appropriate imximage.cfg file.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      a05a6045
    • B
      ARM: mx6: move to a standard arch/board approach · 89ebc821
      由 Boris BREZILLON 提交于 
      Freescale boards are currently all defined in arch/arm/Kconfig, which
makes them hard to detect.
Moreover the MX6 SoC variant (Q, D, DL, S, SL) selection is currently
done via the SYS_EXTRA_OPTIONS option which marked as deprecated.

Move to a more standard way to select sub-architecture and board by
creating a Kconfig under arch/arm/cpu/armv7/mx6 and a new ARCH_MX6
option.

Existing MX6 board definitions should be moved in this new Kconfig in
choice menu, and new boards should be directly declared in this menu.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      89ebc821
  11. 09 3月, 2015 1 次提交
    • L
      armv8/vexpress64: make multientry conditional · 23b5877c
      由 Linus Walleij 提交于 
      While the Freescale ARMv8 board LS2085A will enter U-Boot both
on a master and a secondary (slave) CPU, this is not the common
behaviour on ARMv8 platforms. The norm is that U-Boot is entered
from the master CPU only, while the other CPUs are kept in
WFI (wait for interrupt) state.

The code determining which CPU we are running on is using the
MPIDR register, but the definition of that register varies with
platform to some extent, and handling multi-cluster platforms
(such as the Juno) will become cumbersome. It is better to only
enable the multiple entry code on machines that actually need
it and disable it by default.

Make the single entry default and add a special
ARMV8_MULTIENTRY KConfig option to be used by the
platforms that need multientry and set it for the LS2085A.
Delete all use of the CPU_RELEASE_ADDR from the Vexpress64
boards as it is just totally unused and misleading, and
make it conditional in the generic start.S code.

This makes the Juno platform start U-Boot properly.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      23b5877c
  13. 06 3月, 2015 1 次提交
  15. 05 3月, 2015 1 次提交
    • M
      arm: socfpga: Add Altera Arria V DK support · c115a0d4
      由 Marek Vasut 提交于 
      Add support for the Altera Arria V development kit.
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: Chin Liang See <clsee@opensource.altera.com>
Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
Cc: Pavel Machek <pavel@denx.de>
Cc: Stefan Roese <sr@denx.de>
Cc: Vince Bridgers <vbridger@opensource.altera.com>
      c115a0d4
  17. 03 3月, 2015 1 次提交
  19. 28 2月, 2015 1 次提交
  21. 25 2月, 2015 6 次提交
  23. 23 2月, 2015 1 次提交
  25. 21 2月, 2015 10 次提交
  27. 13 2月, 2015 1 次提交
  29. 08 2月, 2015 2 次提交
  31. 07 2月, 2015 2 次提交
  33. 30 1月, 2015 2 次提交
    • L
      vexpress64: support the Juno Development Platform · ffc10373
      由 Linus Walleij 提交于 
      The Juno Development Platform is a physical Versatile Express
device with some differences from the emulated semihosting
models. The main difference is that the system is split in
a SoC and an FPGA where the SoC hosts the serial ports at
totally different adresses.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      ffc10373
    • L
      vexpress64: get rid of CONFIG_SYS_EXTRA_OPTIONS · f91afc4d
      由 Linus Walleij 提交于 
      The Versatile Express ARMv8 semihosted FVP platform is still
using the legacy CONFIG_SYS_EXTRA_OPTIONS method to configure
some compile-time flags. Get rid of this and create a Kconfig
entry for the FVP model, and a selectable bool for the
semihosting library.

The FVP subboard is now modeled as a target choice so we can
eventually choose between different ARMv8 versatile express
boards (FVP, base model, Juno...) this way. All dependent
symbols are updated to reflect this.

The 64bit Versatile Express board symbols are renamed
VEXPRESS64 so we have some chance to see what is actually
going on. Tested on the FVP fast model.
Acked-by: NSteve Rae <srae@broadcom.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      f91afc4d
  35. 22 1月, 2015 2 次提交