At present this uses mtrr_add_request() & mtrr_commit() combination
to program the MTRR for graphics memory. This usage has two major
issues as below:
- mtrr_commit() will re-initialize all MTRR registers from index 0,
using the settings previously added by mtrr_add_request() and saved
in gd->arch.mtrr_req[], which won't cause any issue but is unnecessary
- The way such combination works is based on the assumption that U-Boot
has full control with MTRR programming (e.g.: U-Boot without any blob
that does all low-level initialization on its own, or using FSP2 which
does not touch MTRR), but this is not the case with FSP. FSP programs
some MTRRs during its execution but U-Boot does not have the settings
saved in gd->arch.mtrr_req[] and when doing mtrr_commit() it will
corrupt what was already programmed previously.
Correct this to use mtrr_set_next_var() instead.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The current vesa structure only provides a 32-bit value for the frame
buffer. Many modern machines use an address outside the range.
It is still useful to have this common struct, but add a separate
frame-buffer address as well.
Add a comment for vesa_setup_video_priv() while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
This function calls rtc_write32, which has a different signature
depending on if (SPL_)DM_RTC is enabled or not. This could result in a
mismatch in SPL if DM_RTC was enabled but SPL_DM_RTC, as the non-DM
declaration would still be used in SPL even though the implementation
would be for non-DM_RTC. We are switching to the correct definitions in
the next commit, so this will become a compilation error. Since
fsp_save_s3_stack is not called from SPL, avoid compiling it if
(SPL_)DM_RTC is disabled.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Rename these to VESA, itself an abbreviation, to avoid a conflict with
Verified Boot for Embedded.
Rename this to avoid referencing VBE.
Signed-off-by: Simon Glass <sjg@chromium.org>
We want to use VBE to mean Verfiied Boot for Embedded in U-Boot. Rename
the existing VBE (Vesa BIOS extensions) to allow this.
Verified Boot for Embedded is documented doc/develop/vbe.rst
Signed-off-by: Simon Glass <sjg@chromium.org>
For FSP1, there is no such INIT_PHASE_END_FIRMWARE.
Move board_final_cleanup() to fsp2 directory.
Fixes: 7c73cea442 ("x86: Notify the FSP of the 'end firmware' event")
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax
Tested-by: Simon Glass <sjg@chromium.org>
There are several outstanding issues as to why this does not apply
to FSP1:
* For FSP1, the system memory and reserved memory used by FSP are
already programmed in the MTRR by FSP.
* The 'mtrr_top' mistakenly includes TSEG memory range that has the
same RES_MEM_RESERVED resource type. Its address is programmed
and reported by FSP to be near the top of 4 GiB space, which is
not what we want for SDRAM.
* The call to mtrr_add_request() is not guaranteed to have its size
to be exactly the power of 2. This causes reserved bits of the
IA32_MTRR_PHYSMASK register to be written which generates #GP.
For FSP2, it seems this is necessary as without this, U-Boot boot
process on Chromebook Coral goes very slowly.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax
Tested-by: Simon Glass <sjg@chromium.org>
This driver cannot work when booted from coreboot, since the FSP
information is not available. Disable it in that case, so that the
coreboot video driver can be used instead.
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>
We use 'priv' for private data but often use 'platdata' for platform data.
We can't really use 'pdata' since that is ambiguous (it could mean private
or platform data).
Rename some of the latter variables to end with 'plat' for consistency.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present the top of available DRAM is the same as the top of the range
of the low-memory MTRR.
In fact, U-Boot is allowed to use memory up until the start of the FSP
reserved memory. Use that value for low_end, since it makes more memory
available.
Keep the same calculation as before for mtrr_top, i.e. the top of
reserved memory.
A side-effect of this change is that the E820 tables have a single entry
that extends from the bottom of the memory used by U-Boot to the bottom
of the FSP reserved memory. This includes the bloblist, if ACPI tables
are placed there.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Quite a few log_info() calls are included in the x86 code which should use
log_debug() instead. Convert them to reduce unwanted output.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Some boards want to reserve extra regions of memory. Add a 'chosen'
property to support this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Send this notification when U-Boot is about to boot into Linux, as
requested by the FSP.
Currently this causes a crash with the APL FSP, so leave it disabled for
now.
Signed-off-by: Simon Glass <sjg@chromium.org>
Configuration variables should have the same meaning independent of the
architecture. x86 and ARM both use CONFIG_STACK_SIZE:
* x86: U-Boot's runtime stack size during reboot
* ARM: max stack size that can be used by U-Boot
Rename the x86 configuration variable to CONFIG_STACK_SIZE_REBOOT
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
This function sounds like something that is called when U-Boot is about to
jump to Linux. In fact it is an init function.
Rename it to reduce confusion.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
At present this enables a few arch-specific members of the global_data
struct which are otherwise not part of the struct. As a result we have to
use #ifdef in various places.
The cost of always having these in the struct is small. Adjust things so
that we can use compile-time code instead of #ifdefs.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
When the copy framebuffer is in use, we must also have the standard U-Boot
framebuffer available. Update the FSP driver to support this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Set this value in global_data so that it is reported correctly on x86
boards.
In fact, U-Boot allocates space for the frame buffer even though it is not
used. Then the FSP picks the address itself (e.g. 0xb0000000). So the
value set by U-Boot (high in memory with everything else that is
relocated), is not actually the correct value.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
It is useful to be able to boot the same x86 image on a device with or
without a first-stage bootloader. For example, with chromebook_coral, it
is helpful for testing to be able to boot the same U-Boot (complete with
FSP) on bare metal and from coreboot. It allows checking of things like
CPU speed, comparing registers, ACPI tables and the like.
When U-Boot is not the first-stage bootloader much of this code is not
needed and can break booting. Add checks for this to the FSP code.
Rather than checking for the amount of available SDRAM, just use 1GB in
this situation, which should be safe. Using 2GB may run into a memory
hole on some SoCs.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This header relates to ACPI and we are about to add some more ACPI
headers. Move this one into a new directory so they are together.
The header inclusion in pci_rom.c is not specific to x86 anymore, so drop
the #ifdef CONFIG_X86.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
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>
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>
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>
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>
Move this function into init.h which seems to be designed for this sort
of thing. Also update the header to declare struct global_data so that it
can be included without global_data.h being needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
At present this hedaer is only available on x86. To allow sandbox to use
it for testing, move it to a common location.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The useable RAM is calculated when the RAM is inited. Save this value so
that it can be easily used in U-Boot proper.
Also save a pointer to the hob list so that it is accessible (before
relocation only) in U-Boot proper. This avoids having to scan it in SPL,
for everything U-Boot proper might need later.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
[bmeng: guard handoff_arch_save() with IS_ENABLED(CONFIG_USE_HOB)]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
With FSP2 the non-volatile storage used by the FSP to init memory can be
split into a fixed piece (determined at compile time) and a variable piece
(determined at run time). Add support for reading the latter.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Some of this file can be shared between FSP1 and FSP2. Move it into a
shared file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Some of this file can be shared between FSP1 and FSP2. Move it into a
shared file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Most of the DRAM functionality can be shared between FSP1 and FSP2. Move
it into a shared file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
[bmeng: rebase the patch against u-boot-x86/next to get it applied cleanly]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Since there is now a new version of the FSP and it is incompatible with
the existing version, move the code into an fsp1 directory. This will
allow us to put FSP v2 code into an fsp2 directory.
Add a Kconfig which defines which version is in use.
Some of the code in this new fsp1/ directory is generic across both FSPv1
and FSPv2. Future patches will address this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
FSP (CONFIG_HAVE_FSP) and Slim Bootloader (CONFIG_SYS_SLIMBOOTLOADER)
consume HOB (CONFIG_USE_HOB) data from the each HOB list pointer.
Add a common HOB library in lib/hob.c and include/asm/hob.h.
Signed-off-by: Aiden Park <aiden.park@intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Use existing EFI_GUID and efi_guid_t instead of struct efi_guid.
This is pre-work before making a common HOB library.
- Change 'struct efi_guid' to efi_guit_t
- Remove 'struct efi_guid'
- Define GUIDs with EFI_GUID() macro
- Use guidcmp() instead of compare_guid()
- Remove compare_guid()
Signed-off-by: Aiden Park <aiden.park@intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested on MinnowMax
Tested-by: Bin Meng <bmeng.cn@gmail.com>
We use binman to build the x86 image now. Update a comment which still
refers to ifdtool.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
In preparation for the reset driver conversion, eliminate the
reset_cpu() call in the FSP init path as it's too early for the
reset driver to work.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Built without a ROM image with FSP (u-boot.rom), the U-Boot loader applies
the microcode update data block encoded in Device Tree to the bootstrap
processor but not passed to the other CPUs when multiprocessing is enabled.
If the bootstrap processor successfully performs a microcode update
from Device Tree, use the same data block for the other processors.
Signed-off-by: Ivan Gorinov <ivan.gorinov@intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
[bmeng: fixed build errors on edison and qemu-x86]
Signed-off-by: Bin Meng <bmeng.cn@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>
This changes 'struct e820entry' to 'struct e820_entry' to conform
with the coding style.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
