At present we don't support loading microcode with FSP2. The correct way
to do this is by adding it to the FIT. For now, disable including
microcode in the image.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Newer Intel SoCs have different ways of setting up cache-as-ram (CAR).
Add support for these along with suitable configuration options.
To make the code cleaner, adjust a few definitions in processor.h so that
they can be used from assembler.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Many Intel SoCs require a FIT in order to boot properly. Add an option to
include this and enable it by default.
This term can be confused with FIT (Flat Image Tree) in U-Boot so the
CONFIG option has to include 'X86'.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
We don't generally have enough space to run this, so don't build it into
TPL. This helps reduce the size of TPL.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The fsp_notify() API is the same for FSP1 and FSP2. Move it into a new
common API file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
FSP-S is used by the notify call after it has been used for silicon init.
To avoid having to load it again, add a field to store the location.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
With FSP2 we need to run silicon init early after relocation. Add a new
hook for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The FSP-S may do this but at least for coral it does not. Set this up so
that graphics is not deathly slow.
It isn't clear whether the FSP is expected to set up MTRR. It is not
mentioned in the APL FSP document.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add support for some important configuration options and FSP memory init.
The memory init uses swizzle tables from the device tree.
Support for the FSP_S binary is also included.
Bootstage timing is used for both FSP_M and FSP_S and memory-mapped SPI
reads.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This generic FSP file should include the generic FSP support header, not
the FSP1 version. Fix it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Both versions of FSP can use the same graphics support, so move it into
the common directory.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present the interrupt table is included in all phases of U-Boot. Allow
it to be omitted, e.g. in TPL, to reduce size.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
These drivers are not needed on all platforms. While they are small, it
is useful in TPL to drop then. Add Kconfig control to allow this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
We don't want to pull in libfdt if of-platdata is being used, since it
reduces the available code-size saves. Also, SPI flash is seldom needed
in TPL.
Drop these options.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Set up MTRRs for the FSP SDRAM regions to improve performance.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present with fsp a single DRAM bank is added which extends to the
whole size of memory. However there is typically only 2GB of memory
available below the 4GB boundary, and this is what is used by U-Boot while
running in 32-bit mode.
Scan the tables to set the banks correct. The first bank is set to memory
below 4GB, and the rest of memory is put into subsequent banks.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This function needs to be different for FSP2, so move the existing
function into the fsp1 directory. Since it is only called from one file,
drop it from the header file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This function is only used within the implementation so make it static.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
With Apollo Lake we need to support a normal cache, which almost never
changes and a much smaller 'variable' cache which changes every time.
Update the code to add a cache type, use an array for the caches and use a
for loop to iterate over the caches.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This function is a bit confusing at present due to the error handling.
Update it to remove the goto, returning errors as they happen.
While we are here, use hex for the data size since this is the norm in
U-Boot.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present we reuse the mrc_output char * to also point to the cache
record after it has been set up. This is confusing and doesn't save much
data space.
Add a new mrc_cache member instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
It is now possible to obtain the memory map for a SPI controllers instead
of having it hard-coded in the device tree. Update the code to support
this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Change the algorithm to first find the flash device then read the
properties using the livetree API. With this change the device is not
probed so this needs to be done in mrccache_save().
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This should take account of the end of the new cache record since a record
cannot extend beyond the end of the flash region. This problem was not
seen before due to the alignment of the relatively small amount of MRC
data.
But with Apollo Lake the MRC data is about 45KB, even if most of it is
zeroes.
Fix this bug and update the parameter name to be less confusing.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present the records are 4KB in size. This is unnecessarily large when
the SPI-flash erase size is 256 bytes. Reduce it so it will be more
efficient with Apollo Lake's 24-byte variable-data record.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Define this symbol so that we can use binman symbols correctly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Update this uclass to support the needs of the Apollo Lake ITSS. It
supports four operations.
Move the uclass into a separate directory so that sandbox can use it too.
Add a new Kconfig to control it and enable this on x86.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add a sandbox driver and PCI-device emulator for p2sb. Also add a test
which uses a simple 'adder' driver to test the p2sb functionality.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
When reseting sandbox for tests, disable mmio support since that is the
default state.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The Primary-to-Sideband bus (P2SB) is used to access various peripherals
through memory-mapped I/O in a large chunk of PCI space. The space is
segmented into different channels and peripherals are accessed by
device-specific means within those channels. Devices should be added in
the device tree as subnodes of the p2sb.
This adds a uclass and enables it for sandbox.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Intel x86 SoCs have a power manager/controller which handles several
power-related aspects of the platform. Add a uclass for this, with a few
useful operations.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
We don't expect an exception in TPL and don't need to set up interrupts in
TPL. Drop this whole file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
We don't need to know every detail about the CPU in TPL. Drop some
superfluous functions to reduce code size. Add a simple CPU detection
algorithm which just supports Intel and AMD, since we only support TPL
on Intel, so far.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Most of the timer-calibration methods are not needed on recent Intel CPUs
and just increase code size. Add an option to use the known-good way to
get the clock frequency in TPL. Size reduction is about 700 bytes.
Note that version 1 of this commit caused bootstage to crash since the CPU
was not identified. This is corrected by changes previously applied to
make sure that the CPU is identified before spl_init() is called, such as
39146a2e0b x86: Move CPU init to before spl_init()
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
On x86 platforms the timer is reset to 0 when the SoC is reset. Having
this as the timer base is useful since it provides an indication of how
long it takes before U-Boot is running.
When U-Boot sets the timer base to something else, time is lost and we
no-longer have an accurate account of the time since reset. This
particularly affects bootstage.
Change the default to not read the timer base, leaving it at 0. Add an
option for when U-Boot is the secondary bootloader.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present the early timer init happens as soon as driver model is set up.
This makes it impossible to do anything that needs driver model but must
run before devices are probed (as needed with Intel's FSP-S, for example).
In any case it is not a good idea to tie probing of particular drivers too
closely to the DM init.
Create a new function to init the timer and put it a bit later in the
sequence.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present these options cannot be enabled for SPL/TPL, but this can be
useful in some cases. Add Kconfig options to allow it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
When device-tree compilation fails it is sometimes tricky to see which
line is broken, since the input file to dtc is a pre-processed version
of the device tree.
Add a line that points to the file that needs to be checked:
When the error is in the main .dts file, output is something like this:
output: 'Error: arch/x86/dts/.chromebook_coral.dtb.pre.tmp:478.46-47
syntax error
FATAL ERROR: Unable to parse input tree
but in fact looking at that file shows nothing useful:
PAD_CFG_NF_IOSSTATE_IOSTERM(GPIO_157, UP_20K, DEEP, NF1, HIZCRX1, DISPUPD)
Instead we need to look at the preprocessed file, which shows:
163 ((1U << 30) | (1 << 10)) ((0xb << 10) | PAD_CFG1_IOSSTATE_HIZCRX1)
Here it is clear that PAD_CFG1_IOSSTATE_HIZCRX1 is not defined and so is
not being resolved by the preprocessor.
This commit adds an additional useful message:
Check arch/x86/dts/.chromebook_coral.dtb.dts.tmp for errors
Note that if the error is reported in an included file, such as
u-boot.dtsi then the output is the following:
Error: arch/x86/dts/u-boot.dtsi:137.14-15 syntax error
FATAL ERROR: Unable to parse input tree
But again, if the error is due to a preprocessor failure, like this:
filename = CONFIG_IFW_INPUT_FILE;
then you can't tell what the problem is by looking at the source. All you
see is the original code:
intel-ifwi {
filename = CONFIG_IFW_INPUT_FILE;
...
};
};
intel-fsp-m {
filename = CONFIG_FSP_FILE_M;
};
Everything looks fine. But looking at the output of the preprocessor:
intel-ifwi {
filename = CONFIG_IFW_INPUT_FILE;
...
};
intel-fsp-m {
filename = "fsp_m.bin";
};
This shows that the filename (normally "fitimage.bin") has not been
inserted the preprocess, leading to the realisation that the value should
be CONFIG_IFWI_INPUT_FILE.
If the above does not make sense, I encourage people to try introducing
errors in the device tree preprocessed values.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Most x86 CPUs use a mechanism where the SPI flash is mapped into the very
top of 32-bit address space, so that it can be executed in place and read
simply by copying from memory. For an 8MB ROM the mapping starts at
0xff800000.
However some recent Intel CPUs do not use a simple 1:1 memory map. Instead
the map starts at a different address and not all of the SPI flash is
accessible through the map. This 'Fast SPI' feature requires that U-Boot
check the location of the map. It is also possible (optionally) to read
from the SPI flash using a driver.
Add support for booting from Fast SPI. The memory-mapped version is used
by both TPL and SPL on Apollo Lake.
In respect of a SPI flash driver, the actual SPI driver is ich.c - this
just adds a few helper functions and definitions.
This is used by Apollo Lake.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Allow this driver to set up an IO address in SPL using an 'early-regs'
property. This allows SPL to use the I2C driver without having to enable
the full PCI stack.
Also split out ofdata_to_platdata in designware driver since this is more
correct, and more convenient for the new logic.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Drivers are not allowed to use static data since they may be used in SPL
where BSS is not available.
It is possible that driver model may provide support for numbering devices
in the future. But for now, move this to global_data.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This is hacked into the driver at present. It seems better to have it as
a separate driver that uses the base driver. Create a new file and put
the X86 code into it.
Actually the Baytrail settings should really come from the device tree.
Note that 'has_max_speed' is added as well. This is currently always false
but since only Baytrail provides the config, it does not affect operation
for other devices.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
These functions are used by code outside the network support, so move them
to lib/ to be more accessible.
Without this, the functions are only accessible in SPL/TPL only if
CONFIG_SPL/TPL_NET are defined. Many boards do not enable those option but
still want to do checksums in this format.
Fix up a few code-style nits while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Early in boot it is necessary to decode the PCI device/function values for
particular peripherals in the device tree or of-platdata. This is needed
in TPL where CONFIG_PCI is not defined.
To handle this, move pci_get_devfn() into a file that is built even when
CONFIG_PCI is not defined.
Also add a function for use by of-platdata, to convert a reg property to
a pci_dev_t.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present PCI auto-configuration happens in U-Boot both before and after
relocation. This is a waste of time and may mess up static addresses used
in board_init_f(). Adjust the code to supporting doing auto-configuration
once, after relocation, under control of a device-tree property.
This is needed for Apollo Lake for debugging the silicon-init code. Once
the UART is moved to a different MMIO address the debug UART does not work
and any debug output in Apollo Lake's arch_fsp_init_r() causes a hang.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
If the offset is -1 this function correctly sets up a null ofnode. But if
the offset is any other negative number (e.g. -FDT_ERR_BADPATH) then it
does the wrong thing.
An offset of -1 in ofnode indicates that the ofnode is not valid. Any
other negative value is not handled by ofnode_valid(). We could of course
change that function, but it seems much better to always use the same
value for an invalid node.
Fix it by setting the offset to -1 if it is invalid for any reason.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present if CONFIG_SPL_GPIO_SUPPORT is enabled then the GPIO uclass
is included in SPL/TPL without any control for boards. Some boards may
want to disable this to reduce code size where GPIOs are not needed in
SPL or TPL.
Add a new Kconfig option to permit this. Default it to 'y' so that
existing boards work correctly.
Change existing uses of CONFIG_DM_GPIO to CONFIG_IS_ENABLED(DM_GPIO) to
preserve the current behaviour. Also update the 74x164 GPIO driver since
it cannot build with SPL.
This allows us to remove the hacks in config_uncmd_spl.h and
Makefile.uncmd_spl (eventually those files should be removed).
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
