17 Mar, 2016
1 commit
-
We don't need this anymore - we can use device tree and the new pinconfig
driver instead.Signed-off-by: Simon Glass
Reviewed-by: Bin Meng
04 Jun, 2015
2 commits
-
Although the two qemu-x86 targets (i440fx and q35) share a lot in
common, they still have something that cannot easily handled in one
single device tree). Split to create two dedicated device tree files
and make the i440fx be the default build target.Signed-off-by: Bin Meng
Acked-by: Simon Glass -
QEMU is much easier for us test booting U-Boot as a coreboot payload
than having a real board like chromebook_link.Signed-off-by: Bin Meng
Acked-by: Simon Glass
Tested-by: Simon Glass
13 May, 2015
1 commit
-
By making the board selections optional, every defconfig will include
the board selection when running savedefconfig so if a new board is
added to the top of the list of choices the former top's defconfig will
still be correct.Signed-off-by: Joe Hershberger
Cc: Masahiro Yamada
Acked-by: Stephen Warren
Cc: Tom Rini
30 Apr, 2015
2 commits
-
Currently all x86 boards still use CONFIG_SYS_EXTRA_OPTIONS to define
the text base address. Since it is deprecated, just remove it and use
CONFIG_SYS_TEXT_BASE directly.Signed-off-by: Bin Meng
Acked-by: Simon Glass -
Let arch/x86/Kconfig prompt board vendor first, then select
the board model under that vendor. This way arch/x86/Kconfig
only needs concern board vendor and leave the supported target
list to board//Kconfig.Signed-off-by: Bin Meng
Acked-by: Simon Glass
19 Apr, 2015
1 commit
-
Since driver model will probe the EC when it is first used, we do not
need to init it explicitly.Signed-off-by: Simon Glass
13 Jan, 2015
5 commits
-
cros_ec_board_init() should be called only when CONFIG_CROS_EC is
enabled.Signed-off-by: Bin Meng
Acked-by: Simon Glass -
Change SYS_CONFIG_NAME and DEFAULT_DEVICE_TREE to chromebook_link
which is currently the only real board officially supported to run
U-Boot loaded by coreboot.Note the symbolic link file chromebook_link.dts is deleted and
link.dts is renamed to chromebook_link.dts.To avoid multiple definition of video_hw_init, the CONFIG_VIDEO_X86
define needs to be moved to arch/x86/cpu/ivybridge/Kconfig.Signed-off-by: Bin Meng
Acked-by: Simon Glass -
Since we already swtiched to use the new mechanism for building
U-Boot for coreboot, coreboot.h is no longer needed so remove it.Signed-off-by: Bin Meng
Acked-by: Simon Glass -
Move CONFIG_SYS_CAR_ADDR and CONFIG_SYS_CAR_SIZE to Kconfig so that
we don't need them in the board configuration file thus the same
board configuratoin file can be used to build both coreboot version
and bare version.Signed-off-by: Bin Meng
Acked-by: Simon Glass -
In theory U-Boot built for coreboot is supposed to run as a payload
to be loaded by coreboot on every board that coreboot supports.
The U-Boot build process uses SYS_CONFIG_NAME and DEFAULT_DEVICE_TREE
which are hardcoded in board defconfig and Kconfig files. For better
support of coreboot, we want to make these two options configurable
so that we can easily change them during 'make menuconfig' so that
the generated U-Boot image for coreboot is board configuration aware.Signed-off-by: Bin Meng
Acked-by: Simon Glass
19 Dec, 2014
1 commit
-
Intel Tunnel Creek GPIO register block is compatible with current
ich6-gpio driver, except the offset and content of GPIO block base
address register in the LPC PCI configuration space are different.Use u16 instead of u32 to store the 16-bit I/O address of the GPIO
registers so that it could support both Ivybridge and Tunnel Creek.Signed-off-by: Bin Meng
Acked-by: Simon Glass
14 Dec, 2014
1 commit
-
Movie setup_pch_gpios() in the ich6-gpio driver to the board support
codes, so that the driver does not need to know any platform specific
stuff (ie: include the platform specifc chipset header file).Signed-off-by: Bin Meng
Acked-by: Simon Glass
21 Nov, 2014
1 commit
-
Rename this vendor since it is intended to be used on any platform where
coreboot runs at reset and then loads U-Boot.So far it is only tested on link. When other boards are supported it is
likely that we will need to move to multiple board names, all under the
'coreboot' vendor. So while it would be possible to remove the vendor for
now, that would be short-sighted.Suggested-by: Bin Meng
Signed-off-by: Simon Glass