| Age | Commit message (Collapse) | Author |
|---|
|
We only need to compile and link these files when building for full
U-Boot. Move them to under cmd/x86/ to make sure they aren't linked in
and undiscarded due to u_boot_list_2_cmd_* being included).
Cc: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
This patch removes the inclusion of the libgcc math functions and
replaces them by functions coded in C, taken from the coreboot
project. This makes U-Boot building more independent from the toolchain
installed / available on the build system.
The code taken from coreboot is authored from Vadim Bendebury
<vbendeb@chromium.org> on 2014-11-28 and committed with commit
ID e63990ef [libpayload: provide basic 64bit division implementation]
(coreboot git repository located here [1]).
I modified the code so that its checkpatch clean without any
functional changes.
[1] git://github.com/coreboot/coreboot.git
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
|
|
This adds a library that provides CMOS (inside RTC SRAM) access
at a very early stage when driver model is not available yet.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Stefan Roese <sr@denx.de>
|
|
In an S3 resume path, U-Boot does everything like a cold boot except
in the last_stage_init() it jumps to the OS resume vector.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Stefan Roese <sr@denx.de>
|
|
This simple PMU driver allows to tyrn power on and off for selected
devices. In particularly Intel Tangier needs to power on SDHCI
controllers in order to access to them during board initialization.
In the future it might be expanded to cover other Intel MID platforms,
that's why it's located under arch/x86/lib and called pmu.c.
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Intel MID platforms have few microcontrollers inside SoC, one of them
is so called System Controller Unit (SCU).
Here is the driver to communicate with microcontroller.
Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
Booting into linux from 64-bit U-Boot is not yet supported. Avoid bringing
in the bootm code until it is implemented.
Of course 32-bit U-Boot still supports booting into both 32- and 64-bit
kernels.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
These cannot be built in this mode, so drop them.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
This is not supported, so disable it for now.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
SPL needs to set up the machine ready for loading 64-bit U-Boot and jumping
to it. Call the existing init routines in order to accomplish this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
Today we can compile a self-contained hello world efi test binary that
allows us to quickly verify whether the EFI loader framwork works.
We can use that binary outside of the self-contained test case though,
by providing it to a to-be-tested system via tftp.
This patch separates compilation of the helloworld.efi file from
including it in the u-boot binary for "bootefi hello". It also modifies
the efi_loader test case to enable travis to pick up the compiled file.
Because we're now no longer bloating the resulting u-boot binary, we
can enable compilation always, giving us good travis test coverage.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
Add compiler flags and make a few minor adjustments to support the efi
loader.
Signed-off-by: Simon Glass <sjg@chromium.org>
[agraf: Add Kconfig dep]
Signed-off-by: Alexander Graf <agraf@suse.de>
|
|
These files now need to be in a standard place so that they can be located
by generic Makefile rules. Move them to the 'lib' directory.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
|
|
Add the required pieces to support the EFI loader on x86.
Since U-Boot only builds for 32-bit on x86, only a 32-bit EFI application
is supported. If a 64-bit kernel must be booted, U-Boot supports this
directly using FIT (see doc/uImage.FIT/kernel.its). U-Boot can act as a
payload for both 32-bit and 64-bit EFI.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
|
|
We will need the SMBIOS generation function on ARM as well going forward,
so let's move it into a non arch specific location.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
coreboot_table.c only needs to be built when SeaBIOS is used.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
CONFIG_GENENRATE_ACPI_TABLE controls the generation of ACPI table which
uses U-Boot's built-in methods and CONFIG_QEMU_ACPI_TABLE controls whether
to load ACPI table from QEMU's fw_cfg interface.
But with commit "697ec431469ce0a4c2fc2c02d8685d907491af84 x86: qemu: Drop
our own ACPI implementation", there is only one way to support ACPI table
for QEMU targets which is the fw_cfg interface. Having two Kconfig options
for this purpose is not necessary any more, so this patch consolidates
the two.
Signed-off-by: Miao Yan <yanmiaobest@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
Add a driver which sets up the pin configuration on x86 devices with an ICH6
(or later) Platform Controller Hub.
The driver is not in the pinctrl uclass due to some oddities of the way x86
devices work:
- The GPIO controller is not present in I/O space until it is set up
- This is done by writing a register in the PCH
- The PCH has a driver which itself uses PCI, another driver
- The pinctrl uclass requires that a pinctrl device be available before any
other device can be probed
It would be possible to work around the limitations by:
- Hard-coding the GPIO address rather than reading it from the PCH
- Using special x86 PCI access to set the GPIO address in the PCH
However it is not clear that this is better, since the pin configuration
driver does not actually provide normal pin configuration services - it
simply sets up all the pins statically when probed. While this remains the
case, it seems better to use a syscon uclass instead. This can be probed
whenever it is needed, without any limitations.
Also add an 'invert' property to support inverting the input.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
To prepare generating coreboot table from U-Boot, implement functions
to handle the writing.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Now that we have converted all x86 codes to DM PCI, drop pci_type1.c
which is only built for legacy PCI. Also per checkpatch.pl warning,
DEFINE_PCI_DEVICE_TABLE is now deprecated so drop that too.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
This patch adds the ability to load and link ACPI tables provided by QEMU.
QEMU tells guests how to load and patch ACPI tables through its fw_cfg
interface, by adding a firmware file 'etc/table-loader'. Guests are
supposed to parse this file and execute corresponding QEMU commands.
Signed-off-by: Miao Yan <yanmiaobest@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
|
|
Add a uclass for the northbridge / SDRAM controller found on some older
Intel chipsets.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
A Platform Controller Hub is an Intel concept - it is like the peripherals
on an SoC and is often in a separate chip from the CPU. The chip is typically
found on the first PCI bus and integrates multiple devices.
We have a very simple uclass to support PCHs. Add a few operations, such as
setting up the devices on the PCH and finding the SPI controller base
address. Also move it into drivers/pch/ since we will be adding a few PCH
drivers.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
To group all dm timer drivers together, move tsc timer to
drivers/timer directory.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
Rename pcat_timer.c to i8254.c and pcat_interrupts.c to i8259.c,
to match their header file names (i8254.h and i8259.h).
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
mrccache implementation can be common for all boards. Move it
from ivybridge cpu directory to the common lib directory.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
Introduce a new fsp command and make the existing hob command a
sub-command to fsp for future extension. Also move cmd_hob.c to
the dedicated fsp sub-directory in arch/x86/lib.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
System Management BIOS (SMBIOS) is a specification for how
motherboard and system vendors present management information
about their products in a standard format by extending the BIOS
interface on Intel architecture systems. As of today the latest
spec is 3.0 and can be downloaded from DMTF website. This commit
adds a simple and minimum required implementation.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
install_e820_map() has nothing to do with zimage related codes.
Move it to a dedicated place.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
Implement write_acpi_table() to create a minimal working ACPI table.
This includes writing FACS, XSDT, RSDP, FADT, MCFG, MADT, DSDT & SSDT
ACPI table entries.
Use a Kconfig option GENERATE_ACPI_TABLE to tell U-Boot whether we need
actually write the APCI table just like we did for PIRQ routing, MP table
and SFI tables. With ACPI table existence, linux kernel gets control of
power management, thermal management, configuration management and
monitoring in hardware.
Signed-off-by: Saket Sinha <saket.sinha89@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tidied up whitespace and aligned some tabs:
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
When U-Boot is running from EFI some of the x86 init is replaced with
EFI-specific init. For example, since DRAM has already been set up, we only
need to find it, not init it. Add these functions so that boards can easily
allow booting from EFI if required.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
Add support for building a 32/64-bit EFI stub for x86. This involves
building the startup and relocation code for either i386 or x86_64.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
The MP table provides a way for the operating system to support
for symmetric multiprocessing as well as symmetric I/O interrupt
handling with the local APIC and I/O APIC. We provide a bunch of
APIs for U-Boot to write the floating table, configuration table
header as well as base and extended table entries.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
This provides a way of passing information to Linux without requiring the
full ACPI horror. Provide a rudimentary implementation sufficient to be
recognised and parsed by Linux.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
|
|
On x86 boards, platform chipset receives up to four different
interrupt signals from PCI devices (INTA/B/C/D), which in turn
will be routed to chipset internal PIRQ lines then routed to
8259 PIC finally if configuring the whole system to work under
the so-called PIC mode (in contrast to symmetric IO mode which
uses IOAPIC).
We add two major APIs to aid this, one for routing PIRQ and the
other one for generating a PIRQ routing table.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
We can write the configuration table in last_stage_init() for all x86
boards, but not with coreboot since coreboot already has them.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
CONFIG_VIDEO_VGA is no longer needed thus remove it.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
On x86 systems this device is commonly used to provide legacy port access.
It is sort-of a replacement for the old ISA bus.
Add a uclass for this, and allow it to have child devices.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Add a simple uclass for this chip which is often found in x86 systems
where the CPU is a separate device.
The device can have children, so make it scan the device tree for these.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Add a simple x86 PCI driver which uses standard functions provided by the
architecture.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
|
|
It is useful to be able to see the MTRR setup in U-Boot. Add a command
to list the state of the variable MTRR registers and allow them to be
changed.
Update the documentation to list some of the available commands.
This does not support fixed MTRRs as yet.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
|
|
FSP builds a series of data structures called the Hand-Off-Blocks
(HOBs) as it progresses through initializing the silicon. These data
structures conform to the HOB format as described in the Platform
Initialization (PI) specification Volume 3 Shared Architectual
Elements specification, which is part of the UEFI specification.
Create a simple command to parse the HOB list to display the HOB
address, type and length in bytes.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
On x86 machines we can use an emulator to run option ROMS as with other
architectures. But with some additional effort (mostly due to the 16-bit
nature of option ROMs) we can run them natively. Add support for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in
the board directory and the SDRAM SPD information in the device tree. This
also needs the Intel Management Engine (me.bin) to work. Binary blobs
everywhere: so far we have MRC, ME and microcode.
SDRAM init works by setting up various parameters and calling the MRC. This
in turn does some sort of magic to work out how much memory there is and
the timing parameters to use. It also sets up the DRAM controllers. When
the MRC returns, we use the information it provides to map out the
available memory in U-Boot.
U-Boot normally moves itself to the top of RAM. On x86 the RAM is not
generally contiguous, and anyway some RAM may be above 4GB which doesn't
work in 32-bit mode. So we relocate to the top of the largest block of
RAM we can find below 4GB. Memory above 4GB is accessible with special
functions (see physmem).
It would be possible to build U-Boot in 64-bit mode but this wouldn't
necessarily provide any more memory, since the largest block is often below
4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large
ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit
kernels directly so this does not pose a limitation in that area. Also there
are probably parts of U-Boot that will not work correctly in 64-bit mode.
The MRC is one.
There is some work remaining in this area. Since memory init is very slow
(over 500ms) it is possible to save the parameters in SPI flash to speed it
up next time. Suspend/resume support is not fully implemented, or at least
it is not efficient.
With this patch, link boots to a prompt.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
The motivation of this commit is to change CONFIG_USE_PRIVATE_LIBGCC
to a boolean macro so we can move it to Kconfig.
In the current implementation, there are two forms of syntax
for this macro:
- CONFIG_USE_PRIVATE_LIBGCC=y
- CONFIG_USE_PRIVATE_LIBGCC=path/to/private/libgcc
The latter is only used by x86 architecture.
With a little bit refactoring, it can be converted to the former.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Tested-by: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Simon Glass <sjg@chromium.org>
|
|
This commit changes the working directory
where the build process occurs.
Before this commit, build process occurred under the source
tree for both in-tree and out-of-tree build.
That's why we needed to add $(obj) prefix to all generated
files in makefiles like follows:
$(obj)u-boot.bin: $(obj)u-boot
Here, $(obj) is empty for in-tree build, whereas it points
to the output directory for out-of-tree build.
And our old build system changes the current working directory
with "make -C <sub-dir>" syntax when descending into the
sub-directories.
On the other hand, Kbuild uses a different idea
to handle out-of-tree build and directory descending.
The build process of Kbuild always occurs under the output tree.
When "O=dir/to/store/output/files" is given, the build system
changes the current working directory to that directory and
restarts the make.
Kbuild uses "make -f $(srctree)/scripts/Makefile.build obj=<sub-dir>"
syntax for descending into sub-directories.
(We can write it like "make $(obj)=<sub-dir>" with a shorthand.)
This means the current working directory is always the top
of the output directory.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Tested-by: Gerhard Sittig <gsi@denx.de>
|
|
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Simon Glass <sjg@chromium.org>
|
|
Signed-off-by: Wolfgang Denk <wd@denx.de>
[trini: Fixup common/cmd_io.c]
Signed-off-by: Tom Rini <trini@ti.com>
|
