summaryrefslogtreecommitdiffstats
path: root/arch/x86/lib/fsp/fsp_dram.c
Commit message (Collapse)AuthorAgeFilesLines
* common: Drop asm/global_data.h from common headerSimon Glass2021-02-021-0/+1
| | | | | | | | | | | | 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>
* x86: fsp: Adjust calculations for MTRR range and DRAM topSimon Glass2020-11-061-13/+22
| | | | | | | | | | | | | | | | | | | | 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>
* x86: Add a way to add to the e820 memory tableSimon Glass2020-09-251-0/+17
| | | | | | | | 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>
* x86: rename CONFIG_STACK_SIZEHeinrich Schuchardt2020-08-011-1/+1
| | | | | | | | | | | | 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>
* x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUMESimon Glass2020-07-171-11/+15
| | | | | | | | | | | | 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>
* common: Drop log.h from common headerSimon Glass2020-05-181-0/+1
| | | | | | Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: fsp: Allow skipping init code when chain loadingSimon Glass2020-04-301-0/+8
| | | | | | | | | | | | | | | | | | 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>
* x86: Set up the MTRR for SDRAMSimon Glass2019-12-151-0/+5
| | | | | | | 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>
* x86: Set the DRAM banks to reflect real locationSimon Glass2019-12-151-1/+29
| | | | | | | | | | | | | 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>
* common: Move board_get_usable_ram_top() out of common.hSimon Glass2019-12-021-0/+1
| | | | | | | | | 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>
* x86: fsp: Save usable RAM and hob_list in the handoff areaSimon Glass2019-10-081-0/+10
| | | | | | | | | | | | | | 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>
* x86: fsp: Move common dram functions into a common fileSimon Glass2019-10-081-0/+90
| | | | | | | | | | | 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>
* x86: Rename existing FSP code to fsp1Simon Glass2019-10-081-108/+0
| | | | | | | | | | | | | | | 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>
* SPDX: Convert all of our single license tags to Linux Kernel styleTom Rini2018-05-071-2/+1
| | | | | | | | | | | | | | | | | | | | 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>
* x86: Rename e820entry to e820_entryBin Meng2018-04-161-1/+1
| | | | | | | | 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>
* x86: Use 'unsigned int' in install_e820_map() functionsBin Meng2018-04-161-2/+3
| | | | | | | | | This fixes the following checkpatch warning: warning: Prefer 'unsigned int' to bare use of 'unsigned' Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
* x86: fsp: Mark memory used by U-Boot as reserved in the E820 table for S3Bin Meng2017-05-171-0/+12
| | | | | | | | | | U-Boot itself as well as everything that is consumed by U-Boot (like heap, stack, dtb, etc) needs to be reserved and reported in the E820 table when S3 resume is on. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Stefan Roese <sr@denx.de>
* board_f: Drop setup_dram_config() wrapperSimon Glass2017-04-051-1/+3
| | | | | | | | By making dram_init_banksize() return an error code we can drop the wrapper. Adjust this and clean up all implementations. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Stefan Roese <sr@denx.de>
* x86: fsp: Pass mrc cache to fsp_init() and save it to gd after fsp_init()Bin Meng2015-10-211-0/+6
| | | | | | | | | | fsp_init() call has a parameter nvs_buf which is used by FSP as the MRC cache but currently is blindly set to NULL. Retreive the MRC cache from SPI flash and pass it to fsp_init() call. After the call, save FSP produced MRC cache to SPI flash too. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: fsp: Report correct number of E820 table entriesBin Meng2015-09-281-1/+2
| | | | | | | | | The logic to calculate the number of E820 table entries is wrong when walking through the FSP HOB tables. Fix it. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Jian Luo <jian.luo4@boschrexroth.de> Acked-by: Simon Glass <sjg@chromium.org>
* x86: Reserve PCIe ECAM address range in the E820 tableBin Meng2015-07-281-0/+6
| | | | | | | | We should mark PCIe ECAM address range in the E820 table as reserved otherwise kernel will not attempt to use ECAM. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: Make CAR and DRAM FSP code commonSimon Glass2015-02-051-0/+81
For now this code seems to be the same for all FSP platforms. Make it common until we see what differences are required. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>