The current name is inconsistent with SPL which uses CONFIG_SPL_TEXT_BASE
and this makes it imposible to use CONFIG_VAL().
Rename it to resolve this problem.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use VENDOR_COREBOOT instead of TARGET_COREBOOT so we can have multiple
coreboot boards, sharing options. Only SYS_CONFIG_NAME needs to be
defined TARGET_COREBOOT.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The BIOS version may not be present, e.g. on a Chrome OS build. Add the
BIOS date as well, so we get some sort of indication of coreboot's
vintage.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
It is possible to boot U-Boot for chromebook_coral either 'bare metal' or
from coreboot. In the latter case we want to provide access to the coreboot
sysinfo tables. Move the definitions into a file available to any x86
board.
Signed-off-by: Simon Glass <sjg@chromium.org>
Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
If u-boot gets used as coreboot payload it might be nice to get
vendor, model and bios version from smbios. I am not sure about
the output of all the read information.
With qemu target for coreboot this could look this:
CBFS: Found @ offset 14f40 size 3b188
Checking segment from ROM address 0xffc15178
Checking segment from ROM address 0xffc15194
Loading segment from ROM address 0xffc15178
code (compression=1)
New segment dstaddr 0x01110000 memsize 0x889ef srcaddr 0xffc151b0 filesize 0x3b150
Loading Segment: addr: 0x01110000 memsz: 0x00000000000889ef filesz: 0x000000000003b150
using LZMA
Loading segment from ROM address 0xffc15194
Entry Point 0x01110000
BS: BS_PAYLOAD_LOAD run times (exec / console): 77 / 1 ms
Jumping to boot code at 0x01110000(0x07fa7000)
U-Boot 2020.10-00536-g5dcf7cc590-dirty (Oct 07 2020 - 14:21:51 +0200)
CPU: x86_64, vendor AMD, device 663h
DRAM: 127.1 MiB
MMC:
Video: No video mode configured in coreboot!
Video: No video mode configured in coreboot!
Vendor: QEMU
Model: Standard PC (i440FX + PIIX, 1996)
Bios Version: 4.12-3152-g326a499f6f-dirty
Net: e1000: 52:54:00:12:34:56
eth0: e1000#0
No working controllers found
Finalizing coreboot
Hit any key to stop autoboot: 0
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
start.S does nothing and can be safely removed. Makefile is still being used
by the build system, so simply drop the rule from it.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Coreboot is a first-stage bootloader mostly used on x86 devices as an
alternative to UEFI. Coreboot runs in 32-bit mode.
U-Boot currently supports booting from coreboot as a second-stage
bootloader, also in 32-bit mode. However it is useful to be able to run
U-Boot in 64-bit mode. To do this we can have a 32-bit SPL which switches
over the CPU and jumps to a 64-bit U-Boot proper.
Add a new 'coreboot64' board for running 64-bit U-Boot from coreboot. This
uses binman to create an image with a 32-bit SPL and a 64-bit U-Boot.
This allows running 64-bit EFI images on x86, for example, without needing
a native U-Boot port for a board.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
A number of board function belong in init.h with the others. Move them.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Currently building U-Boot as the coreboot payload requires user
to change the build configuration for a specific board during
menuconfig process. This uses the board's native device tree
to configure the hardware. For example, the device tree provides
PCI address range for the PCI host controller and U-Boot will
re-program all PCI devices' BAR to be within this range. In order
to make sure we don't mess up the hardware, we should guarantee
the range matches what coreboot programs the chipset.
But we really should make the coreboot payload support easier.
Just like EFI payload, we can create a generic coreboot payload
for all x86 boards as well. The payload is configured to include
as many generic drivers as possible. All stuff that touches low
level initialization are not allowed as such is the coreboot's
responsibility. Platform specific drivers (like gpio, spi, etc)
are not included.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from. So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry. Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.
In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.
This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents. There's also a few places where I found we did not have a tag
and have introduced one.
Signed-off-by: Tom Rini <trini@konsulko.com>
We only use coreboot as a target on x86 platforms, since on ARM platforms
U-Boot always runs as the primary boot loader. Rename the coreboot-x86
platform to reflect this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Only a specific type of SPI flash exists on a board, having board
Kconfig to select the SPI flash seems to make more sense. Other
flash types are not necessary except coreboot, which implies all
available flash drivers there.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This is architecture-dependent early initialization hence should
be put in the platform Kconfig.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
We don't need this anymore - we can use device tree and the new pinconfig
driver instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
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 <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
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 <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
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 <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
cros_ec_board_init() should be called only when CONFIG_CROS_EC is
enabled.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
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 <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
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 <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
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 <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
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 <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
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 <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
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 <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
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 <bmeng.cn@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
